इस पेज का अनुवाद Cloud Translation API से किया गया है.

व्यवहार में बदलाव: Android 14 या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन

पिछले वर्शन की तरह ही, Android 14 में भी काम करने के तरीके में बदलाव किए गए हैं. इनसे आपके ऐप्लिकेशन पर असर पड़ सकता है. काम करने के तरीके में ये बदलाव, सिर्फ़ उन ऐप्लिकेशन पर लागू होते हैं जो Android 14 (एपीआई लेवल 34) या उसके बाद के वर्शन को टारगेट करते हैं. अगर आपका ऐप्लिकेशन Android 14 या उसके बाद के वर्शन को टारगेट करता है, तो आपको अपने ऐप्लिकेशन में बदलाव करने होंगे, ताकि ये बदलाव सही तरीके से काम कर सकें. हालांकि, ऐसा सिर्फ़ तब करें, जब ये बदलाव आपके ऐप्लिकेशन के लिए लागू हों.

ऐप्लिकेशन के काम करने के तरीके में हुए उन बदलावों की सूची भी देखना न भूलें जिनका असर, Android 14 पर काम करने वाले सभी ऐप्लिकेशन पर पड़ता है. भले ही, ऐप्लिकेशन का targetSdkVersion कुछ भी हो.

मुख्य फ़ंक्शन

फ़ोरग्राउंड सेवा के टाइप डालना ज़रूरी है

If your app targets Android 14 (API level 34) or higher, it must specify at least one foreground service type for each foreground service within your app. You should choose a foreground service type that represents your app's use case. The system expects foreground services that have a particular type to satisfy a particular use case.

If a use case in your app isn't associated with any of these types, it's strongly recommended that you migrate your logic to use WorkManager or user-initiated data transfer jobs.

BluetoothAdapter में BLUETOOTH_CONNECT की अनुमति लागू करना

Android 14, BluetoothAdapter getProfileConnectionState() तरीके को कॉल करते समय, BLUETOOTH_CONNECT अनुमति लागू करता है. ऐसा उन ऐप्लिकेशन के लिए किया जाता है जो Android 14 (एपीआई लेवल 34) या उसके बाद के वर्शन को टारगेट करते हैं.

इस तरीके के लिए, पहले से ही 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, कॉलबैक और नेटवर्क के व्यवहार को बेहतर बनाता है

शुरुआत के बाद से, JobScheduler को उम्मीद है कि आपका ऐप्लिकेशन onStartJob या onStopJob कुछ सेकंड में. Android 14 से पहले के वर्शन अगर कोई काम ज़्यादा समय तक चलता है, तो काम रुक जाता है और बिना किसी आवाज़ के पूरा नहीं हो पाता. अगर आपका ऐप्लिकेशन Android 14 (एपीआई लेवल 34) या उसके बाद के वर्शन को टारगेट करता है और मुख्य थ्रेड पर तय समय से ज़्यादा समय लेता है, तो ऐप्लिकेशन "onStartJob पर कोई जवाब नहीं" या "onStopJob पर कोई जवाब नहीं" गड़बड़ी मैसेज के साथ एएनआर को ट्रिगर करता है.

यह ANR, इन दो स्थितियों की वजह से हो सकता है: 1. मुख्य थ्रेड को ब्लॉक करने वाला कोई काम है, जिसकी वजह से कॉलबैक onStartJob या onStopJob तय समयसीमा के अंदर लागू नहीं हो पा रहे हैं और पूरे नहीं हो पा रहे हैं. 2. डेवलपर JobScheduler में ब्लॉक करने का काम चला रहा है onStartJob या onStopJob कॉलबैक, जो कॉलबैक को रोक रहा है तय समयसीमा में पूरा हो जाता है.

#1 को ठीक करने के लिए, आपको यह पता लगाना होगा कि एएनआर होने पर मुख्य थ्रेड को क्या ब्लॉक कर रहा है. एएनआर होने पर टॉम्बस्टोन ट्रैक पाने के लिए, ApplicationExitInfo#getTraceInputStream() का इस्तेमाल करें. अगर एएनआर को मैन्युअल तरीके से दोहराया जा सकता है, तो सिस्टम ट्रेस रिकॉर्ड किया जा सकता है. साथ ही, Android Studio या Perfetto का इस्तेमाल करके, ट्रेस की जांच की जा सकती है. इससे यह बेहतर तरीके से समझा जा सकता है कि एएनआर होने पर मुख्य थ्रेड पर क्या चल रहा है. ध्यान दें कि यह सीधे तौर पर JobScheduler API का इस्तेमाल करने या androidx लाइब्रेरी WorkManager का इस्तेमाल करने पर हो सकता है.

#2 को ठीक करने के लिए, WorkManager पर माइग्रेट करें. यह प्लैटफ़ॉर्म onStartJob या onStopJob में किसी भी प्रोसेसिंग को रैप करने के लिए सहायता एसिंक्रोनस थ्रेड में है.

JobScheduler में, setRequiredNetworkType या setRequiredNetwork कंस्ट्रेंट का इस्तेमाल करने पर, ACCESS_NETWORK_STATE अनुमति का एलान करने की ज़रूरत भी शामिल की गई है. अगर आपका ऐप्लिकेशन, टास्क शेड्यूल करते समय ACCESS_NETWORK_STATE अनुमति का एलान नहीं करता है और Android 14 या उसके बाद के वर्शन को टारगेट करता है, तो आपको SecurityException दिखेगा.

Tiles launch 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.

उपयोगकर्ता अनुभव

फ़ुल-स्क्रीन पर सूचनाएं दिखाने की सुविधा को सुरक्षित करना

With Android 11 (API level 30), it was possible for any app to use Notification.Builder.setFullScreenIntent to send full-screen intents while the phone is locked. You could auto-grant this on app install by declaring USE_FULL_SCREEN_INTENT permission in the AndroidManifest.

Full-screen intent notifications are designed for extremely high-priority notifications demanding the user's immediate attention, such as an incoming phone call or alarm clock settings configured by the user. For apps targeting Android 14 (API level 34) or higher, apps that are allowed to use this permission are limited to those that provide calling and alarms only. The Google Play Store revokes default USE_FULL_SCREEN_INTENT permissions for any apps that don't fit this profile. The deadline for these policy changes is May 31, 2024.

This permission remains enabled for apps installed on the phone before the user updates to Android 14. Users can turn this permission on and off.

You can use the new API NotificationManager.canUseFullScreenIntent to check if your app has the permission; if not, your app can use the new intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT to launch the settings page where users can grant the permission.

सुरक्षा

इंप्लिसिट और लंबित इंटेंट पर पाबंदियां

Android 14 (एपीआई लेवल 34) या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, Android, ऐप्लिकेशन के इंटरनल कॉम्पोनेंट को इंप्लिसिट इंटेंट भेजने से इन तरीकों से प्रतिबंधित करता है:

इंप्लिसिट इंटेंट सिर्फ़ एक्सपोर्ट किए गए कॉम्पोनेंट को डिलीवर किए जाते हैं. ऐप्लिकेशन को या तो एक्सपोर्ट नहीं किए गए कॉम्पोनेंट को डिलीवर करने के लिए, खास इंटेंट का इस्तेमाल करना चाहिए या कॉम्पोनेंट को एक्सपोर्ट किए गए के तौर पर मार्क करना चाहिए.
अगर कोई ऐप्लिकेशन, बदले जा सकने वाले PendingIntent को ऐसे इंटेंट के साथ बनाता है जिसमें किसी कॉम्पोनेंट या पैकेज के बारे में जानकारी नहीं दी गई है, तो सिस्टम में अपवाद दिखता है.

इन बदलावों से, नुकसान पहुंचाने वाले ऐप्लिकेशन को इंप्लिसिट इंटेंट को इंटरसेप्ट करने से रोका जा सकता है. इन इंटेंट का इस्तेमाल, ऐप्लिकेशन के इंटरनल कॉम्पोनेंट करते हैं.

उदाहरण के लिए, यहां एक इंटेंट फ़िल्टर दिया गया है, जिसे आपके ऐप्लिकेशन की मेनिफ़ेस्ट फ़ाइल में एलान किया जा सकता है:

<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 अपवाद दिखाया जाएगा:

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

एक्सपोर्ट नहीं की गई गतिविधि को लॉन्च करने के लिए, आपके ऐप्लिकेशन को एक्सप्लिसिट इंटेंट का इस्तेमाल करना चाहिए:

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

रनटाइम के दौरान रजिस्टर किए गए ब्रॉडकास्ट रिसीवर को एक्सपोर्ट के तरीके की जानकारी देनी होगी

Android 14 (एपीआई लेवल 34) या उसके बाद के वर्शन को टारगेट करने वाले और कॉन्टेक्स्ट के हिसाब से रजिस्टर किए गए रिसीवर का इस्तेमाल करने वाले ऐप्लिकेशन और सेवाओं को एक फ़्लैग तय करना होगा. इससे यह पता चलता है कि रिसीवर को डिवाइस पर मौजूद अन्य सभी ऐप्लिकेशन में एक्सपोर्ट किया जाना चाहिए या नहीं. इसके लिए, RECEIVER_EXPORTED या RECEIVER_NOT_EXPORTED में से कोई एक विकल्प चुना जा सकता है. इस ज़रूरी शर्त से, Android 13 में इन रिसीवर के लिए उपलब्ध सुविधाओं का फ़ायदा उठाकर, ऐप्लिकेशन को सुरक्षा से जुड़ी जोखिम से बचाने में मदद मिलती है.

सिर्फ़ सिस्टम ब्रॉडकास्ट पाने वाले लोगों के लिए अपवाद

अगर आपका ऐप्लिकेशन सिर्फ़ सिस्टम ब्रॉडकास्ट के लिए, Context#registerReceiver() जैसे Context#registerReceiver तरीकों से रिसीवर रजिस्टर कर रहा है, तो उसे रिसीवर रजिस्टर करते समय कोई फ़्लैग नहीं देना चाहिए.

डाइनैमिक कोड को सुरक्षित तरीके से लोड करना

अगर आपका ऐप्लिकेशन Android 14 (एपीआई लेवल 34) या उसके बाद के वर्शन को टारगेट करता है और डाइनैमिक कोड लोडिंग (डीसीएल) का इस्तेमाल करता है, तो डाइनैमिक तौर पर लोड की गई सभी फ़ाइलों को रीड-ओनली के तौर पर मार्क किया जाना चाहिए. ऐसा न करने पर, सिस्टम कोई अपवाद दिखाता है. हमारा सुझाव है कि ऐप्लिकेशन जब भी हो सके, डाइनैमिक तौर पर कोड लोड करने से बचें. ऐसा करने से, कोड इंजेक्शन या कोड में छेड़छाड़ करके ऐप्लिकेशन को हैक करने का जोखिम बहुत बढ़ जाता है.

अगर आपको कोड को डाइनैमिक तौर पर लोड करना है, तो डाइनैमिक तौर पर लोड की गई फ़ाइल (जैसे, dex, JAR या APK फ़ाइल) को फ़ाइल खुलने के तुरंत बाद और उसमें कोई कॉन्टेंट लिखने से पहले, रीड-ओनली के तौर पर सेट करने के लिए, यह तरीका अपनाएं:

Kotlin

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)

Java

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

पहले से मौजूद, डाइनैमिक तौर पर लोड होने वाली फ़ाइलों को मैनेज करना

डाइनैमिक तौर पर लोड होने वाली मौजूदा फ़ाइलों के लिए अपवादों को रोकने के लिए, हमारा सुझाव है कि आप अपने ऐप्लिकेशन में उन्हें फिर से डाइनैमिक तौर पर लोड करने से पहले, उन्हें मिटा दें और फिर से बनाएं. फ़ाइलों को फिर से बनाते समय, लिखने के समय उन्हें रीड-ओनली के तौर पर मार्क करने के लिए, ऊपर दिए गए निर्देशों का पालन करें. इसके अलावा, मौजूदा फ़ाइलों को फिर से रीड-ओनली के तौर पर लेबल किया जा सकता है. हालांकि, इस मामले में हमारा सुझाव है कि आप पहले फ़ाइलों की पुष्टि कर लें. उदाहरण के लिए, किसी भरोसेमंद वैल्यू के हिसाब से फ़ाइल के हस्ताक्षर की जांच करके. इससे, आपके ऐप्लिकेशन को नुकसान पहुंचाने वाली कार्रवाइयों से बचाने में मदद मिलेगी.

बैकग्राउंड से गतिविधियां शुरू करने पर लगी अतिरिक्त पाबंदियां

Android 14 (एपीआई लेवल 34) या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, सिस्टम ने बैकग्राउंड से गतिविधियां शुरू करने की अनुमति देने के समय पर और पाबंदी लगाई है:

जब कोई ऐप्लिकेशन PendingIntent#send() या मिलते-जुलते तरीकों का इस्तेमाल करके PendingIntent भेजता है, तो उसे ऑप्ट-इन करना होगा. ऐसा इसलिए, ताकि वह बैकग्राउंड में गतिविधि शुरू करने की अनुमतियां दे सके और बाकी बचे इंटेंट को शुरू कर सके. ऑप्ट-इन करने के लिए, ऐप्लिकेशन को setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED) के साथ ActivityOptions बंडल पास करना होगा.
जब कोई ऐप्लिकेशन, bindService() तरीके का इस्तेमाल करके, बैकग्राउंड में चल रहे किसी दूसरे ऐप्लिकेशन की सेवा को बांधता है, तो उसे अब ऑप्ट-इन करना होगा. ऐसा तब करना होगा, जब उसे बांधी गई सेवा को बैकग्राउंड में चल रही गतिविधि को लॉन्च करने की अनुमतियां देनी हों. ऑप्ट इन करने के लिए, ऐप्लिकेशन को bindService() तरीके को कॉल करते समय, BIND_ALLOW_ACTIVITY_STARTS फ़्लैग शामिल करना चाहिए.

इन बदलावों से, पाबंदियों के मौजूदा सेट को बढ़ाया गया है. इससे उपयोगकर्ताओं को सुरक्षित रखने के लिए, नुकसान पहुंचाने वाले ऐप्लिकेशन को बैकग्राउंड से परेशान करने वाली गतिविधियां शुरू करने के लिए, एपीआई का गलत इस्तेमाल करने से रोका जा सकेगा.

ज़िप पाथ ट्रेवर्सल

For apps targeting Android 14 (API level 34) or higher, Android prevents the Zip Path Traversal Vulnerability in the following way: ZipFile(String) and ZipInputStream.getNextEntry() throws a ZipException if zip file entry names contain ".." or start with "/".

Apps can opt-out from this validation by calling dalvik.system.ZipPathValidator.clearCallback().

Android 14 (एपीआई लेवल 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 टूल के अलावा अन्य चीज़ों पर लगी पाबंदियां अपडेट की गईं

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 के इस रिलीज़ में हुए बदलावों के बारे में ज़्यादा जानने के लिए, Android 14 में, SDK टूल के अलावा अन्य इंटरफ़ेस से जुड़ी पाबंदियों में हुए अपडेट देखें. आम तौर पर, SDK टूल के बाहर के इंटरफ़ेस के बारे में ज़्यादा जानने के लिए, SDK टूल के बाहर के इंटरफ़ेस पर लगी पाबंदियां देखें.

मुख्य फ़ंक्शन

फ़ोरग्राउंड सेवा के टाइप डालना ज़रूरी है

BluetoothAdapter में BLUETOOTH_CONNECT की अनुमति लागू करना

OpenJDK 17 के अपडेट

JobScheduler, कॉलबैक और नेटवर्क के व्यवहार को बेहतर बनाता है

Tiles launch API

निजता

फ़ोटो और वीडियो का कुछ ऐक्सेस

उपयोगकर्ता अनुभव

फ़ुल-स्क्रीन पर सूचनाएं दिखाने की सुविधा को सुरक्षित करना

सुरक्षा

इंप्लिसिट और लंबित इंटेंट पर पाबंदियां

Kotlin

Java

Kotlin

Java

रनटाइम के दौरान रजिस्टर किए गए ब्रॉडकास्ट रिसीवर को एक्सपोर्ट के तरीके की जानकारी देनी होगी

सिर्फ़ सिस्टम ब्रॉडकास्ट पाने वाले लोगों के लिए अपवाद

डाइनैमिक कोड को सुरक्षित तरीके से लोड करना

Kotlin

Java

पहले से मौजूद, डाइनैमिक तौर पर लोड होने वाली फ़ाइलों को मैनेज करना

बैकग्राउंड से गतिविधियां शुरू करने पर लगी अतिरिक्त पाबंदियां

ज़िप पाथ ट्रेवर्सल

MediaProjection के हर कैप्चर सेशन के लिए, उपयोगकर्ता की सहमति ज़रूरी है

कॉन्फ़िगरेशन के बदलावों को हैंडल करना

कॉलबैक रजिस्टर करना

SDK टूल के अलावा अन्य चीज़ों पर लगी पाबंदियां अपडेट की गईं