GKI मॉड्यूल का पार्टीशन लागू करना

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

system_dklm पार्टिशन के लिए सहायता लागू करना

system_dlkm पार्टिशन, सुपर पार्टिशन में एक अन्य डाइनैमिक पार्टिशन के तौर पर मौजूद होता है. इस पार्टीशन में ये चीज़ें शामिल हो सकती हैं:

  • Google के बिल्ड-टाइम पर हस्ताक्षर किए गए कर्नेल मॉड्यूल
  • depmod सह-उत्पाद

बिल्‍ड system_dlkm

system_dlkm बनाना, अन्य डाइनैमिक पार्टीशन बनाने की प्रोसेस जैसा ही है. अपने बिल्ड में system_dlkm जोड़ने के लिए, यह तरीका अपनाएं:

  1. BoardConfig.mk में, ये एंट्री जोड़ें:

    BOARD_USES_SYSTEM_DLKMIMAGE := true
    BOARD_SYSTEM_DLKMIMAGE_FILE_SYSTEM_TYPE := $(TARGET_RO_FILE_SYSTEM_TYPE)
    TARGET_COPY_OUT_SYSTEM_DLKM := system_dlkm
    
  2. पार्टिशन की सूची में, system_dlkm जोड़ें: BOARD_GOOGLE_SYSTEM_DYNAMIC_PARTITIONS_PARTITION_LIST := system_dlkm

  3. (ज़रूरी नहीं) A/B और वर्चुअल A/B डिवाइसों के लिए, अपने डिवाइस की device.mk फ़ाइल में यह लाइन जोड़ें:

    AB_OTA_PARTITIONS += system_dlkm
    

system_dlkm में कॉपी किए जाने वाले कर्नेल मॉड्यूल की पहचान करना

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

Android 13 के लिए

BOARD_SYSTEM_DLKM_SRC को उस फ़ोल्डर पर ले जाएं जिसमें डिवाइस के लिए ज़रूरी GKI मॉड्यूल वाली कर्नल ऑब्जेक्ट फ़ाइलें मौजूद हों. ऐसा इसलिए किया जाता है, ताकि बिल्ड सिस्टम को इनपुट के तौर पर ये फ़ाइलें मिल सकें और वह system_dlkm पार्टीशन जनरेट कर सके. उदाहरण के लिए:

किसी फ़ोल्डर में GKI मॉड्यूल का सोर्स उपलब्ध कराएं और BOARD_SYSTEM_DLKM_SRC को उस फ़ोल्डर पर ले जाएं. उदाहरण के लिए:

  BOARD_SYSTEM_DLKM_SRC := kernel/prebuilts/5.10/arm64/system_dlkm_staging

बिल्ड के समय, BOARD_SYSTEM_DLKM_SRC में शामिल मॉड्यूल, $ANDROID_PRODUCT_OUT/system_dlkm में इंस्टॉल किए जाते हैं.

Android 14 के लिए

हमने लागू करने की प्रोसेस को आसान बना दिया है. इसमें, अन्य *_dlkm पार्टीशन के लिए इस्तेमाल किए जा रहे मैक्रो (BOARD_*_KERNEL_MODULES) का इस्तेमाल किया जा रहा है. डिवाइस के लिए ज़रूरी GKI मॉड्यूल की सूची को BOARD_SYSTEM_KERNEL_MODULES मैक्रो से रेफ़रंस किया जाना चाहिए. बिल्ड के समय, इन मॉड्यूल को $ANDROID_PRODUCT_OUT/system_dlkm में इंस्टॉल किया जाता है. vendor_dlkm पार्टीशन में मौजूद किसी भी मॉड्यूल की डिपेंडेंसी, system_dlkm पार्टीशन में मौजूद मॉड्यूल पर होती है. इससे vendor_dlkm पार्टीशन के लिए, modules.dep फ़ाइल में सही रेफ़रंस जनरेट होते हैं. modules.dep से दिखाए गए क्रॉस-पार्टिशन डिपेंडेंसी की वजह से, जब कोई वेंडर मॉड्यूल लोड होता है, तो ज़रूरी GKI मॉड्यूल अपने-आप लोड हो जाता है.

उदाहरण के लिए, प्रीबिल्ट से जीकेआई arm64 कर्नेल 5.15 के लिए, system_dlkm पार्टीशन पर सभी जीकेआई मॉड्यूल इंस्टॉल करने के लिए:

 BOARD_SYSTEM_KERNEL_MODULES := $(wildcard kernel/prebuilts/5.15/arm64/*.ko)

रनटाइम के दौरान system_dlkm को माउंट करना

रीड-ओनली फ़ाइल सिस्टम के तौर पर इस्तेमाल किए जा रहे फ़ाइल सिस्टम के आधार पर, रनटाइम के दौरान system_dlkm पार्टिशन को माउंट करने के लिए, अपने fstab में यह जोड़ें:

ext4 को सिर्फ़ पढ़ने वाले फ़ाइल सिस्टम के तौर पर

  system_dlkm /system_dlkm ext4 noatime,ro,errors=panic wait,logical,first_stage_mount,slotselect,avb

erofs को सिर्फ़ पढ़ने वाले फ़ाइल सिस्टम के तौर पर

  system_dlkm /system_dlkm erofs ro wait,logical,first_stage_mount,slotselect,avb

पार्टिशन माउंट करना और मॉड्यूल लोड करना

first_stage_init के दौरान, system_dlkm पार्टीशन को /system_dlkm में सिर्फ़ पढ़ने वाले फ़ाइल सिस्टम के तौर पर माउंट किया जाता है. माउंट होने के बाद, /system/lib/modules पर मौजूद सिंबॉलिक लिंक, /system_dlkm/lib/modules पर पॉइंट करते हैं.

इसके बाद, वेंडर प्रोसेस, जैसे कि .rc स्क्रिप्ट, modules.load में दिए गए क्रम के आधार पर कर्नेल मॉड्यूल लोड कर सकती है. वेंडर प्रोसेस को मॉड्यूल लोड करने के लिए, सिंबॉलिक लिंक /system/lib/modules का इस्तेमाल करना होगा. अगर ज़रूरी हो, तो वेंडर प्रोसेस बाद में भी मॉड्यूल लोड कर सकती है.

SELinux

system_dlkm पार्टीशन में मौजूद हर फ़ाइल को, system_dlkm_file के फ़ाइल कॉन्टेक्स्ट के साथ लेबल किया जाता है. system_dlkm पार्टिशन में GKI मॉड्यूल फ़ाइल लोड करने के लिए, मॉड्यूल लोड करने की ज़िम्मेदारी वाली वेंडर प्रोसेस को वेंडर डोमेन में sepolicy की ज़रूरत होती है.

उदाहरण के लिए, Cuttlefish, GKI मॉड्यूल लोड करने के लिए dlkm_loader का इस्तेमाल करता है. इसके पास shared/sepolicy/vendor/dlkm_loader.te पर मौजूद नीति फ़ाइल में ये अनुमतियां होती हैं:

allow dlkm_loader self:capability sys_module;
allow dlkm_loader system_dlkm_file:dir r_dir_perms;
allow dlkm_loader system_dlkm_file:file r_file_perms;
allow dlkm_loader system_dlkm_file:system module_load;

system-dlkm पार्टीशन की पुष्टि करना

Google, system_dlkm पार्टिशन की पुष्टि करने के लिए, GKI VTS टेस्ट केस उपलब्ध कराता है. टेस्ट को मैन्युअल तरीके से शुरू करने के लिए, इस atest कमांड का इस्तेमाल करें:

  atest -c vts_dlkm_partition_test