পূর্ববর্তী রিলিজের মতো, Android 14-তেও এমন আচরণগত পরিবর্তন রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। নিম্নলিখিত আচরণগত পরিবর্তনগুলি কেবলমাত্র Android 14 (API লেভেল 34) বা তার বেশি ভার্সনের অ্যাপগুলিতে প্রযোজ্য। যদি আপনার অ্যাপটি Android 14 বা তার বেশি ভার্সনের জন্য তৈরি হয়, তাহলে প্রযোজ্য ক্ষেত্রে এই আচরণগুলিকে সঠিকভাবে সমর্থন করার জন্য আপনার অ্যাপটি পরিবর্তন করা উচিত।
অ্যাপটির targetSdkVersion যাই হোক না কেন , Android 14 এ চলমান সমস্ত অ্যাপকে প্রভাবিত করে এমন আচরণগত পরিবর্তনের তালিকাটিও পর্যালোচনা করতে ভুলবেন না।
মূল কার্যকারিতা
ফোরগ্রাউন্ড পরিষেবার ধরণগুলি প্রয়োজন
যদি আপনার অ্যাপটি Android 14 (API লেভেল 34) বা উচ্চতরকে টার্গেট করে, তাহলে এটিকে অবশ্যই আপনার অ্যাপের মধ্যে প্রতিটি ফোরগ্রাউন্ড পরিষেবার জন্য অন্তত একটি ফোরগ্রাউন্ড পরিষেবার ধরণ নির্দিষ্ট করতে হবে। আপনার একটি ফোরগ্রাউন্ড পরিষেবার ধরন বেছে নেওয়া উচিত যা আপনার অ্যাপের ব্যবহারের ক্ষেত্রে প্রতিনিধিত্ব করে। সিস্টেমটি ফোরগ্রাউন্ড পরিষেবাগুলি আশা করে যেগুলির একটি নির্দিষ্ট ধরণের একটি নির্দিষ্ট ব্যবহারের ক্ষেত্রে সন্তুষ্ট হয়।
যদি আপনার অ্যাপে ব্যবহারের ক্ষেত্রে এই ধরনের কোনোটির সাথে যুক্ত না হয়, তাহলে এটি দৃঢ়ভাবে সুপারিশ করা হয় যে আপনি WorkManager বা ব্যবহারকারী-সূচিত ডেটা স্থানান্তর কাজগুলি ব্যবহার করতে আপনার যুক্তি স্থানান্তর করুন৷
BluetoothAdapter-এ BLUETOOTH_CONNECT অনুমতির প্রয়োগ
Android 14 (API লেভেল 34) বা উচ্চতরকে লক্ষ্য করে এমন অ্যাপগুলির জন্য BluetoothAdapter getProfileConnectionState() পদ্ধতিতে কল করার সময় Android 14 BLUETOOTH_CONNECT অনুমতি প্রয়োগ করে৷
এই পদ্ধতিটি ইতিমধ্যেই BLUETOOTH_CONNECT অনুমতির প্রয়োজন ছিল, কিন্তু এটি প্রয়োগ করা হয়নি৷ নিম্নলিখিত স্নিপেটে দেখানো হিসাবে আপনার অ্যাপটি আপনার অ্যাপের AndroidManifest.xml ফাইলে BLUETOOTH_CONNECT ঘোষণা করেছে এবং getProfileConnectionState এ কল করার আগে একজন ব্যবহারকারী অনুমতি দিয়েছেন কিনা তা পরীক্ষা করুন ।
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
OpenJDK ১৭টি আপডেট
Android 14 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases, including both library updates and Java 17 language support for app and platform developers.
A few of these changes can affect app compatibility:
- Changes to regular expressions: Invalid group references are now
disallowed to more closely follow the semantics of OpenJDK. You might see
new cases where an
IllegalArgumentExceptionis thrown by thejava.util.regex.Matcherclass, so make sure to test your app for areas that use regular expressions. To enable or disable this change while testing, toggle theDISALLOW_INVALID_GROUP_REFERENCEflag using the compatibility framework tools. - UUID handling: The
java.util.UUID.fromString()method now does more strict checks when validating the input argument, so you might see anIllegalArgumentExceptionduring deserialization. To enable or disable this change while testing, toggle theENABLE_STRICT_VALIDATIONflag using the compatibility framework tools. - ProGuard issues: In some cases, the addition of the
java.lang.ClassValueclass causes an issue if you try to shrink, obfuscate, and optimize your app using ProGuard. The problem originates with a Kotlin library that changes runtime behaviour based on whetherClass.forName("java.lang.ClassValue")returns a class or not. If your app was developed against an older version of the runtime without thejava.lang.ClassValueclass available, then these optimizations might remove thecomputeValuemethod from classes derived fromjava.lang.ClassValue.
জবশিডিউলার কলব্যাক এবং নেটওয়ার্ক আচরণকে শক্তিশালী করে
এটির প্রবর্তনের পর থেকে, JobScheduler আশা করে যে আপনার অ্যাপটি কয়েক সেকেন্ডের মধ্যে onStartJob বা onStopJob থেকে ফিরে আসবে। অ্যান্ড্রয়েড 14 এর আগে, যদি একটি কাজ খুব বেশি সময় ধরে চলে, তবে কাজটি বন্ধ হয়ে যায় এবং নীরবে ব্যর্থ হয়। যদি আপনার অ্যাপটি Android 14 (API লেভেল 34) বা তার বেশিকে টার্গেট করে এবং মূল থ্রেডে নির্ধারিত সময় অতিক্রম করে, তাহলে অ্যাপটি onStartJob -এ কোন প্রতিক্রিয়া নেই" বা " onStopJob এ কোন প্রতিক্রিয়া নেই" ত্রুটি বার্তা সহ একটি ANR ট্রিগার করে।
এই ANR 2টি পরিস্থিতির ফলাফল হতে পারে: 1. মূল থ্রেড ব্লক করার কাজ রয়েছে, onStartJob বা onStopJob কলব্যাকগুলিকে প্রত্যাশিত সময়ের সীমার মধ্যে কার্যকর করা এবং সম্পূর্ণ করা থেকে বাধা দিচ্ছে৷ 2. ডেভেলপার JobScheduler কলব্যাক onStartJob বা onStopJob মধ্যে ব্লক করার কাজ চালাচ্ছেন, প্রত্যাশিত সময়সীমার মধ্যে কলব্যাক সম্পূর্ণ হতে বাধা দিচ্ছে।
#1 এড্রেস করার জন্য, ANR ঘটলে মূল থ্রেডকে কী ব্লক করছে তা আপনাকে আরও ডিবাগ করতে হবে, ANR ঘটলে সমাধির পাথরের ট্রেস পেতে আপনি ApplicationExitInfo#getTraceInputStream() ব্যবহার করে এটি করতে পারেন। আপনি যদি ম্যানুয়ালি ANR পুনরুত্পাদন করতে সক্ষম হন, আপনি একটি সিস্টেম ট্রেস রেকর্ড করতে পারেন এবং ANR ঘটলে মূল থ্রেডে কী চলছে তা আরও ভালভাবে বুঝতে Android Studio বা Perfetto ব্যবহার করে ট্রেস পরিদর্শন করতে পারেন। মনে রাখবেন যে JobScheduler API সরাসরি ব্যবহার করার সময় বা androidx লাইব্রেরি WorkManager ব্যবহার করার সময় এটি ঘটতে পারে।
#2 ঠিকানার জন্য, WorkManager- এ স্থানান্তরিত করার কথা বিবেচনা করুন, যা onStartJob বা onStopJob এ একটি অ্যাসিঙ্ক্রোনাস থ্রেডে যেকোনো প্রক্রিয়াকরণ মোড়ানোর জন্য সমর্থন প্রদান করে।
যদি setRequiredNetworkType বা setRequiredNetwork সীমাবদ্ধতা ব্যবহার করে তাহলে JobScheduler ACCESS_NETWORK_STATE অনুমতি ঘোষণা করার জন্য একটি প্রয়োজনীয়তাও প্রবর্তন করে। যদি আপনার অ্যাপটি কাজের সময়সূচী করার সময় ACCESS_NETWORK_STATE অনুমতি ঘোষণা না করে এবং Android 14 বা উচ্চতরকে লক্ষ্য করে, তাহলে এটি একটি SecurityException হবে।
এটির প্রবর্তনের পর থেকে, JobScheduler আশা করে যে আপনার অ্যাপটি কয়েক সেকেন্ডের মধ্যে onStartJob বা onStopJob থেকে ফিরে আসবে। অ্যান্ড্রয়েড 14 এর আগে, যদি একটি কাজ খুব বেশি সময় ধরে চলে, তবে কাজটি বন্ধ হয়ে যায় এবং নীরবে ব্যর্থ হয়। যদি আপনার অ্যাপটি Android 14 (API লেভেল 34) বা তার বেশিকে টার্গেট করে এবং মূল থ্রেডে নির্ধারিত সময় অতিক্রম করে, তাহলে অ্যাপটি onStartJob -এ কোন প্রতিক্রিয়া নেই" বা " onStopJob এ কোন প্রতিক্রিয়া নেই" ত্রুটি বার্তা সহ একটি ANR ট্রিগার করে।
এই ANR 2টি পরিস্থিতির ফলাফল হতে পারে: 1. মূল থ্রেড ব্লক করার কাজ রয়েছে, onStartJob বা onStopJob কলব্যাকগুলিকে প্রত্যাশিত সময়ের সীমার মধ্যে কার্যকর করা এবং সম্পূর্ণ করা থেকে বাধা দিচ্ছে৷ 2. ডেভেলপার JobScheduler কলব্যাক onStartJob বা onStopJob মধ্যে ব্লক করার কাজ চালাচ্ছেন, প্রত্যাশিত সময়সীমার মধ্যে কলব্যাক সম্পূর্ণ হতে বাধা দিচ্ছে।
#1 এড্রেস করার জন্য, ANR ঘটলে মূল থ্রেডকে কী ব্লক করছে তা আপনাকে আরও ডিবাগ করতে হবে, ANR ঘটলে সমাধির পাথরের ট্রেস পেতে আপনি ApplicationExitInfo#getTraceInputStream() ব্যবহার করে এটি করতে পারেন। আপনি যদি ম্যানুয়ালি ANR পুনরুত্পাদন করতে সক্ষম হন, আপনি একটি সিস্টেম ট্রেস রেকর্ড করতে পারেন এবং ANR ঘটলে মূল থ্রেডে কী চলছে তা আরও ভালভাবে বুঝতে Android Studio বা Perfetto ব্যবহার করে ট্রেস পরিদর্শন করতে পারেন। মনে রাখবেন যে JobScheduler API সরাসরি ব্যবহার করার সময় বা androidx লাইব্রেরি WorkManager ব্যবহার করার সময় এটি ঘটতে পারে।
#2 ঠিকানার জন্য, WorkManager- এ স্থানান্তরিত করার কথা বিবেচনা করুন, যা onStartJob বা onStopJob এ একটি অ্যাসিঙ্ক্রোনাস থ্রেডে যেকোনো প্রক্রিয়াকরণ মোড়ানোর জন্য সমর্থন প্রদান করে।
যদি setRequiredNetworkType বা setRequiredNetwork সীমাবদ্ধতা ব্যবহার করে তাহলে JobScheduler ACCESS_NETWORK_STATE অনুমতি ঘোষণা করার জন্য একটি প্রয়োজনীয়তাও প্রবর্তন করে। যদি আপনার অ্যাপটি কাজের সময়সূচী করার সময় ACCESS_NETWORK_STATE অনুমতি ঘোষণা না করে এবং Android 14 বা উচ্চতরকে লক্ষ্য করে, তাহলে এটি একটি SecurityException হবে।
এটির প্রবর্তনের পর থেকে, JobScheduler আশা করে যে আপনার অ্যাপটি কয়েক সেকেন্ডের মধ্যে onStartJob বা onStopJob থেকে ফিরে আসবে। অ্যান্ড্রয়েড 14-এর আগে, যদি কোনও কাজ খুব বেশি সময় ধরে চলে তবে কাজটি বন্ধ হয়ে যায় এবং নীরবে ব্যর্থ হয়। যদি আপনার অ্যাপটি Android 14 (API লেভেল 34) বা তার বেশিকে টার্গেট করে এবং মূল থ্রেডে নির্ধারিত সময় অতিক্রম করে, তাহলে অ্যাপটি onStartJob -এ কোন প্রতিক্রিয়া নেই" বা " onStopJob এ কোন প্রতিক্রিয়া নেই" ত্রুটি বার্তা সহ একটি ANR ট্রিগার করে।
এই ANR 2টি পরিস্থিতির ফলাফল হতে পারে: 1. মূল থ্রেড ব্লক করার কাজ রয়েছে, onStartJob বা onStopJob কলব্যাকগুলিকে প্রত্যাশিত সময়ের সীমার মধ্যে কার্যকর করা এবং সম্পূর্ণ করা থেকে বাধা দিচ্ছে৷ 2. ডেভেলপার JobScheduler কলব্যাক onStartJob বা onStopJob মধ্যে ব্লক করার কাজ চালাচ্ছেন, প্রত্যাশিত সময়সীমার মধ্যে কলব্যাক সম্পূর্ণ হতে বাধা দিচ্ছে।
#1 এড্রেস করার জন্য, ANR ঘটলে মূল থ্রেডকে কী ব্লক করছে তা আপনাকে আরও ডিবাগ করতে হবে, ANR ঘটলে সমাধির পাথরের ট্রেস পেতে আপনি ApplicationExitInfo#getTraceInputStream() ব্যবহার করে এটি করতে পারেন। আপনি যদি ম্যানুয়ালি ANR পুনরুত্পাদন করতে সক্ষম হন, আপনি একটি সিস্টেম ট্রেস রেকর্ড করতে পারেন এবং ANR ঘটলে মূল থ্রেডে কী চলছে তা আরও ভালভাবে বুঝতে Android Studio বা Perfetto ব্যবহার করে ট্রেস পরিদর্শন করতে পারেন। মনে রাখবেন যে JobScheduler API সরাসরি ব্যবহার করার সময় বা androidx লাইব্রেরি WorkManager ব্যবহার করার সময় এটি ঘটতে পারে।
#2 ঠিকানার জন্য, WorkManager- এ স্থানান্তরিত করার কথা বিবেচনা করুন, যা onStartJob বা onStopJob এ একটি অ্যাসিঙ্ক্রোনাস থ্রেডে যেকোনো প্রক্রিয়াকরণ মোড়ানোর জন্য সমর্থন প্রদান করে।
যদি setRequiredNetworkType বা setRequiredNetwork সীমাবদ্ধতা ব্যবহার করে তাহলে JobScheduler ACCESS_NETWORK_STATE অনুমতি ঘোষণা করার জন্য একটি প্রয়োজনীয়তাও প্রবর্তন করে। যদি আপনার অ্যাপটি কাজের সময়সূচী করার সময় ACCESS_NETWORK_STATE অনুমতি ঘোষণা না করে এবং Android 14 বা উচ্চতরকে লক্ষ্য করে, তাহলে এটি একটি SecurityException হবে।
এটির প্রবর্তনের পর থেকে, JobScheduler আশা করে যে আপনার অ্যাপটি কয়েক সেকেন্ডের মধ্যে onStartJob বা onStopJob থেকে ফিরে আসবে। অ্যান্ড্রয়েড 14 এর আগে, যদি একটি কাজ খুব বেশি সময় ধরে চলে, তবে কাজটি বন্ধ হয়ে যায় এবং নীরবে ব্যর্থ হয়। যদি আপনার অ্যাপটি Android 14 (API লেভেল 34) বা তার বেশিকে টার্গেট করে এবং মূল থ্রেডে নির্ধারিত সময় অতিক্রম করে, তাহলে অ্যাপটি onStartJob -এ কোন প্রতিক্রিয়া নেই" বা " onStopJob এ কোন প্রতিক্রিয়া নেই" ত্রুটি বার্তা সহ একটি ANR ট্রিগার করে।
এই ANR 2টি পরিস্থিতির ফলাফল হতে পারে: 1. মূল থ্রেড ব্লক করার কাজ রয়েছে, onStartJob বা onStopJob কলব্যাকগুলিকে প্রত্যাশিত সময়ের সীমার মধ্যে কার্যকর করা এবং সম্পূর্ণ করা থেকে বাধা দিচ্ছে৷ 2. ডেভেলপার JobScheduler কলব্যাক onStartJob বা onStopJob মধ্যে ব্লক করার কাজ চালাচ্ছেন, প্রত্যাশিত সময়সীমার মধ্যে কলব্যাক সম্পূর্ণ হতে বাধা দিচ্ছে।
#1 এড্রেস করার জন্য, ANR ঘটলে মূল থ্রেডকে কী ব্লক করছে তা আপনাকে আরও ডিবাগ করতে হবে, ANR ঘটলে সমাধির পাথরের ট্রেস পেতে আপনি ApplicationExitInfo#getTraceInputStream() ব্যবহার করে এটি করতে পারেন। আপনি যদি ম্যানুয়ালি ANR পুনরুত্পাদন করতে সক্ষম হন, আপনি একটি সিস্টেম ট্রেস রেকর্ড করতে পারেন এবং ANR ঘটলে মূল থ্রেডে কী চলছে তা আরও ভালভাবে বুঝতে Android Studio বা Perfetto ব্যবহার করে ট্রেস পরিদর্শন করতে পারেন। মনে রাখবেন যে JobScheduler API সরাসরি ব্যবহার করার সময় বা androidx লাইব্রেরি WorkManager ব্যবহার করার সময় এটি ঘটতে পারে।
#2 ঠিকানার জন্য, WorkManager- এ স্থানান্তরিত করার কথা বিবেচনা করুন, যা onStartJob বা onStopJob এ একটি অ্যাসিঙ্ক্রোনাস থ্রেডে যেকোনো প্রক্রিয়াকরণ মোড়ানোর জন্য সমর্থন প্রদান করে।
যদি setRequiredNetworkType বা setRequiredNetwork সীমাবদ্ধতা ব্যবহার করে তাহলে JobScheduler ACCESS_NETWORK_STATE অনুমতি ঘোষণা করার জন্য একটি প্রয়োজনীয়তাও প্রবর্তন করে। যদি আপনার অ্যাপটি কাজের সময়সূচী করার সময় ACCESS_NETWORK_STATE অনুমতি ঘোষণা না করে এবং Android 14 বা উচ্চতরকে লক্ষ্য করে, তাহলে এটি একটি SecurityException হবে।
টাইলস লঞ্চ API
14 এবং উচ্চতর টার্গেট করা অ্যাপ্লিকেশানগুলির জন্য, TileService#startActivityAndCollapse(Intent) বাতিল করা হয়েছে এবং এখন কল করার সময় একটি ব্যতিক্রম থ্রো করে৷ যদি আপনার অ্যাপটি টাইলস থেকে ক্রিয়াকলাপ চালু করে, তাহলে পরিবর্তে TileService#startActivityAndCollapse(PendingIntent) ব্যবহার করুন।
গোপনীয়তা
ছবি এবং ভিডিওতে আংশিক অ্যাক্সেস
অ্যান্ড্রয়েড 14 নির্বাচিত ফটো অ্যাক্সেস প্রবর্তন করে, যা ব্যবহারকারীদের একটি প্রদত্ত ধরণের সমস্ত মিডিয়াতে অ্যাক্সেস দেওয়ার পরিবর্তে তাদের লাইব্রেরিতে নির্দিষ্ট চিত্র এবং ভিডিওগুলিতে অ্যাপ্লিকেশনগুলিকে অ্যাক্সেস দেওয়ার অনুমতি দেয়।
আপনার অ্যাপটি Android 14 (API লেভেল 34) বা উচ্চতরকে লক্ষ্য করলেই এই পরিবর্তনটি সক্ষম হবে। আপনি যদি এখনও ফটো পিকার ব্যবহার না করেন, তাহলে আমরা কোনও স্টোরেজ অনুমতির অনুরোধ না করেই ব্যবহারকারীর গোপনীয়তা বাড়ায় এমন ছবি এবং ভিডিও নির্বাচন করার জন্য একটি সামঞ্জস্যপূর্ণ অভিজ্ঞতা প্রদানের জন্য এটিকে আপনার অ্যাপে প্রয়োগ করার পরামর্শ দিই।
আপনি যদি স্টোরেজ অনুমতিগুলি ব্যবহার করে আপনার নিজস্ব গ্যালারি পিকার বজায় রাখেন এবং আপনার বাস্তবায়নের উপর সম্পূর্ণ নিয়ন্ত্রণ বজায় রাখতে চান, তাহলে নতুন READ_MEDIA_VISUAL_USER_SELECTED অনুমতি ব্যবহার করতে আপনার বাস্তবায়ন মানিয়ে নিন । যদি আপনার অ্যাপটি নতুন অনুমতি ব্যবহার না করে, তাহলে সিস্টেমটি আপনার অ্যাপটিকে একটি সামঞ্জস্যপূর্ণ মোডে চালায়।
ব্যবহারকারীর অভিজ্ঞতা
পূর্ণ-স্ক্রিন ইন্টেন্ট বিজ্ঞপ্তিগুলি সুরক্ষিত করুন
Android 11 (API লেভেল 30) এর সাথে, ফোন লক থাকা অবস্থায় যেকোন অ্যাপের জন্য Notification.Builder.setFullScreenIntent ব্যবহার করে ফুল-স্ক্রিন ইন্টেন্ট পাঠানো সম্ভব ছিল। আপনি AndroidManifest-এ USE_FULL_SCREEN_INTENT অনুমতি ঘোষণা করে অ্যাপ ইনস্টলে এটি স্বয়ংক্রিয়ভাবে মঞ্জুর করতে পারেন।
পূর্ণ-স্ক্রীন অভিপ্রায় বিজ্ঞপ্তিগুলি ব্যবহারকারীর অবিলম্বে মনোযোগ দাবি করে অত্যন্ত উচ্চ-প্রধান বিজ্ঞপ্তিগুলির জন্য ডিজাইন করা হয়েছে, যেমন একটি ইনকামিং ফোন কল বা ব্যবহারকারীর দ্বারা কনফিগার করা অ্যালার্ম ঘড়ি সেটিংস। Android 14 (API লেভেল 34) বা উচ্চতর টার্গেট করা অ্যাপ্লিকেশানগুলির জন্য, যে অ্যাপগুলিকে এই অনুমতি ব্যবহার করার অনুমতি দেওয়া হয়েছে শুধুমাত্র সেইগুলির মধ্যেই সীমাবদ্ধ যেগুলি কলিং এবং অ্যালার্ম প্রদান করে৷ Google Play স্টোর ডিফল্ট USE_FULL_SCREEN_INTENT অনুমতি প্রত্যাহার করে যে কোনও অ্যাপ এই প্রোফাইলের সাথে খাপ খায় না৷ এই নীতি পরিবর্তনের সময়সীমা মে 31, 2024 ।
ব্যবহারকারী Android 14-এ আপডেট করার আগে ফোনে ইনস্টল করা অ্যাপগুলির জন্য এই অনুমতিটি সক্রিয় থাকে৷ ব্যবহারকারীরা এই অনুমতিটি চালু এবং বন্ধ করতে পারেন৷
আপনার অ্যাপটির অনুমতি আছে কিনা তা পরীক্ষা করতে আপনি নতুন API NotificationManager.canUseFullScreenIntent ব্যবহার করতে পারেন; যদি তা না হয়, আপনার অ্যাপটি সেটিংস পৃষ্ঠা চালু করতে নতুন অভিপ্রায় ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT ব্যবহার করতে পারে যেখানে ব্যবহারকারীরা অনুমতি দিতে পারেন।
নিরাপত্তা
অন্তর্নিহিত এবং মুলতুবি উদ্দেশ্যের উপর বিধিনিষেধ
অ্যান্ড্রয়েড 14 (এপিআই লেভেল 34) বা উচ্চতরকে টার্গেট করা অ্যাপগুলির জন্য, অ্যান্ড্রয়েড নিম্নলিখিত উপায়ে অভ্যন্তরীণ অ্যাপ উপাদানগুলিতে অন্তর্নিহিত উদ্দেশ্য পাঠানো থেকে অ্যাপগুলিকে সীমাবদ্ধ করে:
- অন্তর্নিহিত উদ্দেশ্যগুলি শুধুমাত্র রপ্তানি করা উপাদানগুলিতে বিতরণ করা হয়। অ্যাপ্লিকেশানগুলিকে হয় অরপ্তানি না হওয়া উপাদানগুলিতে সরবরাহ করার জন্য একটি সুস্পষ্ট অভিপ্রায় ব্যবহার করতে হবে, অথবা উপাদানটিকে রপ্তানি করা হিসাবে চিহ্নিত করতে হবে৷
- যদি একটি অ্যাপ এমন একটি অভিপ্রায়ের সাথে একটি পরিবর্তনযোগ্য মুলতুবি অভিপ্রায় তৈরি করে যা একটি উপাদান বা প্যাকেজ নির্দিষ্ট করে না, তবে সিস্টেমটি একটি ব্যতিক্রম নিক্ষেপ করে৷
এই পরিবর্তনগুলি দূষিত অ্যাপগুলিকে একটি অ্যাপের অভ্যন্তরীণ উপাদানগুলির দ্বারা ব্যবহারের উদ্দেশ্যে করা অন্তর্নিহিত উদ্দেশ্যগুলিকে বাধা দিতে বাধা দেয়৷
উদাহরণস্বরূপ, এখানে একটি অভিপ্রায় ফিল্টার রয়েছে যা আপনার অ্যাপের ম্যানিফেস্ট ফাইলে ঘোষণা করা যেতে পারে:
<activity
android:name=".AppActivity"
android:exported="false">
<intent-filter>
<action android:name="com.example.action.APP_ACTION" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
যদি আপনার অ্যাপ একটি অন্তর্নিহিত উদ্দেশ্য ব্যবহার করে এই কার্যকলাপটি চালু করার চেষ্টা করে, তাহলে একটি ActivityNotFoundException ব্যতিক্রম নিক্ষেপ করা হবে:
কোটলিন
// Throws an ActivityNotFoundException exception when targeting Android 14. context.startActivity(Intent("com.example.action.APP_ACTION"))
জাভা
// Throws an ActivityNotFoundException exception when targeting Android 14. context.startActivity(new Intent("com.example.action.APP_ACTION"));
অ-রপ্তানি ক্রিয়াকলাপ চালু করতে, আপনার অ্যাপের পরিবর্তে একটি স্পষ্ট অভিপ্রায় ব্যবহার করা উচিত:
কোটলিন
// This makes the intent explicit. val explicitIntent = Intent("com.example.action.APP_ACTION") explicitIntent.apply { package = context.packageName } context.startActivity(explicitIntent)
জাভা
// This makes the intent explicit. Intent explicitIntent = new Intent("com.example.action.APP_ACTION") explicitIntent.setPackage(context.getPackageName()); context.startActivity(explicitIntent);
রানটাইম-নিবন্ধিত সম্প্রচার রিসিভারগুলিকে অবশ্যই রপ্তানি আচরণ নির্দিষ্ট করতে হবে
অ্যাপ্লিকেশান এবং পরিষেবাগুলি যেগুলি Android 14 (API স্তর 34) বা উচ্চতরকে লক্ষ্য করে এবং প্রসঙ্গ-নিবন্ধিত রিসিভারগুলি ব্যবহার করে তা নির্দেশ করার জন্য একটি পতাকা নির্দিষ্ট করতে হবে যে রিসিভারটিকে ডিভাইসের অন্যান্য সমস্ত অ্যাপে রপ্তানি করা উচিত কিনা: যথাক্রমে RECEIVER_EXPORTED বা RECEIVER_NOT_EXPORTED . এই প্রয়োজনীয়তাটি Android 13-এ প্রবর্তিত এই রিসিভারগুলির জন্য বৈশিষ্ট্যগুলি ব্যবহার করে সুরক্ষা দুর্বলতা থেকে অ্যাপগুলিকে রক্ষা করতে সহায়তা করে৷
শুধুমাত্র সিস্টেম সম্প্রচার গ্রহণকারী রিসিভারদের জন্য ব্যতিক্রম
আপনার অ্যাপ যদি Context#registerReceiver Context#registerReceiver() এর মতো সিস্টেম সম্প্রচারের জন্য শুধুমাত্র একটি রিসিভার নিবন্ধন করে থাকে, তাহলে রিসিভার নিবন্ধন করার সময় এটি একটি পতাকা নির্দিষ্ট করবে না।
নিরাপদ গতিশীল কোড লোডিং
যদি আপনার অ্যাপটি Android 14 (API লেভেল 34) বা উচ্চতরকে টার্গেট করে এবং ডায়নামিক কোড লোডিং (DCL) ব্যবহার করে, তবে সমস্ত গতিশীল-লোড করা ফাইলগুলিকে শুধুমাত্র পঠনযোগ্য হিসাবে চিহ্নিত করতে হবে। অন্যথায়, সিস্টেম একটি ব্যতিক্রম নিক্ষেপ. আমরা সুপারিশ করি যে যখনই সম্ভব অ্যাপগুলিকে গতিশীলভাবে কোড লোড করা এড়িয়ে চলুন , কারণ এটি করার ফলে কোড ইনজেকশন বা কোড টেম্পারিং দ্বারা একটি অ্যাপের সাথে আপস করা হওয়ার ঝুঁকি অনেক বেড়ে যায়।
যদি আপনাকে গতিশীলভাবে কোড লোড করতে হয়, ফাইলটি খোলার সাথে সাথে এবং কোনো বিষয়বস্তু লেখার আগে গতিশীলভাবে লোড করা ফাইল (যেমন একটি DEX, JAR বা APK ফাইল) শুধুমাত্র পঠনযোগ্য হিসাবে সেট করতে নিম্নলিখিত পদ্ধতিটি ব্যবহার করুন:
কোটলিন
val jar = File("DYNAMICALLY_LOADED_FILE.jar") val os = FileOutputStream(jar) os.use { // Set the file to read-only first to prevent race conditions jar.setReadOnly() // Then write the actual file content } val cl = PathClassLoader(jar, parentClassLoader)
জাভা
File jar = new File("DYNAMICALLY_LOADED_FILE.jar"); try (FileOutputStream os = new FileOutputStream(jar)) { // Set the file to read-only first to prevent race conditions jar.setReadOnly(); // Then write the actual file content } catch (IOException e) { ... } PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);
গতিশীল-লোড করা ফাইলগুলি পরিচালনা করুন যা ইতিমধ্যেই বিদ্যমান
বিদ্যমান গতিশীলভাবে লোড করা ফাইলগুলির জন্য ব্যতিক্রমগুলি ছুঁড়ে ফেলা থেকে প্রতিরোধ করার জন্য, আমরা আপনার অ্যাপে আবার গতিশীলভাবে লোড করার চেষ্টা করার আগে ফাইলগুলি মুছে ফেলা এবং পুনরায় তৈরি করার পরামর্শ দিই৷ আপনি ফাইলগুলি পুনরায় তৈরি করার সময়, লেখার সময় ফাইলগুলিকে শুধুমাত্র পঠনযোগ্য চিহ্নিত করার জন্য পূর্ববর্তী নির্দেশিকা অনুসরণ করুন। বিকল্পভাবে, আপনি বিদ্যমান ফাইলগুলিকে শুধুমাত্র-পঠন হিসাবে পুনরায় লেবেল করতে পারেন, তবে এই ক্ষেত্রে, আমরা দৃঢ়ভাবে সুপারিশ করি যে আপনি প্রথমে ফাইলগুলির অখণ্ডতা যাচাই করুন (উদাহরণস্বরূপ, একটি বিশ্বস্ত মানের বিপরীতে ফাইলের স্বাক্ষর চেক করে), সুরক্ষায় সহায়তা করতে দূষিত কর্ম থেকে আপনার অ্যাপ্লিকেশন.
পটভূমি থেকে কার্যক্রম শুরু করার উপর অতিরিক্ত বিধিনিষেধ
অ্যান্ড্রয়েড 14 (এপিআই লেভেল 34) বা উচ্চতর টার্গেট করা অ্যাপগুলির জন্য, যখন অ্যাপগুলিকে ব্যাকগ্রাউন্ড থেকে ক্রিয়াকলাপ শুরু করার অনুমতি দেওয়া হয় তখন সিস্টেমটি আরও সীমাবদ্ধ করে:
- যখন একটি অ্যাপ
PendingIntent#send()বা অনুরূপ পদ্ধতি ব্যবহার করে একটিPendingIntentপাঠায়, অ্যাপটিকে অবশ্যই বেছে নিতে হবে যদি এটি মুলতুবি থাকা অভিপ্রায় শুরু করার জন্য নিজস্ব ব্যাকগ্রাউন্ড অ্যাক্টিভিটি লঞ্চের সুবিধা দিতে চায়। নির্বাচন করতে, অ্যাপটিকেsetPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)সহ একটিActivityOptionsবান্ডেল পাস করতে হবে। - যখন একটি দৃশ্যমান অ্যাপ
bindService()পদ্ধতি ব্যবহার করে ব্যাকগ্রাউন্ডে থাকা অন্য অ্যাপের একটি পরিষেবাকে আবদ্ধ করে, তখন দৃশ্যমান অ্যাপটিকে অবশ্যই বেছে নিতে হবে যদি এটি আবদ্ধ পরিষেবাতে তার নিজস্ব ব্যাকগ্রাউন্ড কার্যকলাপ লঞ্চের সুবিধা দিতে চায়। নির্বাচন করার জন্য,bindService()পদ্ধতিতে কল করার সময় অ্যাপটিতেBIND_ALLOW_ACTIVITY_STARTSপতাকা অন্তর্ভুক্ত করা উচিত।
এই পরিবর্তনগুলি ব্যাকগ্রাউন্ড থেকে ব্যাঘাতমূলক ক্রিয়াকলাপ শুরু করার জন্য API-এর অপব্যবহার থেকে ক্ষতিকারক অ্যাপগুলিকে প্রতিরোধ করে ব্যবহারকারীদের সুরক্ষার জন্য বিদ্যমান বিধিনিষেধের সেটকে প্রসারিত করে৷
জিপ পাথ ট্রাভার্সাল
Android 14 (API লেভেল 34) বা উচ্চতর টার্গেট করা অ্যাপগুলির জন্য, Android নিম্নলিখিত উপায়ে Zip Path Traversal Vulnerability রোধ করে: ZipFile(String) এবং ZipInputStream.getNextEntry() একটি ZipException থ্রো করে যদি জিপ ফাইলের এন্ট্রি নামগুলিতে ".." থাকে বা শুরু হয় "/" দিয়ে।
অ্যাপগুলি dalvik.system.ZipPathValidator.clearCallback() কল করে এই বৈধতা থেকে অপ্ট-আউট করতে পারে৷
প্রতিটি মিডিয়াপ্রোজেকশন ক্যাপচার সেশনের জন্য ব্যবহারকারীর সম্মতি প্রয়োজন
Android 14 (API লেভেল 34) বা উচ্চতর টার্গেট করা অ্যাপগুলির জন্য, MediaProjection#createVirtualDisplay দ্বারা নিম্নলিখিত পরিস্থিতিতে যেকোন একটিতে একটি SecurityException নিক্ষেপ করা হয়:
- আপনার অ্যাপটি
MediaProjectionManager#createScreenCaptureIntentথেকে ফেরত আসাIntentক্যাশ করে এবং এটি একাধিকবারMediaProjectionManager#getMediaProjectionএ পাস করে। - আপনার অ্যাপ একই
MediaProjectionদৃষ্টান্তে একাধিকবারMediaProjection#createVirtualDisplayআহ্বান করে।
প্রতিটি ক্যাপচার সেশনের আগে আপনার অ্যাপ ব্যবহারকারীকে সম্মতি দিতে বলতে হবে। একটি একক ক্যাপচার সেশন হল MediaProjection#createVirtualDisplay এ একটি একক আহ্বান, এবং প্রতিটি MediaProjection দৃষ্টান্ত শুধুমাত্র একবার ব্যবহার করতে হবে।
কনফিগারেশন পরিবর্তন হ্যান্ডেল
কনফিগারেশন পরিবর্তনগুলি (যেমন স্ক্রিন ওরিয়েন্টেশন বা স্ক্রীনের আকার পরিবর্তন) পরিচালনা করার জন্য যদি আপনার অ্যাপটিকে MediaProjection#createVirtualDisplay চালু করতে হয়, তাহলে আপনি বিদ্যমান MediaProjection উদাহরণের জন্য VirtualDisplay আপডেট করতে এই পদক্ষেপগুলি অনুসরণ করতে পারেন:
- নতুন প্রস্থ এবং উচ্চতার সাথে
VirtualDisplay#resizeকরুন। -
VirtualDisplay#setSurfaceএ নতুন প্রস্থ এবং উচ্চতা সহ একটি নতুনSurfaceপ্রদান করুন।
একটি কলব্যাক নিবন্ধন করুন
যে ক্ষেত্রে ব্যবহারকারী ক্যাপচার সেশন চালিয়ে যাওয়ার জন্য সম্মতি দেন না সেগুলি পরিচালনা করতে আপনার অ্যাপের একটি কলব্যাক নিবন্ধন করা উচিত। এটি করার জন্য, Callback#onStop প্রয়োগ করুন এবং আপনার অ্যাপকে যেকোনো সম্পর্কিত সংস্থান (যেমন VirtualDisplay এবং Surface ) প্রকাশ করতে দিন।
যদি আপনার অ্যাপ এই কলব্যাকটি নিবন্ধন না করে, MediaProjection#createVirtualDisplay একটি IllegalStateException নিক্ষেপ করে যখন আপনার অ্যাপ এটিকে আহ্বান করে।
আপডেট করা নন-SDK বিধিনিষেধ
অ্যান্ড্রয়েড ১৪-তে অ্যান্ড্রয়েড ডেভেলপারদের সাথে সহযোগিতা এবং সর্বশেষ অভ্যন্তরীণ পরীক্ষার উপর ভিত্তি করে সীমাবদ্ধ নন-SDK ইন্টারফেসের আপডেট করা তালিকা অন্তর্ভুক্ত রয়েছে। যখনই সম্ভব, আমরা নিশ্চিত করি যে নন-SDK ইন্টারফেস সীমাবদ্ধ করার আগে সর্বজনীন বিকল্পগুলি উপলব্ধ রয়েছে।
যদি আপনার অ্যাপটি Android 14-কে টার্গেট না করে, তাহলে এই পরিবর্তনগুলির কিছু তাৎক্ষণিকভাবে আপনার উপর প্রভাব ফেলতে পারে না। তবে, যদিও আপনি বর্তমানে কিছু নন-SDK ইন্টারফেস ব্যবহার করতে পারেন ( আপনার অ্যাপের টার্গেট API স্তরের উপর নির্ভর করে ), যেকোনো নন-SDK পদ্ধতি বা ক্ষেত্র ব্যবহার করলে আপনার অ্যাপটি ভেঙে যাওয়ার ঝুঁকি সবসময় বেশি থাকে।
যদি আপনার অ্যাপটি নন-SDK ইন্টারফেস ব্যবহার করে কিনা তা নিশ্চিত না হন, তাহলে আপনি আপনার অ্যাপটি পরীক্ষা করে দেখতে পারেন। যদি আপনার অ্যাপ নন-SDK ইন্টারফেসের উপর নির্ভর করে, তাহলে আপনার SDK বিকল্পগুলিতে মাইগ্রেশনের পরিকল্পনা শুরু করা উচিত। তবুও, আমরা বুঝতে পারি যে কিছু অ্যাপের নন-SDK ইন্টারফেস ব্যবহারের জন্য বৈধ ব্যবহারের ক্ষেত্রে রয়েছে। যদি আপনি আপনার অ্যাপে কোনও বৈশিষ্ট্যের জন্য নন-SDK ইন্টারফেস ব্যবহারের বিকল্প খুঁজে না পান, তাহলে আপনার একটি নতুন পাবলিক API অনুরোধ করা উচিত।
অ্যান্ড্রয়েডের এই প্রকাশের পরিবর্তনগুলি সম্পর্কে আরও জানতে, Android 14-এ নন-SDK ইন্টারফেস সীমাবদ্ধতার আপডেটগুলি দেখুন। সাধারণত নন-SDK ইন্টারফেস সম্পর্কে আরও জানতে, নন-SDK ইন্টারফেসের উপর সীমাবদ্ধতা দেখুন।