আচরণের পরিবর্তন: 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 আপডেট

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 IllegalArgumentException is thrown by the java.util.regex.Matcher class, so make sure to test your app for areas that use regular expressions. To enable or disable this change while testing, toggle the DISALLOW_INVALID_GROUP_REFERENCE flag 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 an IllegalArgumentException during deserialization. To enable or disable this change while testing, toggle the ENABLE_STRICT_VALIDATION flag using the compatibility framework tools.
  • ProGuard issues: In some cases, the addition of the java.lang.ClassValue class 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 whether Class.forName("java.lang.ClassValue") returns a class or not. If your app was developed against an older version of the runtime without the java.lang.ClassValue class available, then these optimizations might remove the computeValue method from classes derived from java.lang.ClassValue.

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

Since its introduction, JobScheduler expects your app to return from onStartJob or onStopJob within a few seconds. Prior to Android 14, if a job runs too long, the job is stopped and fails silently. If your app targets Android 14 (API level 34) or higher and exceeds the granted time on the main thread, the app triggers an ANR with the error message "No response to onStartJob" or "No response to onStopJob".

This ANR may be a result of 2 scenarios: 1. There is work blocking the main thread, preventing the callbacks onStartJob or onStopJob from executing and completing within the expected time limit. 2. The developer is running blocking work within the JobScheduler callback onStartJob or onStopJob, preventing the callback from completing within the expected time limit.

To address #1, you will need to further debug what is blocking the main thread when the ANR occurs, you can do this using ApplicationExitInfo#getTraceInputStream() to get the tombstone trace when the ANR occurs. If you're able to manually reproduce the ANR, you can record a system trace and inspect the trace using either Android Studio or Perfetto to better understand what is running on the main thread when the ANR occurs. Note that this can happen when using JobScheduler API directly or using the androidx library WorkManager.

To address #2, consider migrating to WorkManager, which provides support for wrapping any processing in onStartJob or onStopJob in an asynchronous thread.

JobScheduler also introduces a requirement to declare the ACCESS_NETWORK_STATE permission if using setRequiredNetworkType or setRequiredNetwork constraint. If your app does not declare the ACCESS_NETWORK_STATE permission when scheduling the job and is targeting Android 14 or higher, it will result in a 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 নিক্ষেপ করা হয়:

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

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

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

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