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

পূর্ববর্তী রিলিজের মতো, 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 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 ব্যবহার করতে পারে যেখানে ব্যবহারকারীরা অনুমতি দিতে পারেন।

নিরাপত্তা

অন্তর্নিহিত এবং মুলতুবি অভিপ্রায়ে সীমাবদ্ধতা

For apps targeting Android 14 (API level 34) or higher, Android restricts apps from sending implicit intents to internal app components in the following ways:

  • Implicit intents are only delivered to exported components. Apps must either use an explicit intent to deliver to unexported components, or mark the component as exported.
  • If an app creates a mutable pending intent with an intent that doesn't specify a component or package, the system throws an exception.

These changes prevent malicious apps from intercepting implicit intents that are intended for use by an app's internal components.

For example, here is an intent filter that could be declared in your app's manifest file:

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

If your app tried to launch this activity using an implicit intent, an ActivityNotFoundException exception would be thrown:

Kotlin

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(Intent("com.example.action.APP_ACTION"))

Java

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(new Intent("com.example.action.APP_ACTION"));

To launch the non-exported activity, your app should use an explicit intent instead:

Kotlin

// This makes the intent explicit.
val explicitIntent =
        Intent("com.example.action.APP_ACTION")
explicitIntent.apply {
    package = context.packageName
}
context.startActivity(explicitIntent)

Java

// This makes the intent explicit.
Intent explicitIntent =
        new Intent("com.example.action.APP_ACTION")
explicitIntent.setPackage(context.getPackageName());
context.startActivity(explicitIntent);

রানটাইম-নিবন্ধিত ব্রডকাস্ট রিসিভারদের অবশ্যই রপ্তানি আচরণ নির্দিষ্ট করতে হবে

Apps and services that target Android 14 (API level 34) or higher and use context-registered receivers are required to specify a flag to indicate whether or not the receiver should be exported to all other apps on the device: either RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED, respectively. This requirement helps protect apps from security vulnerabilities by leveraging the features for these receivers introduced in Android 13.

Exception for receivers that receive only system broadcasts

If your app is registering a receiver only for system broadcasts through Context#registerReceiver methods, such as Context#registerReceiver(), then it shouldn't specify a flag when registering the receiver.

নিরাপদ ডায়নামিক কোড লোড হচ্ছে

যদি আপনার অ্যাপটি 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 নিক্ষেপ করা হয়:

প্রতিটি ক্যাপচার সেশনের আগে আপনার অ্যাপ ব্যবহারকারীকে সম্মতি দিতে বলতে হবে। একটি একক ক্যাপচার সেশন হল MediaProjection#createVirtualDisplay এ একটি একক আহ্বান, এবং প্রতিটি MediaProjection দৃষ্টান্ত শুধুমাত্র একবার ব্যবহার করতে হবে।

কনফিগারেশন পরিবর্তন হ্যান্ডেল

কনফিগারেশন পরিবর্তনগুলি (যেমন স্ক্রিন ওরিয়েন্টেশন বা স্ক্রীনের আকার পরিবর্তন) পরিচালনা করার জন্য যদি আপনার অ্যাপটিকে MediaProjection#createVirtualDisplay চালু করতে হয়, তাহলে আপনি বিদ্যমান MediaProjection উদাহরণের জন্য VirtualDisplay আপডেট করতে এই পদক্ষেপগুলি অনুসরণ করতে পারেন:

  1. নতুন প্রস্থ এবং উচ্চতার সাথে VirtualDisplay#resize করুন।
  2. VirtualDisplay#setSurface এ নতুন প্রস্থ এবং উচ্চতা সহ একটি নতুন Surface প্রদান করুন।

একটি কলব্যাক নিবন্ধন করুন

যে ক্ষেত্রে ব্যবহারকারী ক্যাপচার সেশন চালিয়ে যাওয়ার জন্য সম্মতি দেন না সেগুলি পরিচালনা করতে আপনার অ্যাপের একটি কলব্যাক নিবন্ধন করা উচিত। এটি করার জন্য, Callback#onStop প্রয়োগ করুন এবং আপনার অ্যাপকে যেকোনো সম্পর্কিত সংস্থান (যেমন VirtualDisplay এবং Surface ) প্রকাশ করতে দিন।

যদি আপনার অ্যাপ এই কলব্যাকটি নিবন্ধন না করে, MediaProjection#createVirtualDisplay একটি IllegalStateException নিক্ষেপ করে যখন আপনার অ্যাপ এটিকে আহ্বান করে।

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

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

যদি আপনার অ্যাপ অ্যান্ড্রয়েড 14 কে টার্গেট না করে, তবে এই পরিবর্তনগুলির মধ্যে কিছু আপনাকে অবিলম্বে প্রভাবিত করতে পারে না। যাইহোক, যদিও আপনি বর্তমানে কিছু নন-SDK ইন্টারফেস ব্যবহার করতে পারেন ( আপনার অ্যাপের টার্গেট API লেভেলের উপর নির্ভর করে ), যেকোন নন-SDK পদ্ধতি বা ক্ষেত্র ব্যবহার করলে সবসময় আপনার অ্যাপ ভাঙার উচ্চ ঝুঁকি থাকে।

আপনি যদি নিশ্চিত না হন যে আপনার অ্যাপ নন-SDK ইন্টারফেস ব্যবহার করে, তাহলে আপনি খুঁজে বের করতে আপনার অ্যাপ পরীক্ষা করতে পারেন। যদি আপনার অ্যাপ নন-SDK ইন্টারফেসের উপর নির্ভর করে, তাহলে আপনার SDK বিকল্পগুলিতে স্থানান্তরের পরিকল্পনা শুরু করা উচিত। তা সত্ত্বেও, আমরা বুঝি যে কিছু অ্যাপে নন-SDK ইন্টারফেস ব্যবহার করার জন্য বৈধ ব্যবহারের ক্ষেত্রে রয়েছে। আপনি যদি আপনার অ্যাপে একটি বৈশিষ্ট্যের জন্য একটি নন-SDK ইন্টারফেস ব্যবহার করার বিকল্প খুঁজে না পান তবে আপনাকে একটি নতুন সর্বজনীন API অনুরোধ করা উচিত।

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