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