আচরণের পরিবর্তন: Android 14 বা উচ্চতরকে লক্ষ্য করে এমন অ্যাপ

পূর্ববর্তী রিলিজের মতো, Android 14-এ এমন আচরণের পরিবর্তন অন্তর্ভুক্ত রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। নিম্নলিখিত আচরণ পরিবর্তনগুলি শুধুমাত্র Android 14 (API স্তর 34) বা উচ্চতরকে লক্ষ্য করে এমন অ্যাপগুলিতে প্রযোজ্য। যদি আপনার অ্যাপটি Android 14 বা তার বেশির দিকে লক্ষ্য করে থাকে, তাহলে প্রযোজ্য ক্ষেত্রে এই আচরণগুলিকে সঠিকভাবে সমর্থন করার জন্য আপনার অ্যাপটি সংশোধন করা উচিত।

অ্যাপ্লিকেশানের targetSdkVersion নির্বিশেষে Android 14 এ চলমান সমস্ত অ্যাপ্লিকেশানকে প্রভাবিত করে এমন আচরণের পরিবর্তনগুলির তালিকাটিও পর্যালোচনা করতে ভুলবেন না।

মূল কার্যকারিতা

ফোরগ্রাউন্ড পরিষেবার প্রকারগুলি প্রয়োজন৷

যদি আপনার অ্যাপটি Android 14 (API লেভেল 34) বা উচ্চতরকে টার্গেট করে, তাহলে এটিকে অবশ্যই আপনার অ্যাপের মধ্যে প্রতিটি ফোরগ্রাউন্ড পরিষেবার জন্য অন্তত একটি ফোরগ্রাউন্ড পরিষেবার ধরণ নির্দিষ্ট করতে হবে। আপনার একটি ফোরগ্রাউন্ড পরিষেবার ধরন বেছে নেওয়া উচিত যা আপনার অ্যাপের ব্যবহারের ক্ষেত্রে প্রতিনিধিত্ব করে। সিস্টেমটি ফোরগ্রাউন্ড পরিষেবাগুলি আশা করে যেগুলির একটি নির্দিষ্ট ধরণের একটি নির্দিষ্ট ব্যবহারের ক্ষেত্রে সন্তুষ্ট হয়।

যদি আপনার অ্যাপে ব্যবহারের ক্ষেত্রে এই ধরনের কোনোটির সাথে যুক্ত না হয়, তাহলে এটি দৃঢ়ভাবে সুপারিশ করা হয় যে আপনি WorkManager বা ব্যবহারকারী-সূচিত ডেটা স্থানান্তর কাজগুলি ব্যবহার করতে আপনার যুক্তি স্থানান্তর করুন৷

BluetoothAdapter-এ BLUETOOTH_CONNECT অনুমতির প্রয়োগ৷

Android 14 enforces the BLUETOOTH_CONNECT permission when calling the BluetoothAdapter getProfileConnectionState() method for apps targeting Android 14 (API level 34) or higher.

This method already required the BLUETOOTH_CONNECT permission, but it was not enforced. Make sure your app declares BLUETOOTH_CONNECT in your app's AndroidManifest.xml file as shown in the following snippet and check that a user has granted the permission before calling getProfileConnectionState.

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

OpenJDK 17 আপডেট

অ্যান্ড্রয়েড 14 অ্যাপ এবং প্ল্যাটফর্ম ডেভেলপারদের জন্য লাইব্রেরি আপডেট এবং জাভা 17 ভাষা সমর্থন উভয় সহ সর্বশেষ OpenJDK LTS রিলিজের বৈশিষ্ট্যগুলির সাথে সারিবদ্ধ করার জন্য Android এর মূল লাইব্রেরিগুলিকে রিফ্রেশ করার কাজ চালিয়ে যাচ্ছে।

এই পরিবর্তনগুলির মধ্যে কয়েকটি অ্যাপের সামঞ্জস্যকে প্রভাবিত করতে পারে:

  • রেগুলার এক্সপ্রেশনে পরিবর্তন : অবৈধ গ্রুপ রেফারেন্স এখন ওপেনজেডিকে-এর শব্দার্থবিদ্যাকে আরও ঘনিষ্ঠভাবে অনুসরণ করার জন্য অননুমোদিত। আপনি নতুন ক্ষেত্রে দেখতে পারেন যেখানে java.util.regex.Matcher ক্লাস দ্বারা একটি IllegalArgumentException নিক্ষেপ করা হয়েছে, তাই রেগুলার এক্সপ্রেশন ব্যবহার করে এমন এলাকাগুলির জন্য আপনার অ্যাপটি পরীক্ষা করা নিশ্চিত করুন। পরীক্ষা করার সময় এই পরিবর্তনটি সক্ষম বা অক্ষম করতে, সামঞ্জস্যপূর্ণ ফ্রেমওয়ার্ক সরঞ্জামগুলি ব্যবহার করে DISALLOW_INVALID_GROUP_REFERENCE পতাকা টগল করুন৷
  • UUID হ্যান্ডলিং : java.util.UUID.fromString() পদ্ধতিটি এখন ইনপুট আর্গুমেন্ট যাচাই করার সময় আরও কঠোর পরীক্ষা করে, তাই আপনি ডিসিরিয়ালাইজেশনের সময় একটি IllegalArgumentException দেখতে পারেন। পরীক্ষা করার সময় এই পরিবর্তনটি সক্ষম বা অক্ষম করতে, সামঞ্জস্যপূর্ণ ফ্রেমওয়ার্ক সরঞ্জামগুলি ব্যবহার করে ENABLE_STRICT_VALIDATION পতাকা টগল করুন৷
  • ProGuard সমস্যা : কিছু ক্ষেত্রে, java.lang.ClassValue ক্লাস যোগ করলে সমস্যা দেখা দেয় যদি আপনি ProGuard ব্যবহার করে আপনার অ্যাপকে সঙ্কুচিত, অস্পষ্ট এবং অপ্টিমাইজ করার চেষ্টা করেন। সমস্যাটি একটি Kotlin লাইব্রেরি থেকে উদ্ভূত হয় যা Class.forName("java.lang.ClassValue") ক্লাস ফেরত দেয় কি না তার উপর ভিত্তি করে রানটাইম আচরণ পরিবর্তন করে। যদি আপনার অ্যাপটি java.lang.ClassValue ক্লাস উপলব্ধ না থাকলে রানটাইমের একটি পুরানো সংস্করণের বিপরীতে তৈরি করা হয়, তাহলে এই অপ্টিমাইজেশনগুলি java.lang.ClassValue থেকে প্রাপ্ত ক্লাসগুলি থেকে computeValue পদ্ধতিটি সরিয়ে দিতে পারে।

JobScheduler কলব্যাক এবং নেটওয়ার্ক আচরণকে শক্তিশালী করে

এটির প্রবর্তনের পর থেকে, 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) ব্যবহার করুন।

গোপনীয়তা

ফটো এবং ভিডিও আংশিক অ্যাক্সেস

Android 14 introduces Selected Photos Access, which allows users to grant apps access to specific images and videos in their library, rather than granting access to all media of a given type.

This change is only enabled if your app targets Android 14 (API level 34) or higher. If you don't use the photo picker yet, we recommend implementing it in your app to provide a consistent experience for selecting images and videos that also enhances user privacy without having to request any storage permissions.

If you maintain your own gallery picker using storage permissions and need to maintain full control over your implementation, adapt your implementation to use the new READ_MEDIA_VISUAL_USER_SELECTED permission. If your app doesn't use the new permission, the system runs your app in a compatibility mode.

ব্যবহারকারীর অভিজ্ঞতা

পূর্ণ-স্ক্রীন ইন্টেন্ট বিজ্ঞপ্তিগুলি সুরক্ষিত করুন

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);

গতিশীল-লোড করা ফাইলগুলি পরিচালনা করুন যা ইতিমধ্যেই বিদ্যমান

বিদ্যমান গতিশীলভাবে লোড করা ফাইলগুলির জন্য ব্যতিক্রমগুলি ছুঁড়ে ফেলা থেকে প্রতিরোধ করার জন্য, আমরা আপনার অ্যাপে আবার গতিশীলভাবে লোড করার চেষ্টা করার আগে ফাইলগুলি মুছে ফেলা এবং পুনরায় তৈরি করার পরামর্শ দিই৷ আপনি ফাইলগুলি পুনরায় তৈরি করার সময়, লেখার সময় ফাইলগুলিকে শুধুমাত্র পঠনযোগ্য চিহ্নিত করার জন্য পূর্ববর্তী নির্দেশিকা অনুসরণ করুন। বিকল্পভাবে, আপনি বিদ্যমান ফাইলগুলিকে শুধুমাত্র-পঠন হিসাবে পুনরায় লেবেল করতে পারেন, তবে এই ক্ষেত্রে, আমরা দৃঢ়ভাবে সুপারিশ করি যে আপনি প্রথমে ফাইলগুলির অখণ্ডতা যাচাই করুন (উদাহরণস্বরূপ, একটি বিশ্বস্ত মানের বিপরীতে ফাইলের স্বাক্ষর চেক করে), সুরক্ষায় সহায়তা করতে দূষিত কর্ম থেকে আপনার অ্যাপ্লিকেশন.

ব্যাকগ্রাউন্ড থেকে কার্যক্রম শুরু করার অতিরিক্ত বিধিনিষেধ

For apps targeting Android 14 (API level 34) or higher, the system further restricts when apps are allowed to start activities from the background:

These changes expand the existing set of restrictions to protect users by preventing malicious apps from abusing APIs to start disruptive activities from the background.

জিপ পাথ ট্রাভার্সাল

Android 14 (API লেভেল 34) বা উচ্চতর টার্গেট করা অ্যাপগুলির জন্য, Android নিম্নলিখিত উপায়ে Zip Path Traversal Vulnerability রোধ করে: ZipFile(String) এবং ZipInputStream.getNextEntry() একটি ZipException থ্রো করে যদি জিপ ফাইলের এন্ট্রি নামগুলিতে ".." থাকে বা শুরু হয় "/" দিয়ে।

অ্যাপগুলি dalvik.system.ZipPathValidator.clearCallback() কল করে এই বৈধতা থেকে অপ্ট-আউট করতে পারে৷

For apps targeting Android 14 (API level 34) or higher, a SecurityException is thrown by MediaProjection#createVirtualDisplay in either of the following scenarios:

Your app must ask the user to give consent before each capture session. A single capture session is a single invocation on MediaProjection#createVirtualDisplay, and each MediaProjection instance must be used only once.

Handle configuration changes

If your app needs to invoke MediaProjection#createVirtualDisplay to handle configuration changes (such as the screen orientation or screen size changing), you can follow these steps to update the VirtualDisplay for the existing MediaProjection instance:

  1. Invoke VirtualDisplay#resize with the new width and height.
  2. Provide a new Surface with the new width and height to VirtualDisplay#setSurface.

Register a callback

Your app should register a callback to handle cases where the user doesn't grant consent to continue a capture session. To do this, implement Callback#onStop and have your app release any related resources (such as the VirtualDisplay and Surface).

If your app doesn't register this callback, MediaProjection#createVirtualDisplay throws an IllegalStateException when your app invokes it.

নন-SDK সীমাবদ্ধতা আপডেট করা হয়েছে

Android 14 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 14, some of these changes might not immediately affect you. However, while you can currently use some non-SDK interfaces (depending on your app's target API level), using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.

অ্যান্ড্রয়েডের এই প্রকাশের পরিবর্তনগুলি সম্পর্কে আরও জানতে, Android 14-এ নন-SDK ইন্টারফেস সীমাবদ্ধতার আপডেটগুলি দেখুন। সাধারণত নন-SDK ইন্টারফেস সম্পর্কে আরও জানতে, নন-SDK ইন্টারফেসের উপর সীমাবদ্ধতা দেখুন।