APEX फ़ाइल फ़ॉर्मैट

Android में Android Pony EXpress (APEX) कंटेनर फ़ॉर्मैट शामिल किया गया 10 मिनट साथ ही, इसका इस्तेमाल लोवर-लेवल सिस्टम के लिए इंस्टॉल फ़्लो में किया जाता है मॉड्यूल देखें. यह फ़ॉर्मैट फ़िट न होने वाले सिस्टम कॉम्पोनेंट को अपडेट करने में मदद करता है किया जा सकता है. उदाहरण के तौर पर दिए गए कुछ कॉम्पोनेंट नेटिव हैं सेवाएं और लाइब्रेरी, हार्डवेयर ऐब्स्ट्रक्शन लेयर (HAL), रनटाइम (ART), और क्लास लाइब्रेरी.

"APEX" शब्द APEX फ़ाइल का भी हवाला दिया जा सकता है.

बैकग्राउंड

हालांकि, Android पर ऐसे मॉड्यूल के अपडेट काम करते हैं जो स्टैंडर्ड ऐप्लिकेशन में फ़िट हो जाते हैं पैकेज इंस्टॉलर ऐप्लिकेशन (जैसे कि (जैसे, Google Play Store ऐप्लिकेशन), तो लोअर-लेवल के ओएस कॉम्पोनेंट के लिए मिलते-जुलते मॉडल का इस्तेमाल किया जा रहा हो इसमें ये खामियां हैं:

  • APK पर आधारित मॉड्यूल को चालू करने के क्रम में, शुरुआत में इस्तेमाल नहीं किया जा सकता. पैकेज मैनेजर ऐप्लिकेशन के बारे में जानकारी का मुख्य संग्रह होता है. इसमें सिर्फ़ गतिविधि मैनेजर से शुरू किया है, जो बूट प्रोसेस होगी.
  • APK फ़ॉर्मैट (खास तौर पर मेनिफ़ेस्ट) Android ऐप्लिकेशन और सिस्टम मॉड्यूल हमेशा सही नहीं होते हैं.

डिज़ाइन

इस सेक्शन में, APEX फ़ाइल फ़ॉर्मैट और APEX मैनेजर, ऐसी सेवा है जो APEX फ़ाइलों को मैनेज करती है.

APEX के लिए यह डिज़ाइन क्यों चुना गया, इस बारे में ज़्यादा जानकारी के लिए देखें APEX डेवलप करते समय इन विकल्पों पर ध्यान दिया जाता है.

APEX फ़ॉर्मैट

यह एक APEX फ़ाइल का फ़ॉर्मैट है.

APEX फ़ाइल फ़ॉर्मैट

पहला डायग्राम. APEX फ़ाइल फ़ॉर्मैट

सबसे ऊपर के लेवल पर, APEX फ़ाइल एक ZIP फ़ाइल होती है, जिसमें फ़ाइलें स्टोर की जाती हैं साइज़ छोटा होना चाहिए और 4 केबी की सीमाओं पर होना चाहिए.

APEX फ़ाइल में ये चार फ़ाइलें होती हैं:

  • apex_manifest.json
  • AndroidManifest.xml
  • apex_payload.img
  • apex_pubkey

apex_manifest.json फ़ाइल में पैकेज का नाम और वर्शन शामिल होता है, जो एक APEX फ़ाइल की पहचान करता है. यह है ApexManifest JSON फ़ॉर्मैट में प्रोटोकॉल बफ़र.

AndroidManifest.xml फ़ाइल, APEX फ़ाइल को APK से जुड़े टूल इस्तेमाल करने की अनुमति देती है और ADB, PackageManager, और पैकेज इंस्टॉलर ऐप्लिकेशन जैसी इन्फ़्रास्ट्रक्चर (जैसे, Play Store). उदाहरण के लिए, APEX फ़ाइल किसी मौजूदा टूल का इस्तेमाल कर सकती है, जैसे कि aapt का इस्तेमाल करें. फ़ाइल में पैकेज का नाम और वर्शन की जानकारी देखें. यह जानकारी आम तौर पर इसमें भी उपलब्ध होती है apex_manifest.json.

नए कोड के लिए AndroidManifest.xml से ज़्यादा apex_manifest.json का सुझाव दिया जाता है और जो APEX क्वेरी से जुड़े हैं. AndroidManifest.xml में अतिरिक्त चीज़ें हो सकती हैं मौजूदा ऐप्लिकेशन पब्लिश करने वाले टूल में इस्तेमाल की जा सकने वाली टारगेटिंग (विज्ञापन के लिए सही दर्शक चुनना) जानकारी.

apex_payload.img एक ext4 फ़ाइल सिस्टम इमेज है, जो dm-verity से जुड़ी है. इमेज को लूपबैक डिवाइस के ज़रिए रनटाइम पर माउंट किया जाता है. खास तौर पर, हैश ट्री और मेटाडेटा ब्लॉक, libavb लाइब्रेरी का इस्तेमाल करके बनाए जाते हैं. फ़ाइल सिस्टम पेलोड पार्स नहीं किया गया है (क्योंकि इमेज अपनी जगह पर माउंट की जा सकती है). सामान्य फ़ाइलें हैं apex_payload.img फ़ाइल में शामिल है.

apex_pubkey एक सार्वजनिक पासकोड है, जिसका इस्तेमाल फ़ाइल सिस्टम की इमेज पर हस्ताक्षर करने के लिए किया जाता है. रनटाइम के दौरान, इस कुंजी से पक्का होता है कि डाउनलोड किया गया APEX उसी इकाई के साथ साइन किया गया है जो पहले से मौजूद पार्टिशन में एक ही APEX पर साइन करता है.

APEX नाम रखने से जुड़े दिशा-निर्देश

प्लैटफ़ॉर्म आगे बढ़ने के साथ-साथ, नए APEXेस के बीच नाम रखने में होने वाले विवादों से बचने में मदद करने के लिए, नीचे दिए गए नामकरण दिशा-निर्देशों का इस्तेमाल करें:

  • com.android.*
    • AOSP APEXes के लिए रिज़र्व. यह किसी कंपनी या डिवाइस के लिए यूनीक नहीं होता.
  • com.<companyname>.*
    • किसी कंपनी के लिए रिज़र्व किया गया. संभावित रूप से इसका इस्तेमाल कई डिवाइस कर सकते हैं कंपनी.
  • com.<companyname>.<devicename>.*
    • किसी खास डिवाइस (या डिवाइसों के सबसेट) के लिए, खास APEXs के लिए रिज़र्व किया गया.

APEX मैनेजर

APEX मैनेजर (या apexd) एक स्टैंडअलोन नेटिव प्रोसेस है, जो APEX फ़ाइलों की पुष्टि और उन्हें इंस्टॉल और अनइंस्टॉल करने के लिए इस्तेमाल किया जाता है. यह प्रोसेस लॉन्च की गई है और बूट सीक्वेंस में जल्दी तैयार हो जाता है. APEX फ़ाइलें आम तौर पर, इन पर पहले से इंस्टॉल होती हैं: /system/apex से कम कीमत वाला डिवाइस. APEX मैनेजर डिफ़ॉल्ट रूप से इनका इस्तेमाल करता है कोई अपडेट उपलब्ध न होने पर पैकेज भेजना.

APEX के अपडेट क्रम का इस्तेमाल पैकेज मैनेजर क्लास के बारे में आपको बताया गया है.

  1. APEX फ़ाइल, पैकेज इंस्टॉलर ऐप्लिकेशन, ADB या अन्य स्रोत.
  2. पैकेज मैनेजर, इंस्टॉल करने की प्रोसेस शुरू करता है. यह पता चलने पर कि फ़ाइल एक APEX है, तो पैकेज मैनेजर कंट्रोल को APEX पर ट्रांसफ़र कर देता है मैनेजर.
  3. APEX मैनेजर, APEX फ़ाइल की पुष्टि करता है.
  4. अगर APEX फ़ाइल की पुष्टि हो गई है, तो APEX मैनेजर का इंटरनल डेटाबेस यह बताने के लिए अपडेट किया गया है कि अगली बार बूट होने पर APEX फ़ाइल चालू हो जाएगी.
  5. पैकेज इंस्टॉल होने पर, इंस्टॉल करने का अनुरोध करने वाले व्यक्ति को ब्रॉडकास्ट मिलता है पुष्टि करने के लिए.
  6. इंस्टॉलेशन जारी रखने के लिए, सिस्टम को फिर से चालू करना होगा.

  7. अगले बूट पर, APEX मैनेजर शुरू होता है, इंटरनल डेटाबेस को पढ़ता है, और यहां दी गई हर APEX फ़ाइल के लिए, नीचे दी गई शर्त को पूरा करना होगा:

    1. APEX फ़ाइल की पुष्टि करता है.
    2. APEX फ़ाइल से लूपबैक डिवाइस बनाता है.
    3. लूपबैक डिवाइस के सबसे ऊपर एक डिवाइस मैपर ब्लॉक डिवाइस बनाता है.
    4. डिवाइस मैपर ब्लॉक डिवाइस को किसी यूनीक पाथ पर माउंट करता है (उदाहरण के लिए, /apex/name@ver).

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

APEX फ़ाइलें, APK फ़ाइलें होती हैं

APEX फ़ाइलें मान्य APK फ़ाइलें होती हैं, क्योंकि वे ज़िप संग्रह होती हैं (जिसका उपयोग करके APK सिग्नेचर स्कीम) है, जिसमें AndroidManifest.xml फ़ाइल है. इससे APEX को अनुमति मिलेगी APK फ़ाइलों के लिए इंफ़्रास्ट्रक्चर का इस्तेमाल करने वाली फ़ाइलें, जैसे कि पैकेज इंस्टॉलर ऐप्लिकेशन, और पैकेज मैनेजर पर कानूनी नियंत्रण लगा सकते हैं.

APEX फ़ाइल के अंदर AndroidManifest.xml फ़ाइल बहुत छोटी होती है. पैकेज name, versionCode, और वैकल्पिक targetSdkVersion, minSdkVersion, और maxSdkVersion का इस्तेमाल, सटीक टारगेटिंग के लिए किया जा सकता है. इस जानकारी के आधार पर, APEX मौजूदा चैनलों के ज़रिए डिलीवर की जाने वाली फ़ाइलें, जैसे कि पैकेज इंस्टॉलर ऐप्लिकेशन और एडीबी.

इस्तेमाल किए जा सकने वाले फ़ाइल टाइप

APEX फ़ॉर्मैट इन फ़ाइल टाइप के साथ काम करता है:

  • नेटिव शेयर की गई लिब्स
  • नेटिव एक्ज़ीक्यूटेबल
  • JAR फ़ाइलें
  • डेटा फ़ाइलें
  • कॉन्फ़िगरेशन फ़ाइलें

इसका मतलब यह नहीं है कि APEX इन सभी फ़ाइल टाइप को अपडेट कर सकता है. क्या फ़ाइल डेटा किस तरह का है, यह प्लैटफ़ॉर्म और इसकी डेफ़िनिशन पर निर्भर करता है कि वे कितने सटीक हैं फ़ाइल टाइप के लिए इंटरफ़ेस हैं.

हस्ताक्षर करने के विकल्प

APEX फ़ाइलों को दो तरीकों से साइन किया जाता है. सबसे पहले, apex_payload.img (खास तौर पर, apex_payload.img में जोड़ा गया vbmeta डिस्क्रिप्टर) फ़ाइल को कुंजी से साइन किया गया है. इसके बाद, पूरे APEX खाते को APK सिग्नेचर स्कीम v3. दो अलग-अलग कुंजियों का इस्तेमाल किया गया है को ट्रैक किया जा सकता है.

डिवाइस की ओर, हस्ताक्षर करने के लिए इस्तेमाल किए जाने वाले निजी पासकोड से जुड़ा एक सार्वजनिक पासकोड vbmeta डिस्क्रिप्टर इंस्टॉल हो जाए. APEX मैनेजर सार्वजनिक पासकोड का इस्तेमाल करके, उन APEXs की पुष्टि करें जिन्हें इंस्टॉल करने का अनुरोध किया गया है. हर APEX खाते पर अलग-अलग कुंजियां होती हैं और उसे बिल्ड के समय और रनटाइम, दोनों पर लागू किया जाता है.

पहले से मौजूद पार्टिशन में APEX

APEX फ़ाइलें पहले से मौजूद पार्टिशन में हो सकती हैं, जैसे कि /system. कॉन्टेंट बनाने विभाजन पहले से dm-verity से ऊपर है, इसलिए APEX फ़ाइलें सीधे माउंट की जाती हैं लूपबैक डिवाइस पर ले जाया जा सकता है.

अगर पहले से मौजूद किसी पार्टीशन में APEX मौजूद है, तो APEX यहां से अपडेट किया जा सकता है APEX पैकेज को वही पैकेज नाम और उससे ज़्यादा या उसके बराबर उपलब्ध कराना को वर्शन कोड में बदलना होगा. नया APEX, /data में सेव किया जाता है. यह APK की तरह ही, हाल ही में इंस्टॉल किया गया वर्शन, बिल्ट-इन में पहले से मौजूद वर्शन को शैडो करता है विभाजन. हालांकि, APK से अलग, APEX का हाल ही में इंस्टॉल किया गया वर्शन और फिर चालू हो जाता है.

कर्नेल के लिए ज़रूरी शर्तें

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

लूपबैक ड्राइवर और डीएम-वेरिटी का परफ़ॉर्मेंस, लक्ष्य हासिल करने के लिए अहम होता है APEX मॉड्यूल का इस्तेमाल करते समय, सिस्टम की परफ़ॉर्मेंस अच्छी होनी चाहिए.

इस्तेमाल किए जा सकने वाले kernel वर्शन

APEX मेनलाइन मॉड्यूल, कर्नेल के वर्शन 4.4 या उच्च. Android 10 या उसके बाद के वर्शन में लॉन्च होने वाले नए डिवाइस APEX मॉड्यूल के साथ काम करने के लिए, कर्नेल वर्शन 4.9 या उसके बाद वाले वर्शन का इस्तेमाल करना ज़रूरी है.

ज़रूरी कर्नेल पैच

APEX मॉड्यूल के साथ काम करने के लिए, ज़रूरी कर्नेल पैच इसमें शामिल हैं Android कॉमन ट्री. APEX के साथ काम करने के लिए पैच पाने के लिए, सबसे नए वर्शन का इस्तेमाल करें Android कॉमन ट्री की इमेज दिखेगी.

Kernel वर्शन 4.4

यह वर्शन सिर्फ़ उन डिवाइसों के लिए काम करता है जिन्हें Android 9 से, अपग्रेड किए गए वर्शन पर अपग्रेड किया गया है Android 10 वर्शन वाले डिवाइस पर, APEX मॉड्यूल की सुविधा काम करती है. पाने के लिए ज़रूरी पैच होते हैं. android-4.4 ब्रांच से डाउन-मर्ज किया जाता है सुझाया गया. ज़रूरी अलग-अलग पैच की सूची नीचे दी गई है कर्नेल वर्शन 4.4 के लिए उपलब्ध है.

  • UPSTREAM: लूप: लॉजिकल ब्लॉक का साइज़ बदलने के लिए ioctl जोड़ें (4.4)
  • बैकपोर्ट: ब्लॉक/लूप: hw_secters सेट करें (4.4)
  • UPSTREAM: लूप: compat ioctl में LOOP_SET_Block_SIZE जोड़ें (4.4)
  • ANDROID: mnt: Next_descendent को ठीक करें (4.4)
  • ANDROID: mnt: दासों के दासों के लिए फिर से माउंट किया जाना चाहिए (4.4)
  • ANDROID: mnt: सही तरीके से रीमाउंट करें (4.4)
  • "ANDROID: dm प्रामाणिकता: कम से कम प्रीफ़ेच आकार जोड़ें" वापस लाएं (4.4)
  • UPSTREAM: लूप: ऑफ़सेट या block_size में बदलाव होने पर कैश मेमोरी छोड़ें (4.4)

Kernel वर्शन 4.9/4.14/4.19

कर्नेल वर्शन 4.9/4.14/4.19 के लिए, ज़रूरी पैच पाने के लिए, इनसे डाउन-मर्ज करें android-common की ब्रांच.

कर्नेल कॉन्फ़िगरेशन के लिए ज़रूरी विकल्प

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

(*) CONFIG_AIO=Y # AIO support (for direct I/O on loop devices)
CONFIG_BLK_DEV_LOOP=Y # for loop device support
CONFIG_BLK_DEV_LOOP_MIN_COUNT=16 # pre-create 16 loop devices
(*) CONFIG_CRYPTO_SHA1=Y # SHA1 hash for DM-verity
(*) CONFIG_CRYPTO_SHA256=Y # SHA256 hash for DM-verity
CONFIG_DM_VERITY=Y # DM-verity support

Kernel कमांड-लाइन पैरामीटर की ज़रूरी शर्तें

APEX के साथ काम करने के लिए, पक्का करें कि कर्नेल कमांड-लाइन पैरामीटर इन शर्तों को पूरा करते हों ज़रूरतें:

  • loop.max_loop सेट नहीं होना चाहिए
  • loop.max_part, <= 8 होना चाहिए

APEX बनाएं

इस सेक्शन में, Android बिल्ड सिस्टम का इस्तेमाल करके APEX फ़ाइल बनाने का तरीका बताया गया है. apex.test नाम के APEX फ़ंक्शन के लिए, Android.bp का उदाहरण नीचे दिया गया है.

apex {
    name: "apex.test",
    manifest: "apex_manifest.json",
    file_contexts: "file_contexts",
    // libc.so and libcutils.so are included in the apex
    native_shared_libs: ["libc", "libcutils"],
    binaries: ["vold"],
    java_libs: ["core-all"],
    prebuilts: ["my_prebuilt"],
    compile_multilib: "both",
    key: "apex.test.key",
    certificate: "platform",
}

apex_manifest.json का उदाहरण:

{
  "name": "com.android.example.apex",
  "version": 1
}

file_contexts का उदाहरण:

(/.*)?           u:object_r:system_file:s0
/sub(/.*)?       u:object_r:sub_file:s0
/sub/file3       u:object_r:file3_file:s0

APEX में फ़ाइल टाइप और लोकेशन

फ़ाइल टाइप APEX में जगह की जानकारी
शेयर की गई लाइब्रेरी /lib और /lib64 (इसके लिए /lib/arm चुकाएं x86 में अनुवाद किया गया आर्म)
एक्ज़ीक्यूटेबल /bin
Java लाइब्रेरी /javalib
पहले से बने ऐप्लिकेशन /etc

ट्रांज़िटिव डिपेंडेंसी

APEX फ़ाइलों में, नेटिव शेयर की गई लिब्स की ट्रांज़िटिव डिपेंडेंसी अपने-आप शामिल हो जाती हैं या एक्ज़ीक्यूटेबल. उदाहरण के लिए, अगर libFoo, libBar पर निर्भर है, तो दो लाइब्रेरी हैं इसे तब शामिल किया जाता है, जब native_shared_libs प्रॉपर्टी में सिर्फ़ libFoo हो.

एक से ज़्यादा एबीआई मैनेज करना

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

डिवाइस के सिर्फ़ मुख्य एबीआई के लिए, binaries प्रॉपर्टी को इस तौर पर इंस्टॉल करें नीचे बताया गया है:

  • अगर डिवाइस में सिर्फ़ 32 बिट है, तो बाइनरी का सिर्फ़ 32-बिट वाला वैरिएंट इंस्टॉल किया गया.
  • अगर डिवाइस सिर्फ़ 64 बिट का है, तो बाइनरी का सिर्फ़ 64-बिट वाला वैरिएंट इंस्टॉल किया गया.

नेटिव लाइब्रेरी और बाइनरी के एबीआई पर बारीकी से कंट्रोल जोड़ने के लिए, का इस्तेमाल करें multilib.[first|lib32|lib64|prefer32|both].[native_shared_libs|binaries] अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है प्रॉपर्टी.

  • first: डिवाइस के मुख्य एबीआई से मेल खाता है. यह इसके लिए डिफ़ॉल्ट है: बाइनरी.
  • lib32: अगर ऐप्लिकेशन काम करता है, तो डिवाइस के 32-बिट एबीआई से मेल खाता है.
  • lib64: डिवाइस के 64-बिट एबीआई से मेल खाता है और यह डिवाइस के साथ काम करता है.
  • prefer32: अगर ऐप्लिकेशन काम करता है, तो डिवाइस के 32-बिट एबीआई से मेल खाता है. अगर 32-बिट एबीआई काम नहीं करता, 64-बिट एबीआई से मेल खाता है.
  • both: दोनों एबीआई से मेल खाता है. यह इसके लिए डिफ़ॉल्ट है: native_shared_libraries.

java, libraries, और prebuilts प्रॉपर्टी, एबीआई पर आधारित होती हैं.

यह उदाहरण ऐसे डिवाइस के लिए है जो 32/64 पर काम करता है और 32 को प्राथमिकता नहीं देता:

apex {
    // other properties are omitted
    native_shared_libs: ["libFoo"], // installed for 32 and 64
    binaries: ["exec1"], // installed for 64, but not for 32
    multilib: {
        first: {
            native_shared_libs: ["libBar"], // installed for 64, but not for 32
            binaries: ["exec2"], // same as binaries without multilib.first
        },
        both: {
            native_shared_libs: ["libBaz"], // same as native_shared_libs without multilib
            binaries: ["exec3"], // installed for 32 and 64
        },
        prefer32: {
            native_shared_libs: ["libX"], // installed for 32, but not for 64
        },
        lib64: {
            native_shared_libs: ["libY"], // installed for 64, but not for 32
        },
    },
}

vbmeta साइनिंग

हर APEX पर अलग-अलग कुंजियों से साइन करें. नई कुंजी की ज़रूरत पड़ने पर, नई कुंजी बनाएं सार्वजनिक-निजी कुंजी का जोड़ा और एक apex_key मॉड्यूल बनाएं. key प्रॉपर्टी का इस्तेमाल इन कामों के लिए करें कुंजी का इस्तेमाल करके APEX पर हस्ताक्षर करें. सार्वजनिक पासकोड अपने-आप avb_pubkey नाम का APEX.

# create an rsa key pair
openssl genrsa -out foo.pem 4096

# extract the public key from the key pair
avbtool extract_public_key --key foo.pem --output foo.avbpubkey

# in Android.bp
apex_key {
    name: "apex.test.key",
    public_key: "foo.avbpubkey",
    private_key: "foo.pem",
}

ऊपर दिए गए उदाहरण में, सार्वजनिक पासकोड (foo) का नाम, बटन दबाएं. APEX पर हस्ताक्षर करने के लिए इस्तेमाल की जाने वाली कुंजी के आईडी को APEX में लिखा गया है. रनटाइम के दौरान, apexd, डिवाइस में उसी आईडी वाले सार्वजनिक पासकोड का इस्तेमाल करके APEX की पुष्टि करता है.

APEX साइनिंग

APEX पर उसी तरह साइन करें जैसे APK पर साइन करते हैं. APEX पर दो बार साइन करें; एक बार मिनी फ़ाइल सिस्टम (apex_payload.img फ़ाइल) और पूरी फ़ाइल के लिए एक बार.

फ़ाइल-लेवल पर APEX पर हस्ताक्षर करने के लिए, certificate प्रॉपर्टी को इनमें से किसी एक में सेट करें ये तीन तरीके हैं:

  • सेट नहीं है: अगर कोई वैल्यू सेट नहीं की गई है, तो एपीईएक्स को दिए गए सर्टिफ़िकेट से साइन किया जाता है PRODUCT_DEFAULT_DEV_CERTIFICATE पर है. अगर कोई फ़्लैग सेट नहीं किया गया है, तो पाथ डिफ़ॉल्ट तौर पर सेट हो जाता है build/target/product/security/testkey तक.
  • <name>: APEX को उसी <name> सर्टिफ़िकेट से साइन किया गया है PRODUCT_DEFAULT_DEV_CERTIFICATE के रूप में डायरेक्ट्री.
  • :<name>: APEX को उस सर्टिफ़िकेट से साइन किया जाता है जो <name> नाम वाला सूंग मॉड्यूल. सर्टिफ़िकेट मॉड्यूल को इस तरह परिभाषित किया जा सकता है अनुसरण करता है.
android_app_certificate {
    name: "my_key_name",
    certificate: "dir/cert",
    // this will use dir/cert.x509.pem (the cert) and dir/cert.pk8 (the private key)
}

APEX इंस्टॉल करें

APEX इंस्टॉल करने के लिए, ADB का इस्तेमाल करें.

adb install apex_file_name
adb reboot

अगर apex_manifest.json में supportsRebootlessUpdate को true पर सेट किया जाता है और फ़िलहाल, इंस्टॉल किया गया APEX इस्तेमाल नहीं किया गया है. उदाहरण के लिए, अगर इसमें मौजूद कोई सेवा है बंद कर दिया गया है), तो एक नया APEX फ़ंक्शन विज्ञापनों को --force-non-staged फ़्लैग.

adb install --force-non-staged apex_file_name

APEX का इस्तेमाल करना

फिर से चालू होने के बाद, APEX /apex/<apex_name>@<version> को माउंट किया जाता है डायरेक्ट्री. एक ही APEX के कई वर्शन एक साथ माउंट किए जा सकते हैं. माउंट पाथ में, सबसे नए वर्शन वाला माउंट पाथ है /apex/<apex_name> पर बाइंड-माउंट किया गया.

क्लाइंट, APEX से फ़ाइलों को पढ़ने या उन्हें एक्ज़ीक्यूट करने के लिए, बाइंड-माउंट किए गए पाथ का इस्तेमाल कर सकते हैं.

एपीएक्स का इस्तेमाल आम तौर पर इस तरह किया जाता है:

  1. जब डिवाइस/system/apex शिप किया गया.
  2. APEX में मौजूद फ़ाइलों को, /apex/<apex_name>/ पाथ से ऐक्सेस किया जाता है.
  3. जब /data/apex में APEX का अपडेट किया गया वर्शन इंस्टॉल किया जाता है, तो पाथ डिवाइस को फिर से चालू करने के बाद, नए APEX पर कर्सर ले जाता है.

APEX के साथ किसी सेवा को अपडेट करना

APEX का इस्तेमाल करके, किसी सेवा को अपडेट करने के लिए:

  1. सिस्टम पार्टीशन में सेवा को अपडेट करने लायक के रूप में मार्क करें. विकल्प जोड़ें updatable को सेवा की परिभाषा में बदला गया है.

    /system/etc/init/myservice.rc:

service myservice /system/bin/myservice
    class core
    user system
    ...
    updatable

  2. अपडेट की गई सेवा के लिए एक नई .rc फ़ाइल बनाएं. override विकल्प का इस्तेमाल करें में आपका स्वागत है.

    /apex/my.apex/etc/init.rc:

service myservice /apex/my.apex/bin/myservice
    class core
    user system
    ...
    override

सेवा की परिभाषाएं, APEX की सिर्फ़ .rc फ़ाइल में तय की जा सकती हैं. ऐक्शन गेम APEXes में ट्रिगर काम नहीं करते.

अगर APEXes चालू होने से पहले, अपडेट की जा सकने वाली सेवा के तौर पर मार्क की गई सेवा शुरू होती है, तो APEXes को चालू करने की प्रोसेस पूरी होने तक, शुरू होने में देरी होगी.

APEX अपडेट के साथ काम करने के लिए सिस्टम कॉन्फ़िगर करें

APEX फ़ाइल को अपडेट करने के लिए, इस सिस्टम प्रॉपर्टी को true पर सेट करें.

<device.mk>:

PRODUCT_PROPERTY_OVERRIDES += ro.apex.updatable=true

BoardConfig.mk:
TARGET_FLATTEN_APEX := false

या बस

<device.mk>:

$(call inherit-product, $(SRC_TARGET_DIR)/product/updatable_apex.mk)

चपटे हुए एपेक्स

लेगसी डिवाइसों के लिए, कभी-कभी पुराने वर्शन को अपडेट करना नामुमकिन या मुश्किल होता है APEX के साथ पूरी तरह से काम करने के लिए कर्नेल. उदाहरण के लिए, हो सकता है कि कर्नेल को बनाया गया हो CONFIG_BLK_DEV_LOOP=Y के बिना, जो फ़ाइल सिस्टम को माउंट करने के लिए ज़रूरी है APEX में शामिल इमेज.

फ़्लैट किया गया APEX खास तौर पर बनाया गया APEX है. इसे उन डिवाइसों पर चालू किया जा सकता है जिनमें लेगसी कर्नेल. फ़्लैट किए गए APEX में मौजूद फ़ाइलें, सीधे डायरेक्ट्री में इंस्टॉल की जाती हैं का सेक्शन भी मिलेगा. उदाहरण के लिए, चपटे APEX में lib/libFoo.so my.apex को /system/apex/my.apex/lib/libFoo.so पर इंस्टॉल किया गया है.

फ़्लैट किए गए APEX को चालू करने में लूप डिवाइस शामिल नहीं होता. पूरा /system/apex/my.apex डायरेक्ट्री, /apex/name@ver के साथ सीधे तौर पर माउंट की गई है.

अपडेट किए गए वर्शन डाउनलोड करने पर, फ़्लैट किए गए APEXs अपडेट नहीं किए जा सकते APEX नेटवर्क में शामिल हो गए, क्योंकि डाउनलोड किए गए APEXe फ़्लैट नहीं किए जा सकते. फ़्लैट किए गए एपेक्स, सिर्फ़ सामान्य ओटीए की मदद से अपडेट किए जा सकते हैं.

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

डिवाइस में चपटे और नॉन-फ़्लैट किए गए एपेक्स को मिलाना नहीं होता समर्थित हैं. किसी डिवाइस में मौजूद एपीएक्स, सभी फ़्लैट किए गए होने चाहिए या सभी फ़्लैट किए जाने चाहिए. खास तौर पर, यह तब ज़रूरी होता है, जब शिपिंग के लिए पहले से साइन किया गया APEX पहले से बनाया गया हो Mainline जैसे प्रोजेक्ट करते हैं. ऐसे APEXेस जो पहले से हस्ताक्षर नहीं किए गए हैं (यानी, जिन्हें इनसे बनाया गया है स्रोत) भी बिना सपाट होने चाहिए और सही कुंजियों के साथ हस्ताक्षर किए जाने चाहिए. कॉन्टेंट बनाने डिवाइस को updatable_apex.mk से इनहेरिट करना चाहिए जैसा कि यहां बताया गया है APEX के साथ किसी सेवा को अपडेट करना.

कंप्रेस किए गए APEX

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

APEX कंप्रेशन, स्टोरेज के इस असर को कम करता है. इसके लिए, ज़्यादा कंप्रेस किए गए सेट का इस्तेमाल किया जाता है APEX फ़ाइलें सिर्फ़ पढ़ने के लिए (जैसे कि /system पार्टिशन) में सेव होती हैं. Android पर 12 और उसके बाद के वर्शन में, DEFLATE zip कंप्रेशन एल्गोरिदम का इस्तेमाल करने की सुविधा मिलती है.

कंप्रेशन से इन्हें ऑप्टिमाइज़ नहीं किया जाता:

  • ऐसे बूटस्ट्रैप APEXेस जिन्हें बूट में बहुत पहले माउंट किया जाना आवश्यक है क्रम.

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

  • डाइनैमिक शेयर की गई लिब्स APEXes. क्योंकि apexd हमेशा इसके दोनों वर्शन चालू करता है जैसे, पहले से इंस्टॉल किए गए और अपग्रेड किए गए ऐसे APEXेस, तो उन्हें कंप्रेस करने से कोई फ़ायदा नहीं होता.

कंप्रेस किया गया APEX फ़ाइल फ़ॉर्मैट

यह कंप्रेस की गई APEX फ़ाइल का फ़ॉर्मैट है.

डायग्राम में, कंप्रेस की गई APEX फ़ाइल का फ़ॉर्मैट दिखाया गया है

दूसरा डायग्राम. कंप्रेस किया गया APEX फ़ाइल फ़ॉर्मैट

सबसे ऊपर के लेवल पर, कंप्रेस की गई APEX फ़ाइल एक ऐसी ZIP फ़ाइल होती है जिसमें ओरिजनल फ़ाइल होती है 9 के कंप्रेशन लेवल के साथ apex फ़ाइल और अन्य फ़ाइलों के साथ डिफ़्लैटेड फ़ॉर्म बिना कंप्रेस की हुई सेव की गई प्रॉपर्टी.

चार फ़ाइलें जिनमें एक APEX फ़ाइल शामिल होती है:

  • original_apex: कंप्रेशन लेवल 9 के साथ डिफ़्लेट किया गया यह ओरिजनल, बिना कंप्रेस की गई APEX फ़ाइल है.
  • apex_manifest.pb: सिर्फ़ सेव किया गया
  • AndroidManifest.xml: सिर्फ़ सेव किया गया
  • apex_pubkey: सिर्फ़ सेव किया गया

apex_manifest.pb, AndroidManifest.xml, और apex_pubkey फ़ाइलें original_apex में अपनी संबंधित फ़ाइलों की कॉपी बना लें.

कंप्रेस किया गया APEX बनाएं

कंप्रेस की गई APEX वैल्यू, यहां मौजूद apex_compression_tool.py टूल का इस्तेमाल करके बनाई जा सकती है: system/apex/tools.

बिल्ड सिस्टम में APEX कंप्रेशन से जुड़े कई पैरामीटर उपलब्ध हैं.

Android.bp में, APEX फ़ाइल को कंप्रेस किया जा सकता है या नहीं compressible प्रॉपर्टी:

apex {
    name: "apex.test",
    manifest: "apex_manifest.json",
    file_contexts: "file_contexts",
    compressible: true,
}

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

लोकल एक्सपेरिमेंट के लिए, किसी बिल्ड को एपीईएक्स को कंप्रेस करने के लिए ज़बरदस्ती सेट किया जा सकता है true के लिए OVERRIDE_PRODUCT_COMPRESSED_APEX=.

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

काम करने वाले कंप्रेशन एल्गोरिदम

Android 12 में सिर्फ़ deflate-zip कंप्रेशन की सुविधा है.

बूट के दौरान कंप्रेस की गई APEX फ़ाइल चालू करें

कंप्रेस की गई APEX फ़ाइल को चालू करने से पहले, इसके अंदर मौजूद original_apex फ़ाइल /data/apex/decompressed डायरेक्ट्री में डीकंप्रेस किया गया. नतीजे के तौर पर मिला नतीजा डिकंप्रेस की गई APEX फ़ाइल, /data/apex/active डायरेक्ट्री से हार्ड-लिंक की गई है.

इस उदाहरण को ऊपर बताई गई प्रोसेस के उदाहरण के तौर पर देखें.

/system/apex/com.android.foo.capex को कंप्रेस किया गया APEX फ़ंक्शन वर्शन कोड 37 के साथ चालू की गई.

  1. /system/apex/com.android.foo.capex के अंदर original_apex फ़ाइल यह है /data/apex/decompressed/com.android.foo@37.apex में डीकंप्रेस किया गया.
  2. restorecon /data/apex/decompressed/com.android.foo@37.apex से कार्रवाई की जाती है पुष्टि करें कि इसमें SELinux लेबल सही है.
  3. पुष्टि की जांच इस दौरान की जाती हैं इसकी वैधता पक्का करने के लिए /data/apex/decompressed/com.android.foo@37.apex: apexd, बंडल किए गए सार्वजनिक पासकोड की जांच करता है पुष्टि करने के लिए /data/apex/decompressed/com.android.foo@37.apex दबाएं कि यह वैल्यू बराबर है /system/apex/com.android.foo.capex के बंडल किए गए के लिए.
  4. /data/apex/decompressed/com.android.foo@37.apex फ़ाइल इससे हार्ड-लिंक की गई है /data/apex/active/com.android.foo@37.apex डायरेक्ट्री.
  5. बिना कंप्रेस की गई APEX फ़ाइलों के लिए, रेगुलर ऐक्टिवेशन लॉजिक इन पर किया जाता है /data/apex/active/com.android.foo@37.apex.

ओटीए के साथ इंटरैक्शन

कंप्रेस की गई APEX फ़ाइलों का ओटीए डिलीवरी और ऐप्लिकेशन पर असर होता है. से एक ओटीए अपडेट में, उच्च वर्शन लेवल वाली कंप्रेस की गई APEX फ़ाइल हो सकती है की तुलना में, डिवाइस पर एक निश्चित मात्रा में खाली स्थान आरक्षित होना चाहिए ओटीए अपडेट लागू करने के लिए, डिवाइस को फिर से चालू करने से पहले.

ओटीए सिस्टम के साथ काम करने के लिए, apexd इन दो बाइंडर एपीआई को दिखाता है:

  • calculateSizeForCompressedApex - डीकंप्रेस करने के लिए ज़रूरी साइज़ की गणना करता है OTA पैकेज में APEX फ़ाइलें. इसका इस्तेमाल यह पुष्टि करने के लिए किया जा सकता है कि किसी डिवाइस में OTA को डाउनलोड करने से पहले काफ़ी जगह खाली कर देता है.
  • reserveSpaceForCompressedApex - भविष्य में इस्तेमाल के लिए डिस्क पर जगह सुरक्षित रखता है OTA पैकेज में कंप्रेस की गई APEX फ़ाइलों को डीकंप्रेस करने के लिए apexd ने.

A/B OTA अपडेट के मामले में, apexd पोस्टइंस्टॉल ओटीए रूटीन के हिस्से के तौर पर बैकग्राउंड. अगर डीकंप्रेशन फ़ेल हो जाता है, ओटीए चालू होने पर, apexd डिवाइस को चालू करने के दौरान कंप्रेस करने की प्रोसेस करता है अपडेट.

एपेक्स को डेवलप करते समय इन विकल्पों पर ध्यान दिया जाता है

APEX फ़ाइल को डिज़ाइन करते समय, एओएसपी इन विकल्पों का इस्तेमाल करती है शामिल करने या बाहर रखने की वजह दी गई है.

नियमित पैकेज मैनेजमेंट सिस्टम

Linux डिस्ट्रिब्यूशन में dpkg और rpm जैसे पैकेज मैनेजमेंट सिस्टम होते हैं, जो ताकतवर, परिपक्व, और मज़बूत हैं. हालांकि, उन्होंने इसे APEX के लिए अपनाया गया है, क्योंकि वे इतनी देर के बाद पैकेज की सुरक्षा नहीं कर सकते इंस्टॉल करना. पैकेज इंस्टॉल होने के बाद ही पुष्टि की जाती है. हमलावर, डिवाइस में इंस्टॉल किए गए पैकेज की सुरक्षा को नुकसान पहुंचा सकते हैं, क्योंकि उन्हें पता नहीं चलता. यह है Android के लिए एक रिग्रेशन, जिसमें सिस्टम के सभी कॉम्पोनेंट रीड-ओनली मोड में सेव किए गए थे ऐसे फ़ाइल सिस्टम की अनुमति देता है जिसकी इंटिग्रिटी की सुरक्षा, हर I/O के लिए डीएम-वेरिटी से की जाती है. कोई भी सिस्टम के कॉम्पोनेंट के साथ छेड़छाड़ करने पर या तो रोक लगी होनी चाहिए या उसका पता चलना चाहिए कि छेड़छाड़ किए जाने पर डिवाइस बूट नहीं हो सकता है.

इंटिग्रिटी के लिए डीएम-क्रिप्ट

APEX कंटेनर में मौजूद फ़ाइलें, पहले से मौजूद पार्टिशन से होती हैं (उदाहरण के लिए, /system पार्टीशन) जो dm-verity से सुरक्षित है, जहां कोई भी बदलाव हो सकता है पार्टिशन माउंट होने के बाद भी फ़ाइलों पर पाबंदी लगी रहती है. यह जानकारी देने के लिए फ़ाइलों के लिए सुरक्षा के स्तर की वजह से, APEX की सभी फ़ाइलें एक फ़ाइल में सेव की जाती हैं हैश ट्री और vbmeta डिस्क्रिप्टर के साथ जोड़ी जाने वाली सिस्टम इमेज. इसके बिना dm-verity, /data पार्टीशन में मौजूद APEX फ़ंक्शन, अनजाने में होने वाले जोखिम की आशंका है जो पुष्टि और इंस्टॉल हो जाने के बाद किए जाते हैं.

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

पाथ को /system से /apex पर रीडायरेक्ट करें

APEX में पैकेज की गई सिस्टम कॉम्पोनेंट फ़ाइलें, नए पाथ से ऐक्सेस की जा सकती हैं, जैसे कि /apex/<name>/lib/libfoo.so. जब ये फ़ाइलें /system का हिस्सा थीं विभाजन के बाद, उन्हें /system/lib/libfoo.so जैसे पाथ से ऐक्सेस किया जा सकता था. ऐप्लिकेशन APEX फ़ाइल (अन्य APEX फ़ाइलें या प्लैटफ़ॉर्म) के क्लाइंट को पाथ. पाथ बदलने की वजह से, आपको मौजूदा कोड को अपडेट करना पड़ सकता है.

हालांकि पाथ बदलने से बचने का एक तरीका यह है कि फ़ाइल के कॉन्टेंट को APEX फ़ाइल को /system पार्टीशन में जोड़ा गया, तो Android टीम ने उसे ओवरले न करने का फ़ैसला लिया फ़ाइलों को /system विभाजन में रखने से उन फ़ाइलों की संख्या जिन पर ओवरले किया जा रहा है (हो सकता है कि एक के बाद एक स्टैक किए गए हों) बढ़ोतरी हुई.

दूसरा विकल्प open, stat, और जैसे कि फ़ाइल ऐक्सेस करने वाले फ़ंक्शन को हाइजैक करना था readlink है, ताकि /system से शुरू होने वाले पाथ को उनके /apex में दिए गए मिलते-जुलते पाथ. Android टीम ने इस विकल्प को खारिज कर दिया है क्योंकि पाथ को स्वीकार करने वाले सभी फ़ंक्शन में बदलाव नहीं किया जा सकता. उदाहरण के लिए, कुछ ऐप्लिकेशन बायोनिक को स्टैटिक रूप से लिंक करते हैं, जो फ़ंक्शन लागू करता है. ऐसे मामलों में, उन ऐप्लिकेशन को रीडायरेक्ट नहीं किया जाता.