Android 9 के रिलीज़ नोट

इस पेज पर, Android 9 रिलीज़ की मुख्य सुविधाओं के बारे में खास जानकारी दी गई है. साथ ही, ज़्यादा जानकारी के लिए लिंक भी दिए गए हैं. सुविधा की खास जानकारी, इस साइट पर मौजूद दस्तावेज़ की जगह के हिसाब से व्यवस्थित की जाती है. सेक्शन को एक से दूसरी जगह ले जाने और नाम बदलने के बारे में जानने के लिए, अगस्त 2018 में साइट से जुड़े अपडेट देखें.

बनाएं

सामान्य सिस्टम इमेज (जीएसआई)

सामान्य सिस्टम इमेज (जीएसआई), Android डिवाइसों के लिए अडजस्ट किए गए कॉन्फ़िगरेशन वाली सिस्टम इमेज होती है. सामान्य सिस्टम इमेज (जीएसआई) में, Android 9 के साथ लॉन्च होने वाले डिवाइसों और Android 9 पर अपग्रेड होने वाले डिवाइसों के लिए, जीएसआई के बीच के अंतर की जानकारी शामिल होती है.

भवन निर्माण

हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल)

HIDL फ़्रेमवर्क के साथ पुराने सिस्टम के काम करने की सुविधा

HIDL फ़्रेमवर्क के पुराने सिस्टम के साथ काम करने की पुष्टि, फ़्रेमवर्क के पुराने सिस्टम के साथ काम करने की पुष्टि करने का एक तरीका है.

डाइनैमिक तौर पर उपलब्ध एचएएल

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

HIDL

HIDL MemoryBlock

HIDL MemoryBlock, hidl_memory, HIDL @1.0::IAllocator, और HIDL @1.0::IMapper पर बनाई गई एक ऐब्स्ट्रैक्ट लेयर है. इसे उन HIDL सेवाओं के लिए डिज़ाइन किया गया है जिनमें एक ही मेमोरी हेप को शेयर करने वाले कई मेमोरी ब्लॉक होते हैं.

डिवाइस ट्री ओवरले

कंप्रेस किए गए ओवरले

Android 9 और उसके बाद के वर्शन में, डिवाइस ट्री टेबल हेडर के वर्शन 1 का इस्तेमाल करते समय, डिवाइस ट्री ब्लॉब ओवरले (डीटीबीओ) इमेज में कंप्रेस किए गए ओवरले के लिए सहायता शामिल है.

डीटीओ से जुड़े अपडेट

Android 9 और उसके बाद के वर्शन के लिए ज़रूरी है कि बूटलोडर, डिवाइस ट्री ओवरले (डीटीओ) में बताई गई प्रॉपर्टी में बदलाव करने से पहले, यूनिफ़ाइड डिवाइस ट्री ब्लॉब को कर्नेल में पास करे.

डीटीबीओ इमेज हेडर का वर्शन

Android 9 और उसके बाद के वर्शन में, DTBO इमेज हेडर में वर्शन फ़ील्ड शामिल होता है.

डीटीबीओ की पुष्टि

Android 9 और उसके बाद के वर्शन के लिए, DTBO पार्टीशन की ज़रूरत होती है. SoC DT में नोड जोड़ने या प्रॉपर्टी में बदलाव करने के लिए, बूटलोडर को डिवाइस के हिसाब से DT को SoC DT पर डाइनैमिक तौर पर ओवरले करना होगा. ज़्यादा जानकारी के लिए, कंपाइल करना और पुष्टि करना लेख पढ़ें.

कर्नेल से जुड़ी शर्तों का पालन करना

Android 9 और इसके बाद के वर्शन में ऐसी ज़रूरी शर्तें शामिल हैं जिनका असर, कर्नेल, उसके इंटरफ़ेस, और डीटीबीओ के इस्तेमाल पर पड़ता है. ज़्यादा जानकारी के लिए, ये पेज देखें:

वेंडर NDK

डिज़ाइन में बदलाव

Android 9 और उसके बाद के वर्शन में, VNDK के डिज़ाइन में हुए बदलावों के बारे में जानने के लिए, ये पेज देखें:

एबीआई चेकर

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

वीएनडीके के स्नैपशॉट

सिस्टम इमेज, वीएनडीके स्नैपशॉट का इस्तेमाल करके, वेंडर इमेज को सही वीएनडीके लाइब्रेरी दे सकती है. भले ही, सिस्टम और वेंडर इमेज, Android के अलग-अलग वर्शन से बनाई गई हों.

वेंडर इंटरफ़ेस ऑब्जेक्ट (VINTF ऑब्जेक्ट)

वेंडर इंटरफ़ेस ऑब्जेक्ट सेक्शन में दिए गए इन पेजों पर, Android 9 और उसके बाद के वर्शन में हुए अपडेट के बारे में बताया गया है:

HIDL के बंद होने का शेड्यूल

यहां दिए गए पेजों पर, यह बताया गया है कि Android, HIDL HALs को कैसे बंद करता है और हटाता है:

बूटलोडर

प्रॉडक्ट विभाजन

Android 9 और उसके बाद के वर्शन में, Android बिल्ड सिस्टम का इस्तेमाल करके /product पार्टीशन बनाए जा सकते हैं. पहले, Android 8.x ने सिस्टम-ऑन-चिप (SoC) के हिसाब से बने कॉम्पोनेंट को /system से /vendor में अलग करने की सुविधा लागू की थी. हालांकि, इसमें Android बिल्ड सिस्टम से बने OEM के हिसाब से बने कॉम्पोनेंट के लिए जगह नहीं दी गई थी.

डिवाइस के कैननिकल बूट होने की वजह से जुड़ी शर्तों का पालन करना

बूट होने की वजह पेज पर, Android 9 और उसके बाद के वर्शन में, बूटलोडर के बूट होने की वजह से जुड़ी खास जानकारी में हुए बदलावों के बारे में बताया गया है.

सिस्टम को रूट के तौर पर

Android 9 और इसके बाद के वर्शन के साथ लॉन्च होने वाले सभी डिवाइसों के लिए, system-as-root का इस्तेमाल करना ज़रूरी है. यह ramdisk.img को system.img (इसे no-ramdisk भी कहा जाता है) में मर्ज करता है. इसके बाद, system.img को rootfs के तौर पर माउंट किया जाता है.

बूट इमेज हेडर का वर्शन

Android 9 और उसके बाद के वर्शन में, बूट इमेज हेडर में हेडर वर्शन दिखाने के लिए फ़ील्ड होता है. बूटलोडर को इस वर्शन फ़ील्ड की जांच करनी चाहिए और उसके हिसाब से हेडर को पार्स करना चाहिए.

रिकवरी में डीटीबीओ

नॉन-A/B डिवाइसों पर, रिकवरी इमेज और डीटीबीओ पार्टिशन के मेल न खाने की वजह से, ओटीए (ऑनलाइन ट्रांसफ़र) की प्रोसेस पूरी न होने से रोकने के लिए, रिकवरी इमेज में डीटीबीओ इमेज की जानकारी होनी चाहिए.

डिसप्ले

डिसप्ले कटआउट

डिसप्ले में कटआउट की सुविधा की मदद से, ऐप्लिकेशन डेवलपर शानदार और बेहतरीन अनुभव दे सकते हैं. साथ ही, डिवाइसों के सामने वाले हिस्से में ज़रूरी सेंसर के लिए जगह भी बची रहती है.

फ़ोटो घुमाने के सुझाव

Android 9 और इसके बाद के वर्शन में, स्क्रीन के रोटेशन के व्यवहार से जुड़े अपडेट किए गए हैं. इनमें, उपयोगकर्ता के लिए एक कंट्रोल जोड़ा गया है. इसकी मदद से, डिवाइस की पोज़िशन बदलने पर भी स्क्रीन को लैंडस्केप या पोर्ट्रेट मोड में पिन किया जा सकता है.

सिंक किए गए ऐप्लिकेशन ट्रांज़िशन

सिंक किए गए ऐप्लिकेशन ट्रांज़िशन की मदद से, ऐप्लिकेशन के नए ट्रांज़िशन एनिमेशन इस्तेमाल किए जा सकते हैं.

टेक्स्ट क्लासिफ़िकेशन (पहले इसे TEXTCLASSIFIER कहा जाता था)

Android 9 और इसके बाद के वर्शन में, टेक्स्ट की कैटगरी तय करने वाली सेवा शामिल होती है. यह टेक्स्ट की कैटगरी तय करने का सुझाया गया तरीका है. साथ ही, यह सेवा डिफ़ॉल्ट रूप से लागू होती है.

वाइड-गैमट कलर

Android 9 और उसके बाद के वर्शन में, वाइड-गैमट कलर की सुविधा काम करती है. इसमें ये शामिल हैं:

  • हाई डाइनैमिक रेंज (एचडीआर)
  • BT2020 कलर स्पेस में कॉन्टेंट को प्रोसेस करना, लेकिन एंड-टारगेट के तौर पर नहीं

वाइड-गैमट कलर का इस्तेमाल करने के लिए, डिवाइस का पूरा डिसप्ले स्टैक (जैसे, स्क्रीन, हार्डवेयर कमपोज़र, जीपीयू) वाइड-गैमट कलर या बफ़र फ़ॉर्मैट के साथ काम करना चाहिए. डिवाइसों को वाइड-गैमट कॉन्टेंट के साथ काम करने का दावा करने की ज़रूरत नहीं है. भले ही, उनका हार्डवेयर इस सुविधा के साथ काम करता हो. हालांकि, हार्डवेयर का पूरा फ़ायदा पाने के लिए, वाइड-गैमट कलर की सुविधा चालू होनी चाहिए. विज़ुअल अनुभव में अंतर से बचने के लिए, रनटाइम के दौरान वाइड-गैमट कलर को बंद नहीं किया जाना चाहिए.

इनके साथ काम करता है

Android के साथ काम करने की जानकारी देने वाला दस्तावेज़

Android 9 के लिए कंपैटबिलिटी डेफ़िनिशन डॉक्यूमेंट (सीडीडी) में, पिछले वर्शन के बारे में बताया गया है. इसमें नई सुविधाओं के अपडेट और पहले रिलीज़ किए गए फ़ंक्शन की ज़रूरी शर्तों में हुए बदलावों के बारे में जानकारी दी गई है.

सेटिंग

बेहतर ऐप्लिकेशन विजेट

Android ऐप्लिकेशन विजेट फ़्रेमवर्क, उपयोगकर्ता के इंटरैक्शन के बारे में ज़्यादा जानकारी देता है. खास तौर पर, जब कोई उपयोगकर्ता विजेट मिटाता है या मैन्युअल तरीके से जोड़ता है. यह सुविधा, Launcher3 में डिफ़ॉल्ट रूप से उपलब्ध होती है.

अगर डिवाइस बनाने वाली कंपनियों के लॉन्चर ऐप्लिकेशन, Launcher3 पर आधारित नहीं हैं, तो उन्हें इस सुविधा के साथ काम करने के लिए, अपने लॉन्चर ऐप्लिकेशन अपडेट करने होंगे. ये ऐप्लिकेशन, डिवाइसों के साथ शिप किए जाते हैं. OEM को अपने डिफ़ॉल्ट लॉन्चर में, नए widgetFeatures फ़ील्ड का इस्तेमाल करना होगा.

ध्यान दें कि यह सुविधा सिर्फ़ तब पूरी तरह से काम करती है, जब लॉन्चर इसे उम्मीद के मुताबिक लागू करते हैं. AOSP में, इसे लागू करने का एक सैंपल शामिल है. दिए गए सैंपल कोड के लिए, AOSP Change-Id Iccd6f965fa3d61992244a365efc242122292c0ca देखें.

पैकेज इंस्टॉलर को डिवाइस की स्थिति में हुए बदलाव की सूचनाएं

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

डिवाइस की स्थिति में हुए बदलाव की सूचना का सोर्स कोड, platform/frameworks/base में इन जगहों पर मौजूद है:

  • api/system-current.txt
  • core/java/android/content/Intent.java
  • core/res/AndroidManifest.xml
  • services/core/java/com/android/server/am/ActivityManagerService.java

इन्फ़ॉर्मेशन आर्किटेक्चर

Settings ऐप्लिकेशन के लिए जानकारी के आर्किटेक्चर में किए गए बदलावों से, ज़्यादा सुविधाएं मिलती हैं और उन्हें लागू करना आसान हो जाता है.

परीक्षण

Atest

Atest कमांड-लाइन टूल की मदद से, Android टेस्ट को स्थानीय तौर पर बनाया, इंस्टॉल, और चलाया जा सकता है. इससे, टेस्ट को फिर से चलाने में काफ़ी कम समय लगता है. इसके लिए, आपको Trade Federation टेस्ट हार्नेस कमांड-लाइन के विकल्पों के बारे में जानने की ज़रूरत नहीं होती.

Compatibility Test Suite

सीटीएस डाउनलोड

Android 9 के साथ काम करने वाले Compatibility Test Suite (CTS) पैकेज, CTS Downloads पेज पर उपलब्ध हैं. शामिल की गई जांचों के सोर्स कोड को, ओपन-सोर्स ट्री में android-cts-9.0_r1 टैग के साथ सिंक किया जा सकता है.

सीटीएस के विकल्प

Android 9 के लिए, CTS v2 में ये कमांड और आर्ग्युमेंट जोड़े गए हैं:

  • run retry उन सभी टेस्ट को फिर से चलाता है जो पिछले सेशन में पूरे नहीं हो पाए थे या जिन्हें पूरा नहीं किया गया था.
  • ‘--shard-count, एक से ज़्यादा डिवाइसों पर एक साथ चलाने के लिए, किसी सीटीएस को तय संख्या में अलग-अलग चंक में बांटता है.

इसके अलावा, पहले दस्तावेज़ में शामिल नहीं किया गया कमांड --retry-type को उसी CTS v2 कंसोल कमांड रेफ़रंस में जोड़ा गया है.

सिक्योर एलिमेंट (एसई) सेवा

सुरक्षित एलिमेंट सेवा, डिवाइसों में एसई एचएएल लागू होने की जानकारी देती है. इससे यह पता चलता है कि डिवाइसों में कितने सुरक्षित एलिमेंट हैं. साथ ही, यह भी पता चलता है कि वे सभी ग्लोबल प्लैटफ़ॉर्म के साथ काम करते हैं या नहीं. इसका इस्तेमाल, एपीआई और सुरक्षित एलिमेंट को लागू करने की जांच करने के लिए आधार के तौर पर किया जाता है.

सेंसर फ़्यूज़न बॉक्स

सेंसर फ़्यूज़न बॉक्स का इस्तेमाल, कैमरा इमेज टेस्ट सुइट (कैमरा ITS) के सेंसर फ़्यूज़न टेस्ट और एक से ज़्यादा कैमरों के सिंक टेस्ट में किया जाता है. साथ ही, यह Android फ़ोन के कैमरे और अन्य सेंसर के टाइमस्टैंप की सटीक जानकारी देने के लिए, टेस्ट का एक जैसा माहौल उपलब्ध कराता है. ज़्यादा जानकारी के लिए, ये पेज देखें:

वाइड फ़ील्ड ऑफ़ व्यू ITS-in-a-box

वाइड फ़ील्ड ऑफ़ व्यू ITS-in-a-box एक ऑटोमेटेड सिस्टम है. इसे कैमरा ITS में वाइड फ़ील्ड ऑफ़ व्यू (WFoV) और रेगुलर फ़ील्ड ऑफ़ व्यू (RFoV) कैमरा सिस्टम, दोनों की जांच करने के लिए डिज़ाइन किया गया है.

वेंडर टेस्ट सुइट

होस्ट कंट्रोलर का आर्किटेक्चर

Vendor Test Suite (VTS) होस्ट कंट्रोलर का आर्किटेक्चर, VTS टेस्ट फ़्रेमवर्क का आर्किटेक्चर है. इसे क्लाउड-आधारित टेस्ट-सेवा देने वाली सेवा के साथ इंटिग्रेट किया गया है.

सेवा के नाम के बारे में जानकारी रखने वाली एचएएल टेस्टिंग

VTS की सेवा के नाम के बारे में जानकारी देने वाली एचएएल टेस्टिंग, उस डिवाइस के आधार पर किसी दिए गए एचएएल इंस्टेंस की सेवा का नाम पाने की सुविधा देता है जिस पर VTS टेस्ट चल रहे हैं.

एचएएल की जांच की जा सकती है

VTS HAL की जांच में, डिवाइस कॉन्फ़िगरेशन का इस्तेमाल करने के लिए, रनटाइम का तरीका शामिल होता है. इससे यह पता चलता है कि उस डिवाइस टारगेट के लिए, कौनसी VTS जांच छोड़ी जानी चाहिए.

अपने-आप टेस्ट करने की सुविधा

अपने-आप टेस्ट करने की सुविधा, VTS का एक इंफ़्रास्ट्रक्चर है. इसका इस्तेमाल, AOSP की सामान्य सिस्टम इमेज (जीएसआई) पर काम करने वाले पार्टनर डिवाइसों पर, VTS, CTS या अन्य टेस्ट के लिए अपने-आप टेस्ट करने की सुविधा के तौर पर किया जाता है.

डीबग करना

ऐडवांस टेलीमेट्री

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

Android 9 में statsd टेलीमेट्री की सुविधा शामिल है. यह बेहतर डेटा को तेज़ी से इकट्ठा करके, इस कमी को ठीक करती है. statsd, ऐप्लिकेशन के इस्तेमाल, बैटरी, और प्रोसेस के आंकड़े इकट्ठा करता है. साथ ही, क्रैश की जानकारी भी इकट्ठा करता है. इस डेटा का विश्लेषण किया जाता है और इसका इस्तेमाल प्रॉडक्ट, हार्डवेयर, और सेवाओं को बेहतर बनाने के लिए किया जाता है.

ज़्यादा जानकारी के लिए, frameworks/base/cmds/statsd/ देखें.

सुरक्षा से जुड़ी सुविधाएं

ऐप पर हस्ताक्षर

APK सिग्नेचर स्कीम v3, APK की कुंजी के रोटेशन के साथ काम करता है.

बायोमेट्रिक से जुड़ी सहायता

Android 9 में पब्लिक क्लास BiometricPrompt शामिल है. इसका इस्तेमाल करके, ऐप्लिकेशन डिवाइस और मोड के हिसाब से, बायोमेट्रिक ऑथेंटिकेशन की सुविधा को इंटिग्रेट कर सकते हैं. BiometricPrompt को शामिल करने के लिए, अपने बायोमेट्रिक स्टैक को इंटिग्रेट करने के बारे में ज़्यादा जानने के लिए, बायोमेट्रिक्स देखें.

डाइनैमिक ऐनलिसिस

Android 9 में, एक्सप्लॉइट को कम करने और विश्लेषण करने वाले ज़्यादा टूल के लिए सहायता शामिल है.

कंट्रोल फ़्लो इंटिग्रिटी (CFI)

कंट्रोल फ़्लो इंटिग्रिटी (सीएफ़आई) एक सुरक्षा तंत्र है, जो किसी कंपाइल किए गए बाइनरी के ओरिजनल कंट्रोल फ़्लो ग्राफ़ में बदलाव करने से रोकता है. इससे, इस तरह के हमले करना काफ़ी मुश्किल हो जाता है.

Kernel CFI

Android 9 और इसके बाद के वर्शन में, डिफ़ॉल्ट रूप से चालू रहने वाले सिस्टम CFI के अलावा, कर्नल कंट्रोल फ़्लो इंटिग्रिटी (CFI) की सुविधा भी शामिल है.

एन्क्रिप्ट (सुरक्षित) करने का तरीका

अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका

अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका (एफ़बीई) को अपडेट किया गया है, ताकि यह अडॉप्टेबल स्टोरेज के साथ काम कर सके. नए डिवाइसों के लिए, पूरी ड्राइव को एन्क्रिप्ट करने के बजाय, अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका इस्तेमाल करना चाहिए.

मेटाडेटा एन्क्रिप्ट (सुरक्षित) करना

Android 9 और उसके बाद के वर्शन में, मेटाडेटा एन्क्रिप्शन की सुविधा उपलब्ध है. हालांकि, इसके लिए ज़रूरी है कि डिवाइस में हार्डवेयर की सुविधा उपलब्ध हो. मेटाडेटा एन्क्रिप्शन की सुविधा के तहत, बूट के समय मौजूद एक कुंजी, एन्क्रिप्ट नहीं किए गए कॉन्टेंट को एन्क्रिप्ट करने के लिए, फ़ाइल पर आधारित एन्क्रिप्शन का इस्तेमाल करती है.

कीस्टोर

Android 9 और इसके बाद के वर्शन में, Keymaster 4 शामिल है. इसमें ये सुविधाएं मौजूद हैं.

StrongBox

Android 9 और इसके बाद के वर्शन में, Android Keystore की कुंजियों के लिए सहायता शामिल है. इन्हें अलग से मौजूद सीपीयू में सेव और इस्तेमाल किया जाता है. यह सीपीयू, ज़्यादा सुरक्षा वाले ऐप्लिकेशन के लिए बनाया गया होता है. जैसे, एम्बेड किया गया सुरक्षित एलिमेंट (एसई). StrongBox Keymaster, अलग से सुरक्षित हार्डवेयर में Keymaster एचएएल को लागू करने का तरीका है. StrongBox में ये चीज़ें होती हैं:

  • डिस्क्रीट सीपीयू
  • सुरक्षित स्टोरेज की सुविधा
  • अच्छी क्वालिटी वाला ट्रू रैंडम नंबर जनरेटर
  • छेड़छाड़ से सुरक्षित पैकेजिंग
  • साइड-चैनल रेज़िस्टेंस

सुरक्षित पासकोड इंपोर्ट करना

Keymaster 4 में किसी कुंजी को सुरक्षित तरीके से इंपोर्ट करने के लिए, डिवाइस से बाहर बनाई गई कुंजी को एन्क्रिप्ट किया जाता है. साथ ही, उसमें अनुमतियों की जानकारी भी दी जाती है. इससे यह तय होता है कि कुंजी का इस्तेमाल कैसे किया जा सकता है.

3DES की सुविधा

Keymaster 4 में 3DES शामिल है, ताकि यह 3DES का इस्तेमाल करने वाले लेगसी सिस्टम के साथ काम कर सके.

वर्शन बाइंडिंग

Treble के मॉड्यूलर स्ट्रक्चर के साथ काम करने और system.img से boot.img की बाइंडिंग को तोड़ने के लिए, Keymaster 4 ने कीवर्ड वर्शन बाइंडिंग मॉडल को बदला, ताकि हर पार्टीशन के लिए अलग-अलग पैच लेवल हो सकें. इससे, हर पार्टीशन को अलग से अपडेट किया जा सकता है. साथ ही, रोलबैक की सुरक्षा भी मिलती रहती है.

Android Protected Confirmation API

Android 9 के साथ लॉन्च होने वाले डिवाइसों पर, डेवलपर Android Protected Confirmation API का इस्तेमाल कर सकते हैं. इस एपीआई की मदद से, ऐप्लिकेशन ConfirmationPrompt के किसी इंस्टेंस का इस्तेमाल करके, उपयोगकर्ता को एक प्रॉम्प्ट दिखा सकते हैं. इसमें, उपयोगकर्ता से किसी छोटे स्टेटमेंट को स्वीकार करने के लिए कहा जाता है. इस स्टेटमेंट की मदद से, ऐप्लिकेशन यह पुष्टि कर सकता है कि उपयोगकर्ता कोई संवेदनशील लेन-देन करना चाहता है. जैसे, पेमेंट करना.

SELinux

हर ऐप्लिकेशन के लिए SELinux सैंडबॉक्स

ऐप्लिकेशन सैंडबॉक्स में नई सुरक्षा और जांच के उदाहरण हैं. इससे यह पक्का किया जा सकेगा कि Android 9 और उसके बाद के वर्शन को टारगेट करने वाले सभी ऐप्लिकेशन, अलग-अलग SELinux सैंडबॉक्स में काम करें.

Treble SELinux में हुए बदलाव

Android 9 और इसके बाद के वर्शन में, Treble SELinux से जुड़े अपडेट के बारे में SELinux सेक्शन में कई पेजों पर जानकारी दी गई है.

वेंडर के लिए शुरू करना

वेंडर init, Treble सिस्टम/वेंडर के बंटवारे में मौजूद गड़बड़ी को ठीक करता है. इसके लिए, वह वेंडर के हिसाब से अनुमतियों के साथ /vendor कमांड चलाने के लिए, अलग से SELinux डोमेन का इस्तेमाल करता है.

सिस्टम प्रॉपर्टी

Android 9, सिस्टम प्रॉपर्टी को system और vendor के बीच शेयर करने पर पाबंदी लगाता है. ऐसा तब किया जाता है, जब ऐसा करना ज़रूरी न हो. साथ ही, शेयर की गई सिस्टम प्रॉपर्टी के बीच एक जैसी जानकारी देने का तरीका भी उपलब्ध कराता है.

SELinux एट्रिब्यूट की जांच

Android 9 में, बिल्ड के समय होने वाले नए टेस्ट शामिल हैं. इनसे यह पक्का किया जाता है कि खास जगहों पर मौजूद सभी फ़ाइलों में सही एट्रिब्यूट हों. उदाहरण के लिए, sysfs में मौजूद सभी फ़ाइलों में ज़रूरी sysfs_type एट्रिब्यूट है.

ऑडियो

हाई रिज़ॉल्यूशन वाले ऑडियो इफ़ेक्ट

हाई रिज़ॉल्यूशन वाले ऑडियो इफ़ेक्ट में हुए अपडेट में, इफ़ेक्ट प्रोसेसिंग को int16 से फ़्लोट फ़ॉर्मैट में बदलना शामिल है. साथ ही, एक साथ चलने वाले क्लाइंट आउटपुट ट्रैक, ज़्यादा से ज़्यादा क्लाइंट/सर्वर मेमोरी, और मिक्स किए गए कुल ट्रैक की संख्या में बढ़ोतरी हुई है.

कैमरा

बाहरी यूएसबी कैमरे

Android 9 और इसके बाद के वर्शन में, Android Camera2 API और कैमरा HIDL इंटरफ़ेस का इस्तेमाल करके, प्लग-ऐंड-प्ले यूएसबी कैमरे (यानी वेबकैम) का इस्तेमाल किया जा सकता है.

मोशन ट्रैकिंग

कैमरा डिवाइसों में, मोशन ट्रैकिंग की सुविधा का विज्ञापन दिखाया जा सकता है.

एक से ज़्यादा कैमरे इस्तेमाल करने की सुविधा

एक से ज़्यादा कैमरे इस्तेमाल करने की सुविधा में, एक से ज़्यादा कैमरे वाले डिवाइसों के लिए एपीआई की सुविधा शामिल होती है. यह सुविधा, एक नए लॉजिकल कैमरा डिवाइस के ज़रिए मिलती है. यह डिवाइस, एक ही दिशा में फ़ोकस करने वाले दो या उससे ज़्यादा फ़िज़िकल कैमरा डिवाइसों से बना होता है.

सेशन पैरामीटर

सेशन पैरामीटर लागू करने से, कैप्चर सेशन के शुरू होने के फ़ेज़ के दौरान, कैमरा क्लाइंट को ज़्यादा समय लेने वाले अनुरोध पैरामीटर के सबसेट को कॉन्फ़िगर करने की सुविधा मिलती है. इससे, देरी कम हो सकती है.

एक प्रोड्यूसर, कई उपभोक्ता बफ़र

एक प्रोड्यूसर, कई उपभोक्ता कैमरा बफ़र ट्रांसपोर्ट, तरीकों का एक सेट है. इसकी मदद से, कैमरा क्लाइंट कैप्चर सेशन के चालू होने और कैमरा स्ट्रीमिंग के दौरान, आउटपुट प्लैटफ़ॉर्म को डाइनैमिक तौर पर जोड़ और हटा सकते हैं.

कनेक्टिविटी

कॉल करना और मैसेज भेजना

डेटा प्लान लागू करना

Android 9 और इसके बाद के वर्शन में, SubscriptionPlan API का इस्तेमाल करके, डेटा प्लान लागू करने में मोबाइल और इंटरनेट सेवा देने वाली कंपनियों को बेहतर सहायता मिलती है.

तीसरे पक्ष के कॉलिंग ऐप्लिकेशन

Android 9 और इसके बाद के वर्शन में एपीआई उपलब्ध होते हैं. इनकी मदद से, तीसरे पक्ष (3P) के कॉलिंग ऐप्लिकेशन, एक साथ आने वाले कैरियर कॉल को मैनेज कर सकते हैं. साथ ही, कॉल को सिस्टम कॉल लॉग में लॉग कर सकते हैं.

मोबाइल और इंटरनेट सेवा देने वाली कंपनी

मोबाइल और इंटरनेट सेवा देने वाली कंपनी की पहचान

Android 9 में, AOSP ने कैरियर आईडी डेटाबेस जोड़ा है, ताकि कैरियर की पहचान करने में मदद मिल सके. डेटाबेस, कैरियर की पहचान करने का एक सामान्य तरीका उपलब्ध कराकर, डुप्लीकेट लॉजिक और ऐप्लिकेशन के अलग-अलग वर्शन से जुड़ी समस्याओं को कम करता है.

ई-सिम

एम्बेडेड सिम (ई-सिम या ईयूआईसीसी) एक नई टेक्नोलॉजी है. इसकी मदद से, मोबाइल इस्तेमाल करने वाले लोग, मोबाइल और इंटरनेट सेवा देने वाली कंपनी की प्रोफ़ाइल डाउनलोड कर सकते हैं. साथ ही, बिना किसी सिम कार्ड के, मोबाइल और इंटरनेट सेवा देने वाली कंपनी की सेवा चालू कर सकते हैं. Android 9 और इसके बाद के वर्शन में, Android फ़्रेमवर्क, ई-सिम को ऐक्सेस करने और उस पर सदस्यता प्रोफ़ाइलों को मैनेज करने के लिए स्टैंडर्ड एपीआई उपलब्ध कराता है. ज़्यादा जानकारी के लिए, ये देखें:

IMS सेटिंग के लिए, एक से ज़्यादा सिम का इस्तेमाल करने की सुविधा

Android 9 और इसके बाद के वर्शन में, आईपी मल्टीमीडिया सबसिस्टम (आईएमएस) के लिए उपयोगकर्ता सेटिंग में सुधार किए गए हैं. इन सेटिंग को सभी सदस्यताओं के लिए शेयर करने के बजाय, हर सदस्यता के लिए वॉइसओवर LTE (VoLTE), वीडियो कॉलिंग, और वाई-फ़ाई कॉलिंग की सुविधा सेट अप की जा सकती है.

सिम की स्थिति के बारे में ब्रॉडकास्ट

Android 9 और इसके बाद के वर्शन में, Intent.ACTION_SIM_STATE_CHANGED का इस्तेमाल नहीं किया जा सकता. साथ ही, कार्ड की स्थिति और कार्ड ऐप्लिकेशन की स्थिति के लिए, दो अलग-अलग ब्रॉडकास्ट जोड़े गए हैं, TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED और TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED.

इन बदलावों के बाद, जिन रिसीवर को सिर्फ़ यह जानना है कि कार्ड मौजूद है या नहीं, उन्हें ऐप्लिकेशन के स्टेटस में होने वाले बदलावों को सुनने की ज़रूरत नहीं है. साथ ही, जिन रिसीवर को सिर्फ़ यह जानना है कि कार्ड के अनुरोध तैयार हैं या नहीं, उन्हें कार्ड के स्टेटस में होने वाले बदलावों को सुनने की ज़रूरत नहीं है.

दो नए ब्रॉडकास्ट @SystemApis हैं और ये स्टिक नहीं होते. ब्रॉडकास्ट सिर्फ़ वे लोग पा सकते हैं जिनके पास READ_PRIVILEGED_PHONE_STATE अनुमति है.

डिवाइस अनलॉक करने पर, इंटेंट फिर से ब्रॉडकास्ट नहीं किए जाते. अनलॉक करने से पहले भेजे गए ब्रॉडकास्ट पर निर्भर रहने वाले रिसीवर को directBootAware का इस्तेमाल करना होगा या उपयोगकर्ता के अनलॉक करने के बाद, स्थिति के बारे में क्वेरी करनी होगी. राज्यों के बारे में जानकारी पाने के लिए, TelephonyManager, getSimCardState() और getSimApplicationState() में मौजूद संबंधित एपीआई का इस्तेमाल किया जा सकता है.

वाई-फ़ाई

मोबाइल और इंटरनेट सेवा देने वाली कंपनी का वाई-फ़ाई

मोबाइल और इंटरनेट सेवा देने वाली कंपनी के वाई-फ़ाई की सुविधा की मदद से, डिवाइसों को मोबाइल और इंटरनेट सेवा देने वाली कंपनी के वाई-फ़ाई नेटवर्क से अपने-आप कनेक्ट किया जा सकता है. ज़्यादा भीड़-भाड़ वाले इलाकों या स्टेडियम या अंडरग्राउंड रेलवे स्टेशन जैसी जगहों पर, मोबाइल और इंटरनेट सेवा देने वाली कंपनी का वाई-फ़ाई, कनेक्टिविटी को बेहतर बनाने और ट्रैफ़िक को कम करने में मदद करता है.

एमएसी पता बदलने की सुविधा

एमएसी पता बदलने की सुविधा की मदद से, डिवाइसों को नए नेटवर्क खोजते समय, रैंडम एमएसी पते का इस्तेमाल करने की अनुमति मिलती है. ऐसा तब होता है, जब डिवाइस किसी नेटवर्क से कनेक्ट न हो. Android 9 और इसके बाद के वर्शन में, डेवलपर के विकल्प को चालू किया जा सकता है. इससे डिवाइस, वाई-फ़ाई नेटवर्क से कनेक्ट होने पर, रैंडम एमएसी पते का इस्तेमाल करेगा.

वाई-फ़ाई अपने आप चालू करें.

वाई-फ़ाई अपने-आप चालू करें सुविधा चालू होने पर, डिवाइस को सेव किए गए किसी वाई-फ़ाई नेटवर्क के आस-पास ले जाने पर, वाई-फ़ाई अपने-आप फिर से चालू हो जाता है. इसके लिए, वाई-फ़ाई सिग्नल की क्षमता का संकेतक (आरएसएसआई) ज़रूरत के मुताबिक होना चाहिए.

वाई-फ़ाई का दोतरफ़ा यात्रा का समय

वाई-फ़ाई राउंड ट्रिप टाइम (आरटीटी) की मदद से, डिवाइसों को एक-दूसरे से दूरी का पता चलता है. भले ही, वे ऐक्सेस पॉइंट (एपी) हों या Wi-Fi Aware पीयर (अगर डिवाइस पर Wi-Fi Aware काम करता है). यह सुविधा, IEEE 802.11mc प्रोटोकॉल पर आधारित है. इससे ऐप्लिकेशन, जगह की सटीक जानकारी और जगह की जानकारी के बारे में ज़्यादा जानकारी का इस्तेमाल कर सकते हैं.

वाई-फ़ाई स्कोरिंग में सुधार

वाई-फ़ाई स्कोरिंग मॉडल को बेहतर बनाया गया है. इससे, यह तुरंत और सटीक तरीके से पता चलता है कि किसी डिवाइस को कनेक्ट किए गए वाई-फ़ाई नेटवर्क से कब बाहर निकलना चाहिए या किसी नए वाई-फ़ाई नेटवर्क से कब कनेक्ट होना चाहिए. ये मॉडल, कनेक्टिविटी में आने वाली रुकावटों को रोककर, उपयोगकर्ताओं को भरोसेमंद और बेहतर अनुभव देते हैं.

config.xml संसाधनों में आरएसएसआई वैल्यू की समीक्षा करें और उन्हें ट्यून करें. खास तौर पर, इन पर ध्यान दें:

  • config_wifi_framework_wifi_score_bad_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_bad_rssi_threshold_24GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_24GHz

वाई-फ़ाई एसटीए/एपी के साथ एक साथ काम करना

वाई-फ़ाई स्टेशन (एसटीए)/ऐक्सेस पॉइंट (एपी) मोड में एक साथ काम करना, डिवाइसों के लिए स्टेशन (एसटीए) और ऐक्सेस पॉइंट (एपी) मोड में एक साथ काम करने की सुविधा है. एक साथ दो बैंड (डीबीएस) वाले वाई-फ़ाई की सुविधा वाले डिवाइसों के लिए, यह कई सुविधाएं उपलब्ध कराता है. जैसे, जब कोई उपयोगकर्ता हॉटस्पॉट (सॉफ़्ट एपी) चालू करना चाहता है, तो एसटीए वाई-फ़ाई में रुकावट नहीं आती.

WiFiStateMachine में सुधार

WifiStateMachine मुख्य क्लास है, जिसका इस्तेमाल वाई-फ़ाई गतिविधि को कंट्रोल करने, उपयोगकर्ता के इनपुट (ऑपरेटिंग मोड: हॉटस्पॉट, स्कैन, कनेक्ट या बंद) को मैनेज करने, और वाई-फ़ाई नेटवर्क की कार्रवाइयों (जैसे, स्कैन करना या कनेक्ट करना) को कंट्रोल करने के लिए किया जाता है.

Android 9 और इसके बाद के वर्शन में, WifiStateMachine को लागू करने और वाई-फ़ाई फ़्रेमवर्क कोड का आर्किटेक्चर फिर से बनाया गया है. इससे कोड का साइज़ कम हो गया है, वाई-फ़ाई कंट्रोल लॉजिक को समझना आसान हो गया है, कंट्रोल को बेहतर तरीके से मैनेज किया जा सकता है, और यूनिट टेस्ट की कवरेज और क्वालिटी बढ़ गई है.

हाई लेवल पर,WifiStateMachine की मदद से वाई-फ़ाई को इनमें से किसी एक स्थिति में रखा जा सकता है:

  • क्लाइंट मोड (कनेक्ट और स्कैन कर सकता है)
  • सिर्फ़ स्कैन करने वाला मोड
  • SoftAP मोड (वाई-फ़ाई हॉटस्पॉट)
  • बंद है (वाई-फ़ाई पूरी तरह से बंद है)

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

वाई-फ़ाई की अनुमति से जुड़े अपडेट

Android 9 और इसके बाद के वर्शन में, CHANGE_WIFI_STATE ऐप्लिकेशन की अनुमति डिफ़ॉल्ट रूप से चालू होती है. सेटिंग > ऐप्लिकेशन और सूचनाएं > ऐप्लिकेशन के लिए खास ऐक्सेस > वाई-फ़ाई कंट्रोल में जाकर, सेटिंग पेज पर किसी भी ऐप्लिकेशन के लिए अनुमति बंद की जा सकती है.

ऐप्लिकेशन को उन मामलों को भी हैंडल करना चाहिए जहां CHANGE_WIFI_STATE अनुमति नहीं दी गई है.

इस व्यवहार की पुष्टि करने के लिए, roboelectric और मैन्युअल टेस्ट चलाएं.

मैन्युअल टेस्टिंग के लिए:

  1. सेटिंग > ऐप्लिकेशन और सूचनाएं > ऐप्लिकेशन के लिए खास ऐक्सेस > वाई-फ़ाई कंट्रोल पर जाएं.
  2. अपने ऐप्लिकेशन के लिए अनुमति चुनें और उसे बंद करें.
  3. पुष्टि करें कि आपका ऐप्लिकेशन उस स्थिति को मैनेज कर सकता है जहां CHANGE_WIFI_STATE अनुमति नहीं दी गई है.

WPS की सुविधा बंद होना

सुरक्षा से जुड़ी समस्याओं की वजह से, WiFiManager में वाई-फ़ाई सुरक्षित सेटअप (डब्ल्यूपीएस) की सुविधा का इस्तेमाल नहीं किया जा सकता. साथ ही, यह सुविधा Android 9 और इसके बाद के वर्शन में बंद है. हालांकि, WiFiDirect अब भी WPA supplicant में WPS का इस्तेमाल करता है.

ग्राफ़िक्स

लागू करना

Vulkan 1.1 API

Android 9 और इसके बाद के वर्शन पर, Vulkan 1.1 ग्राफ़िक एपीआई को लागू किया जा सकता है.

विंडो ट्रांज़िशन ट्रैकिंग के लिए WinScope टूल

Android 9 और उसके बाद के वर्शन में, विंडो ट्रांज़िशन को ट्रैक करने के लिए WinScope टूल शामिल है. WinScope, ट्रांज़िशन के दौरान और उसके बाद, विंडो मैनेजर की स्थिति को रिकॉर्ड करने और उसका विश्लेषण करने के लिए, इंफ़्रास्ट्रक्चर और टूल उपलब्ध कराता है. इससे विंडो ट्रांज़िशन को रिकॉर्ड करने और उनमें आगे बढ़ने की अनुमति मिलती है. साथ ही, विंडो मैनेजर की सभी ज़रूरी स्थितियों को ट्रैक फ़ाइल में रिकॉर्ड किया जाता है. इस डेटा का इस्तेमाल, ट्रांज़िशन को फिर से चलाने और उसमें सिलसिलेवार तरीके से आगे बढ़ने के लिए किया जा सकता है.

WinScope टूल का सोर्स कोड, platform/development/tools/winscope पर मौजूद है.

इंटरैक्शन

वाहन का ऑडियो

Automotive Audio, वाहन से जुड़े Android के लागू होने के लिए ऑडियो आर्किटेक्चर के बारे में बताता है.

न्यूरल नेटवर्क (एनएन) एचएएल, अलग-अलग ऐक्सेलरेटर के एब्स्ट्रैक्शन के बारे में बताता है. इन ऐक्सेलरेटर के ड्राइवर, इस एचएएल के मुताबिक होने चाहिए.

व्हीकल एचएएल

वाहन की प्रॉपर्टी से, वाहन के एचएएल इंटरफ़ेस में हुए बदलावों के बारे में पता चलता है.

जीएनएसएस सैटलाइट चुनना

नए ग्लोबल नेविगेशन सैटलाइट सिस्टम (जीएनएसएस) एचएएल (v1.1+) के साथ काम करते समय, Android फ़्रेमवर्क, Android सेटिंग को मॉनिटर करता है. पार्टनर, Google Play services या सिस्टम के अन्य अपडेट से सेटिंग बदल सकते हैं. इन सेटिंग से, GNSS HAL को पता चलता है कि कुछ जीएनएसएस सैटलाइट का इस्तेमाल नहीं किया जाना चाहिए. यह GNSS उपग्रह या कॉन्स्टेलेशन से जुड़ी गड़बड़ियों के मामले में मददगार हो सकता है. इसके अलावा, GNSS HAL लागू करने से जुड़ी समस्याओं का तेज़ी से जवाब देने में भी मदद मिल सकती है. ये समस्याएं, अलग-अलग टाइम सिस्टम और बाहरी इवेंट का इस्तेमाल करके कॉन्स्टेलेशन को मिक्स करने पर हो सकती हैं. जैसे, लीप-सेकंड, दिन या हफ़्ते के नंबर के रोलओवर.

जीएनएसएस हार्डवेयर मॉडल

Android 9 में, GNSS HAL का 1.1 या इसके बाद का वर्शन, प्लैटफ़ॉर्म को हार्डवेयर एपीआई के बारे में जानकारी दे सकता है. प्लैटफ़ॉर्म को IGnssCallback इंटरफ़ेस लागू करना होगा और एचएएल को हैंडल पास करना होगा. GNSS एचएएल, हार्डवेयर मॉडल की जानकारी को LocationManager#getGnssHardwareModelName() तरीके से पास करता है. डिवाइस बनाने वाली कंपनियों को जहां भी हो सके, यह जानकारी देने के लिए जीएनएसएस एचएएल की सेवा देने वाली कंपनियों के साथ काम करना चाहिए.

अनुमतियां

डिस्क्रेशनरी ऐक्सेस कंट्रोल के अपडेट कॉन्फ़िगर करना

डिसक्रेशनरी ऐक्सेस कंट्रोल (डीएसी) कॉन्फ़िगर करना में, फ़ाइल सिस्टम की सुविधाओं को बेहतर बनाने के लिए, Android आईडी (एआईडी) के तरीके में अपडेट शामिल हैं.

खास ऐप्लिकेशन की अनुमतियों को व्हाइटलिस्ट करना

Android 9 और उसके बाद के वर्शन में, अगर ऐसी अनुमतियां हैं जिन्हें अस्वीकार करना है, तो एक्सएमएल में बदलाव करें. इससे, आपको पिछली रिलीज़ में इस्तेमाल किए गए permission टैग के बजाय, deny-permission टैग का इस्तेमाल करने में मदद मिलेगी.

डेटा

बैंडविथ के अनुमान में सुधार

Android 9 में, बैंडविड्थ का अनुमान लगाने की सुविधा को बेहतर बनाया गया है. अगर Android ऐप्लिकेशन, उपलब्ध डेटा बैंडविड्थ को ऐक्सेस कर सकते हैं, तो वे वीडियो कॉल और वीडियो स्ट्रीमिंग के लिए ज़्यादा सही रिज़ॉल्यूशन सेटिंग तय कर सकते हैं.

Android 6.0 या इसके बाद के वर्शन वाले डिवाइसों पर, कॉल करने वाला व्यक्ति अगर मोबाइल नेटवर्क के लिए बैंडविड्थ का अनुमान जानना चाहता है, तो वह ConnectivityManager.requestBandwidthUpdate() कोड डालता है. इसके बाद, फ़्रेमवर्क हो सकता है कि डाउनलिंक बैंडविड्थ का अनुमान दे.

हालांकि, Android 9 या इसके बाद के वर्शन वाले डिवाइसों पर, अनुमानित बैंडविड्थ में काफ़ी बदलाव होने पर, onCapabilitiesChanged() कॉलबैक अपने-आप ट्रिगर होता है. साथ ही, requestBandwidthUpdate() को कॉल करने की ज़रूरत नहीं होती. इससे जुड़े getLinkDownstreamBandwidthKbps() और getLinkUpstreamBandwidthKbps() को फ़िज़िकल लेयर से मिली अपडेट की गई जानकारी से पॉप्युलेट किया जाता है.

इसके अलावा, डिवाइस ServiceState.getCellBandwidths() के ज़रिए LTE सेल बैंडविड्थ की जांच कर सकते हैं. इससे ऐप्लिकेशन यह तय कर सकते हैं कि किसी सेल पर कितनी बैंडविड्थ (फ़्रीक्वेंसी) उपलब्ध है. सेल बैंडविड्थ की जानकारी, छिपे हुए मेन्यू में उपलब्ध होती है, ताकि फ़ील्ड टेस्टर सबसे नई जानकारी देख सकें.

eBPF ट्रैफ़िक मॉनिटरिंग

eBPF नेटवर्क ट्रैफ़िक टूल, डिवाइस के आखिरी बार बूट होने के बाद से, नेटवर्क के इस्तेमाल को मॉनिटर करने के लिए, कर्नेल और उपयोगकर्ता स्पेस के कॉम्बिनेशन का इस्तेमाल करता है. यह टूल, डिवाइस की स्थिति के आधार पर ऐप्लिकेशन को नेटवर्क ऐक्सेस करने से ब्लॉक करने के लिए, यूआईडी के हिसाब से फ़ायरवॉल, फ़ोरग्राउंड/बैकग्राउंड ट्रैफ़िक को अलग करने, और सॉकेट टैग करने जैसी अतिरिक्त सुविधाएं देता है.

पुराने एपीआई पर वापस लाना

अब डिवाइसों को ऑपरेटिंग सिस्टम के आने वाले वर्शन से भी वापस लाया जा सकता है. यह सुविधा खास तौर पर तब काम आती है, जब उपयोगकर्ताओं ने अपने फ़ोन अपग्रेड कर लिए हों, लेकिन फिर वे खो गए हों या टूट गए हों.

अगर कोई OEM, सिस्टम के किसी भी पैकेज (Android, सिस्टम, सेटिंग) के लिए बैकअप एजेंट में बदलाव करता है, तो उन एजेंट को प्लैटफ़ॉर्म के नए वर्शन पर बनाए गए बैकअप सेट को क्रैश किए बिना और कम से कम कुछ डेटा को वापस लाकर रीस्टोर करना चाहिए.

बैकअप डेटा के किसी हिस्से की अमान्य वैल्यू की जांच करने के लिए, वैलिडेटर का इस्तेमाल करें. साथ ही, सिर्फ़ मान्य डेटा को core/java/android/provider/SettingsValidators.java की तरह वापस लाएं.

यह सुविधा डिफ़ॉल्ट रूप से चालू रहती है. आने वाले वर्शन से डेटा वापस लाने के लिए, SettingsBackupAgent की सहायता को Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION की मदद से बंद किया जा सकता है. जब तक डिवाइस बनाने वाली कंपनी, रोम में शामिल किसी बैकअप एजेंट को बेहतर नहीं बनाती या कोई कस्टम एजेंट नहीं जोड़ती, तब तक इसे लागू करने के लिए कुछ और करने की ज़रूरत नहीं है.

इस सुविधा की मदद से, प्लैटफ़ॉर्म के आने वाले वर्शन से सिस्टम को वापस लाया जा सकता है. हालांकि, यह उम्मीद करना सही नहीं होगा कि वापस लाया गया डेटा पूरा होगा. ये निर्देश, यहां दिए गए बैकअप एजेंट पर लागू होते हैं:

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

  • SystemBackupAgent, Android 9 और इसके बाद के वर्शन में restoreAnyVersion = false की जानकारी देता है. यह एपीआई के नए वर्शन से बैकअप को वापस लाने की सुविधा नहीं देता.

  • SettingsBackupAgent, Android 9 और इसके बाद के वर्शन में restoreAnyVersion = true की जानकारी देता है. पुष्टि करने वाले टूल की मदद से, कुछ हद तक यह सुविधा काम करती है. किसी सेटिंग को एपीआई के बेहतर वर्शन से वापस लाया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि टारगेट ओएस में, इस सेटिंग की पुष्टि करने वाला टूल मौजूद हो. किसी भी सेटिंग को जोड़ते समय, पुष्टि करने वाला टूल भी जोड़ना चाहिए. ज़्यादा जानकारी के लिए क्लास देखें.

  • अगर बैकअप डेटा फ़ॉर्मैट में कोई ऐसा बदलाव किया जाता है जो काम नहीं करता, तो ROM में शामिल किसी भी कस्टम बैकअप एजेंट को अपने वर्शन कोड को बढ़ाना चाहिए. साथ ही, अगर एजेंट अपने कोड के अगले वर्शन के बैकअप डेटा को मैनेज करने के लिए तैयार नहीं है, तो restoreAnyVersion = false (डिफ़ॉल्ट) का इस्तेमाल करना चाहिए.

Enterprise

मैनेज की जा रही प्रोफ़ाइल में सुधार

मैनेज की जा रही प्रोफ़ाइलों के लिए यूज़र एक्सपीरियंस में किए गए बदलावों की मदद से, उपयोगकर्ताओं को मैनेज की जा रही प्रोफ़ाइल की पहचान करने, उसे ऐक्सेस करने, और कंट्रोल करने में आसानी होती है.

ओटीए रोकना

नए @SystemApi की मदद से, डिवाइस के मालिक ओटीए अपडेट को हमेशा के लिए रोक सकते हैं. इनमें सुरक्षा से जुड़े अपडेट भी शामिल हैं.

परफ़ॉर्मेंस

Health 2.0

Android 9 और इसके बाद के वर्शन में android.hardware.health HAL 2.0 शामिल है. यह health@1.0 HAL से वर्शन अपग्रेड का एक बड़ा अपडेट है. ज़्यादा जानकारी के लिए, ये पेज देखें:

APK कैश मेमोरी से जुड़ी समस्या का हल

Android 9 और इसके बाद के वर्शन में, APK कैश मेमोरी का समाधान शामिल है. इससे, A/B पार्टीशन की सुविधा वाले डिवाइस पर, पहले से लोड किए गए ऐप्लिकेशन तेज़ी से इंस्टॉल किए जा सकते हैं. OEM, A/B-पार्टिशन वाले नए डिवाइसों पर, APK कैश मेमोरी में प्रीलोड किए गए ऐप्लिकेशन और लोकप्रिय ऐप्लिकेशन सेव कर सकते हैं. यह कैश मेमोरी, ज़्यादातर खाली B-पार्टिशन में सेव होती है. इससे, उपयोगकर्ता के लिए उपलब्ध डेटा स्टोरेज पर कोई असर नहीं पड़ता.

प्रोफ़ाइल के हिसाब से ऑप्टिमाइज़ेशन

Android 9 और इसके बाद के वर्शन में, उन नेटिव Android मॉड्यूल पर Clang के प्रोफ़ाइल-गाइडेड ऑप्टिमाइज़ेशन (PGO) का इस्तेमाल किया जा सकता है जिनमें ब्लूप्रिंट बिल्ड नियम हैं.

पहले से लॉग करना

SQLiteDatabase का एक खास मोड, कंपैटिबिलिटी राइट-अहेड लॉगिंग (डब्ल्यूएएल) है. इसकी मदद से, डेटाबेस में journal_mode=WAL का इस्तेमाल किया जा सकता है. हालांकि, हर डेटाबेस के लिए ज़्यादा से ज़्यादा एक कनेक्शन ही रखा जा सकता है.

बूट होने में लगने वाला समय

Android 9 में, बूट टाइम ऑप्टिमाइज़ेशन में बदलाव किए गए हैं. इनके बारे में बूट टाइम ऑप्टिमाइज़ करना लेख में बताया गया है.

ताकत

बैकग्राउंड में काम करने से जुड़ी पाबंदियां

Android 9 और इसके बाद के वर्शन में, बैकग्राउंड में काम करने से जुड़ी पाबंदियां शामिल हैं. इनकी मदद से, उपयोगकर्ता उन ऐप्लिकेशन पर पाबंदी लगा सकते हैं जो बैटरी खर्च कर रहे हैं. सिस्टम, ऐसे ऐप्लिकेशन बंद करने का सुझाव भी दे सकता है जिनसे डिवाइस की परफ़ॉर्मेंस पर बुरा असर पड़ रहा है.

बैटरी के बिना काम करने वाले डिवाइस

Android 9, बिना बैटरी वाले डिवाइसों को मैनेज करने के लिए, पिछली रिलीज़ के मुकाबले बेहतर तरीके का इस्तेमाल करता है. Android 9 में, बैटरी के बिना काम करने वाले ऐसे डिवाइसों के लिए कोड हटा दिया गया है जो डिफ़ॉल्ट रूप से यह मानते हैं कि बैटरी मौजूद है, 100% चार्ज है, और थर्मिस्टर पर सामान्य तापमान की जानकारी दिख रही है.