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

जीकेआई और जीकेआई मॉड्यूल को, बाकी हिस्सों से अलग अपडेट किया जा सकता है क्योंकि सुपर इमेज में जीकेआई मॉड्यूल एक अलग डाइनैमिक पार्टीशन पर रहता है system_dlkm कॉल किया गया. Google, कर्नेल का इस्तेमाल करके GKI मॉड्यूल पर हस्ताक्षर करता है बिल्ड-टाइम कुंजी का जोड़ा और ये सिर्फ़ उस जीकेआई के साथ काम करते हैं जिससे इन्हें बनाया गया है. 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 को ऐसे फ़ोल्डर पर ले जाएं जिसमें ज़रूरी जीकेआई मॉड्यूल हों जनरेट करने के लिए बिल्ड सिस्टम के इनपुट के रूप में डिवाइस के लिए कर्नेल ऑब्जेक्ट फ़ाइलें system_dlkm विभाजन. उदाहरण के लिए:

किसी फ़ोल्डर में जीकेआई मॉड्यूल सोर्स दें और 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 के लिए

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

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

 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 में पर भी असर पड़ सकता है.

उदाहरण के लिए, GKI मॉड्यूल लोड करने के लिए Cuttlefish का इस्तेमाल करने वाले 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 पार्टीशन की पुष्टि करना

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

  atest -c vts_dlkm_partition_test