बिल्ड में जोड़े गए फ़ाइल सिस्टम ऑब्जेक्ट और सेवाओं के लिए, अक्सर अलग-अलग यूनीक आईडी की ज़रूरत होती है. इन आईडी को Android आईडी (एआईडी) कहा जाता है. फ़िलहाल, फ़ाइलों और सेवाओं जैसे कई संसाधन, बिना वजह कोर (Android के तय किए गए) AID का इस्तेमाल करते हैं. कई मामलों में इसके बजाय OEM (OEM के तय किए गए) AID का इस्तेमाल किया जा सकता है.
Android के पुराने वर्शन (Android 7.x और उससे पहले के वर्शन), डिवाइस के हिसाब से बनाई गई android_filesystem_config.h
फ़ाइल का इस्तेमाल करके, एआईडी के तरीके को बेहतर बनाते हैं. इससे फ़ाइल सिस्टम की सुविधाओं और/या कस्टम OEM एआईडी के बारे में जानकारी मिलती है. हालांकि, यह सिस्टम आसान नहीं था, क्योंकि यह OEM AID के लिए अच्छे नामों का इस्तेमाल नहीं करता था. साथ ही, आपको उपयोगकर्ता और ग्रुप फ़ील्ड के लिए रॉ न्यूमेरिक डालना पड़ता था. साथ ही, न्यूमेरिक AID के साथ कोई आसान नाम जोड़ने का विकल्प भी नहीं था.
Android के नए वर्शन (Android 8.0 और इसके बाद वाले वर्शन) में फ़ाइल सिस्टम की सुविधाओं को बढ़ाने के लिए, एक नया तरीका इस्तेमाल किया जा सकता है. इस नए तरीके से, ये काम किए जा सकते हैं:
- कॉन्फ़िगरेशन फ़ाइलों के लिए कई सोर्स लोकेशन (बड़े किए जा सकने वाले बिल्ड कॉन्फ़िगरेशन को चालू करता है).
- OEM AID की वैल्यू की बिल्ड-टाइम में जांच करना.
- कस्टम OEM AID हेडर जनरेट करना, जिसका इस्तेमाल ज़रूरत के हिसाब से सोर्स फ़ाइलों में किया जा सकता है.
- OEM AID की असल वैल्यू के साथ कोई आसान नाम जोड़ना. उपयोगकर्ता और ग्रुप के लिए, संख्या के बजाय स्ट्रिंग वाले आर्ग्युमेंट का इस्तेमाल किया जा सकता है. जैसे, "2901" के बजाय "foo".
अन्य सुधारों में, system/core/libcutils/include/private/android_filesystem_config.h
से android_ids[]
पंक्ति को हटाना शामिल है. यह ऐरे अब Bionic में, पूरी तरह से निजी तौर पर जनरेट किए गए ऐरे के तौर पर मौजूद है. इसमें getpwnam()
और getgrnam()
वाले ऐक्सेसर्स हैं. (इससे, कोर एआईडी में बदलाव किए जाने की वजह से, स्थिर बाइनरी बनाने का साइड इफ़ेक्ट होता है.) टूल
और ज़्यादा जानकारी वाली README फ़ाइल के लिए, build/make/tools/fs_config
देखें.
Android आईडी (AID) जोड़ना
Android 8.0 ने Android
ओपन सोर्स प्रोजेक्ट (AOSP) से android_ids[]
कलेक्शन को हटा दिया है. इसके बजाय, Bionic android_ids[]
कलेक्शन जनरेट करते समय, system/core/libcutils/include/private/android_filesystem_config.h
हेडर फ़ाइल से सभी एआईडी-फ़्रेंडली नाम जनरेट किए जाते हैं. टूल, AID_*
से मैच करने वाला कोई भी define
चुन लेता है और * लोअरकेस नाम बन जाता है.
उदाहरण के लिए, private/android_filesystem_config.h
में:
#define AID_SYSTEM 1000
बनने वाला है:
- दोस्ताना नाम: सिस्टम
- uid: 1000
- जीआईडी: 1000
नया AOSP कोर AID जोड़ने के लिए, android_filesystem_config.h
हेडर फ़ाइल में #define
जोड़ें. AID, बिल्ड के समय जनरेट होता है और उपयोगकर्ता और ग्रुप ऑर्ग्युमेंट का इस्तेमाल करने वाले इंटरफ़ेस के लिए उपलब्ध कराया जाता है. टूल की मदद से इस बात की पुष्टि होती है कि नया AID, ऐप्लिकेशन या OEM
रेंज में शामिल नहीं है. साथ ही, टूल की मदद से,
उन रेंज में किए गए बदलावों को भी ध्यान में रखा जाता है. साथ ही, बदलावों को या OEM के लिए रिज़र्व की गई नई रेंज पर, इसे अपने-आप फिर से कॉन्फ़िगर किया जाना चाहिए.
एआईडी कॉन्फ़िगर करना
नए AIDs मैकेनिज़्म को चालू करने के लिए, BoardConfig.mk
फ़ाइल में
TARGET_FS_CONFIG_GEN
को सेट करें. इस वैरिएबल में, कॉन्फ़िगरेशन
फ़ाइलों की सूची होती है. इससे ज़रूरत के हिसाब से फ़ाइलें जोड़ी जा सकती हैं.
आम तौर पर, कॉन्फ़िगरेशन फ़ाइलों में config.fs
नाम का इस्तेमाल किया जाता है. हालांकि, असल में किसी भी नाम का इस्तेमाल किया जा सकता है. config.fs
फ़ाइलें,
Python
ConfigParser ini फ़ॉर्मैट में होती हैं. इनमें caps सेक्शन (फ़ाइल सिस्टम की सुविधाओं को कॉन्फ़िगर करने के लिए) और AIDs सेक्शन (OEM AIDs को कॉन्फ़िगर करने के लिए) शामिल होता है.
कैप्स सेक्शन को कॉन्फ़िगर करना
कैप सेक्शन में, बिल्ड में मौजूद फ़ाइल सिस्टम ऑब्जेक्ट पर फ़ाइल सिस्टम की सुविधाएं सेट की जा सकती हैं. हालांकि, इसके लिए ज़रूरी है कि फ़ाइल सिस्टम खुद भी इस सुविधा के साथ काम करता हो.
Android में किसी सेवा को रूट के तौर पर चलाने पर, कंपैटिबिलिटी टेस्ट सुइट (CTS) काम नहीं करता. इसलिए, किसी प्रोसेस या सेवा को चलाते समय किसी सुविधा को बनाए रखने के लिए, पहले ज़रूरी थी कि आपने सुविधाओं को सेट अप किया हो. इसके बाद, setuid
/setgid
का इस्तेमाल करके, सही एआईडी को चलाया जा सकता था. कैप का इस्तेमाल करके, इन
ज़रूरी शर्तों को छोड़ा जा सकता है और कर्नेल से यह काम पूरा किया जा सकता है. जब main()
को कंट्रोल दिया जाता है, तो आपकी प्रोसेस में पहले से ही ज़रूरी सुविधाएं मौजूद होती हैं, ताकि आपकी सेवा किसी ऐसे उपयोगकर्ता और ग्रुप का इस्तेमाल कर सके जो रूट नहीं है. यह, खास सुविधाओं वाली सेवाएं शुरू करने का सबसे सही तरीका है.
कैप सेक्शन में, इस सिंटैक्स का इस्तेमाल किया जाता है:
सेक्शन | वैल्यू | परिभाषा |
---|---|---|
[path] |
कॉन्फ़िगर करने के लिए फ़ाइल सिस्टम पाथ. / पर खत्म होने वाले पाथ को डायरेक्ट्री माना जाता है,
अन्यथा इसे फ़ाइल माना जाता है.
अलग-अलग फ़ाइलों में एक ही [path] वाले कई सेक्शन तय करना गड़बड़ी है. Python के 3.2 से पहले के वर्शन में, एक ही फ़ाइल में ऐसे सेक्शन हो सकते हैं जो पिछले सेक्शन को बदल देते हैं. Python 3.2 में, इसे स्ट्रिक्ट मोड पर सेट किया गया है. |
|
mode |
ऑक्टल फ़ाइल मोड | कम से कम तीन अंकों वाला मान्य ऑक्टल फ़ाइल मोड. अगर 3 दिया गया है, तो उससे पहले 0 जोड़ दिया जाता है. ऐसा न करने पर, मोड का इस्तेमाल वैसे ही किया जाता है. |
user |
एआईडी_<उपयोगकर्ता> | मान्य AID के लिए C define या आसान नाम
(उदाहरण के लिए, AID_RADIO और radio , दोनों स्वीकार किए जाते हैं). कस्टम AID तय करने के लिए, AID सेक्शन को कॉन्फ़िगर करना लेख पढ़ें. |
group |
AID_<group> | उपयोगकर्ता की तरह. |
caps |
कैप* | bionic/libc/kernel/uapi/linux/capability.h में बताए गए नाम में, CAP_ को हटा दें. छोटे-बड़े अक्षरों का इस्तेमाल किया जा सकता है. कैप को रॉ के तौर पर भी इस्तेमाल किया जा सकता है:
|
इस्तेमाल के उदाहरण के लिए, फ़ाइल सिस्टम की क्षमताओं का इस्तेमाल करना देखें.
AID सेक्शन कॉन्फ़िगर करना
AID सेक्शन में OEM AID शामिल होते हैं और यह इस सिंटैक्स का इस्तेमाल करता है:
सेक्शन | वैल्यू | परिभाषा |
---|---|---|
[AID_<name>] |
<name> में, अंग्रेज़ी के बड़े अक्षरों, अंकों, और अंडरस्कोर वाले वर्ण हो सकते हैं. छोटे अक्षरों वाले वर्शन का इस्तेमाल,
आसान नाम के तौर पर किया जाता है. कोड शामिल करने के लिए, जनरेट की गई हेडर फ़ाइल सटीक
AID_<name> का इस्तेमाल करती है.
एक ही AID_<name> के साथ कई सेक्शन तय करना गड़बड़ी है. [path] की तरह ही, इसमें भी केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) की शर्तें लागू होती हैं.
<name> को पार्टीशन के नाम से शुरू करना ज़रूरी है, ताकि यह पक्का किया जा सके कि यह अलग-अलग सोर्स से मेल न खाए. |
|
value |
<number> | C स्टाइल की मान्य संख्या वाली स्ट्रिंग (हेक्स, ऑक्टल, बाइनरी, और दशमलव).
एक ही वैल्यू के विकल्प के साथ कई सेक्शन तय करना गड़बड़ी है. वैल्यू के विकल्प, <name> में इस्तेमाल किए गए partition के हिसाब से तय की गई रेंज में होने चाहिए. मान्य पार्टीशन और उनसे जुड़ी रेंज की सूची system/core/libcutils/include/private/android_filesystem_config.h में दी गई है.
इसके विकल्प:
|
इस्तेमाल के उदाहरणों के लिए, OEM AID के नाम तय करना और OEM AID का इस्तेमाल करना लेख पढ़ें.
इस्तेमाल के उदाहरण
इन उदाहरणों में, OEM AID को तय करने, इस्तेमाल करने, और फ़ाइल सिस्टम की सुविधाओं को चालू करने के तरीके के बारे में बताया गया है. OEM AID के नाम ([AID_name]), "vendor_" जैसे किसी पार्टिशन के नाम से शुरू होने चाहिए. इससे यह पक्का किया जा सकेगा कि ये नाम, आने वाले समय में AOSP के नाम या अन्य पार्टिशन के नाम से मेल न खाएं.
OEM AID के नाम तय करना
OEM AID तय करने के लिए, config.fs
फ़ाइल बनाएं और AID वैल्यू सेट करें. उदाहरण के लिए, device/x/y/config.fs
में ये सेट करें:
[AID_VENDOR_FOO] value: 2900
फ़ाइल बनाने के बाद, TARGET_FS_CONFIG_GEN
वैरिएबल सेट करें और BoardConfig.mk
में उस पर ले जाएं. उदाहरण के लिए, device/x/y/BoardConfig.mk
में, ये सेट करें:
TARGET_FS_CONFIG_GEN += device/x/y/config.fs
अब नए बिल्ड में, सिस्टम आपके कस्टम AID का इस्तेमाल कर सकता है.
OEM AID का इस्तेमाल करना
OEM AID का इस्तेमाल करने के लिए, अपने C कोड में, उससे जुड़ी
Makefile में oemaids_headers
शामिल करें और #include "generated_oem_aid.h"
जोड़ें. इसके बाद, एलान किए गए
आइडेंटिफ़ायर का इस्तेमाल शुरू करें. उदाहरण के लिए, my_file.c
में यह जोड़ें:
#include "generated_oem_aid.h" … If (ipc->uid == AID_VENDOR_FOO) { // Do something ...
अपनी Android.bp
फ़ाइल में, यह जानकारी जोड़ें:
header_libs: ["oemaids_headers"],
अगर Android.mk
फ़ाइल का इस्तेमाल किया जा रहा है, तो ये जोड़ें:
LOCAL_HEADER_LIBRARIES := oemaids_headers
जाने-पहचाने नाम इस्तेमाल करें
Android 9 में, AID नेम के साथ काम करने वाले किसी भी इंटरफ़ेस के लिए, आसान नाम का इस्तेमाल किया जा सकता है. उदाहरण के लिए:
some/init.rc
मेंchown
कमांड में:chown vendor_foo /vendor/some/vendor_foo/file
some/init.rc
मेंservice
में:service vendor_foo /vendor/bin/foo_service user vendor_foo group vendor_foo
फ़्रेंडली नाम से uid तक की इंटरनल मैपिंग,
/vendor/etc/passwd
और /vendor/etc/group
करते हैं. इसलिए, वेंडर वाले सेगमेंट को माउंट करना ज़रूरी है.
आसान नाम जोड़ना
Android 9 में, OEM AID की असल वैल्यू के साथ, आसान नाम जोड़ने की सुविधा शामिल है. उपयोगकर्ता और ग्रुप के लिए, अंकों के बजाय स्ट्रिंग वाले आर्ग्युमेंट का इस्तेमाल किया जा सकता है. जैसे, "2901" के बजाय "vendor_foo".
AID को आसान नामों में बदलना
OEM AIDs के लिए, Android 8.x में getpwnam
और मिलते-जुलते फ़ंक्शन के साथ oem_####
का इस्तेमाल करना ज़रूरी था. साथ ही, getpwnam
के साथ लुकअप मैनेज करने वाली जगहों (जैसे, init
स्क्रिप्ट) पर भी ऐसा करना ज़रूरी था. Android 9 में, Android आईडी (AID) को आसान नामों में बदलने और आसान नामों को Android आईडी में बदलने के लिए, Bionic में getpwnam
और getgrnam
फ़्रेंड का इस्तेमाल किया जा सकता है.
फ़ाइल सिस्टम की सुविधाओं का इस्तेमाल करना
फ़ाइल सिस्टम की सुविधाएं चालू करने के लिए, config.fs
फ़ाइल में एक कैप सेक्शन बनाएं. उदाहरण के लिए,
device/x/y/config.fs
में यह सेक्शन जोड़ें:
[system/bin/foo_service] mode: 0555 user: AID_VENDOR_FOO group: AID_SYSTEM caps: SYS_ADMIN | SYS_NICE
फ़ाइल बनाने के बाद, BoardConfig.mk
में उस फ़ाइल पर ले जाने के लिए TARGET_FS_CONFIG_GEN
सेट करें. उदाहरण के लिए, device/x/y/BoardConfig.mk
में, ये सेट करें:
TARGET_FS_CONFIG_GEN += device/x/y/config.fs
सेवा vendor_foo
को लागू करने पर, यह setuid
और setgid
कॉल के बिना,
CAP_SYS_ADMIN
और CAP_SYS_NICE
सुविधाओं के साथ शुरू होती है. इसके अलावा, vendor_foo
सेवा की SELinux नीति को अब setuid
और setgid
की सुविधा की ज़रूरत नहीं है. इसलिए, इन्हें मिटाया जा सकता है.
बदलावों को कॉन्फ़िगर करना (Android 6.x-7.x)
Android 6.0 ने fs_config
और उससे जुड़ी स्ट्रक्चर की परिभाषाओं (system/core/include/private/android_filesystem_config.h
) को system/core/libcutils/fs_config.c
पर भेज दिया है. यहां उन्हें /system/etc/fs_config_dirs
और /system/etc/fs_config_files
में इंस्टॉल की गई बाइनरी फ़ाइलों से अपडेट किया जा सकता है या बदला जा सकता है. डायरेक्ट्री और फ़ाइलों के लिए, मैचिंग और पार्स करने के अलग-अलग नियमों (इसमें अतिरिक्त ग्लोब एक्सप्रेशन का इस्तेमाल हो सकता है) का इस्तेमाल करने से Android को दो अलग-अलग टेबल में डायरेक्ट्री और फ़ाइलों को मैनेज करने में मदद मिली.
system/core/libcutils/fs_config.c
में मौजूद स्ट्रक्चर की परिभाषाओं की मदद से,
रनटाइम के दौरान डायरेक्ट्री और फ़ाइलों को पढ़ा जा सकता है. साथ ही, होस्ट उन फ़ाइलों का इस्तेमाल, बिल्ड के समय ${OUT}/system/etc/fs_config_dirs
और
${OUT}/system/etc/fs_config_files
के तौर पर फ़ाइल सिस्टम इमेज बनाने के लिए कर सकता है.
फ़ाइल सिस्टम को बड़ा करने के लिए, ओवरराइड करने के तरीके की जगह, Android 8.0 में पेश किए गए मॉड्यूलर कॉन्फ़िगरेशन सिस्टम का इस्तेमाल किया जाता है. हालांकि, आपके पास अब भी पुराने तरीके का इस्तेमाल करने का विकल्प है. नीचे दिए गए सेक्शन में, बदलाव करने वाली फ़ाइलों को जनरेट करने और शामिल करने के साथ-साथ, फ़ाइल सिस्टम को कॉन्फ़िगर करने का तरीका बताया गया है.
बदलाव करने वाली फ़ाइलें जनरेट करना
build/tools/fs_config
में fs_config_generate
टूल का इस्तेमाल करके, अलाइन की गई बाइनरी फ़ाइलें /system/etc/fs_config_dirs
और /system/etc/fs_config_files
जनरेट की जा सकती हैं. यह टूल, libcutils
लाइब्रेरी फ़ंक्शन (fs_config_generate()
) का इस्तेमाल करके, डीएसी की ज़रूरी शर्तों को बफ़र में मैनेज करता है. साथ ही, डीएसी के नियमों को लागू करने के लिए, शामिल की जाने वाली फ़ाइल के लिए नियम तय करता है.
इसका इस्तेमाल करने के लिए, device/vendor/device/android_filesystem_config.h
में एक शामिल फ़ाइल बनाएं, जो बदलाव करने के तौर पर काम करती है. फ़ाइल में, डायरेक्ट्री और फ़ाइल सिंबल के लिए, system/core/include/private/android_filesystem_config.h
में बताए गए structure fs_path_config
फ़ॉर्मैट का इस्तेमाल करना ज़रूरी है. साथ ही, स्ट्रक्चर को इनके हिसाब से शुरू करना होगा:
- डायरेक्ट्री के लिए,
android_device_dirs[]
का इस्तेमाल करें. - फ़ाइलों के लिए,
android_device_files[]
का इस्तेमाल करें.
android_device_dirs[]
और
android_device_files[]
का इस्तेमाल नहीं करते समय, NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS
और
NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_FILES
को तय किया जा सकता है. (नीचे
उदाहरण देखें). बोर्ड कॉन्फ़िगरेशन में TARGET_ANDROID_FILESYSTEM_CONFIG_H
का इस्तेमाल करके, बदली गई फ़ाइल की जानकारी भी दी जा सकती है. इसके लिए, android_filesystem_config.h
का इस्तेमाल करके, ज़रूरी बेसनेम तय करें.
ओवरराइड फ़ाइलें शामिल करें
फ़ाइलें शामिल करने के लिए, पक्का करें कि PRODUCT_PACKAGES
में
fs_config_dirs
और/या fs_config_files
शामिल हो, ताकि वह उन्हें
/system/etc/fs_config_dirs
और
/system/etc/fs_config_files
पर इंस्टॉल कर सके. बिल्ड सिस्टम, $(TARGET_DEVICE_DIR)
में कस्टम android_filesystem_config.h
खोजता है, जहां BoardConfig.mk
मौजूद है.
अगर यह फ़ाइल कहीं और मौजूद है, तो बोर्ड कॉन्फ़िगरेशन वैरिएबल
TARGET_ANDROID_FILESYSTEM_CONFIG_H
को उस जगह पर ले जाने के लिए सेट करें.
फ़ाइल सिस्टम कॉन्फ़िगर करें
Android 6.0 और इसके बाद के वर्शन में फ़ाइल सिस्टम को कॉन्फ़िगर करने के लिए:
$(TARGET_DEVICE_DIR)/android_filesystem_config.h
फ़ाइल बनाएं.- बोर्ड कॉन्फ़िगरेशन फ़ाइल में,
fs_config_dirs
और/याfs_config_files
कोPRODUCT_PACKAGES
में जोड़ें (उदाहरण के लिए,$(TARGET_DEVICE_DIR)/device.mk
).
उदाहरण बदलें
इस उदाहरण में, system/bin/glgps
डायरेक्ट्री में वॉकी-अप लॉक की सुविधा जोड़ने के लिए, device/vendor/device
डायरेक्ट्री में system/bin/glgps
डिमन को बदलने के लिए पैच दिखाया गया है. इन बातों का
ध्यान रखें:
- हर स्ट्रक्चर में मोड, uid, gid, क्षमताएं, और नाम शामिल होते हैं.
मेनिफ़ेस्ट #defines (
AID_ROOT
,AID_SHELL
,CAP_BLOCK_SUSPEND
) उपलब्ध कराने के लिए,system/core/include/private/android_filesystem_config.h
को अपने-आप शामिल किया जाता है. android_device_files[]
सेक्शन में,system/etc/fs_config_dirs
के ऐक्सेस को दबाने के लिए एक कार्रवाई शामिल होती है. ऐसा तब किया जाता है, जबsystem/etc/fs_config_dirs
के लिए कोई जानकारी नहीं दी जाती. यह डायरेक्ट्री के लिए कॉन्टेंट न होने पर, डीएसी की अतिरिक्त सुरक्षा के तौर पर काम करती है. हालांकि, यह सुरक्षा की कमज़ोर सुविधा है. अगर किसी व्यक्ति के पास/system
का कंट्रोल है, तो वह आम तौर पर अपनी मर्ज़ी से कुछ भी कर सकता है.
diff --git a/android_filesystem_config.h b/android_filesystem_config.h new file mode 100644 index 0000000..874195f --- /dev/null +++ b/android_filesystem_config.h @@ -0,0 +1,36 @@ +/* + * Copyright (C) 2015 The Android Open Source Project + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or + * implied. See the License for the specific language governing + * permissions and limitations under the License. + */ + +/* This file is used to define the properties of the file system +** images generated by build tools (eg: mkbootfs) and +** by the device side of adb. +*/ + +#define NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS +/* static const struct fs_path_config android_device_dirs[] = { }; */ + +/* Rules for files. +** These rules are applied based on "first match", so they +** should start with the most specific path and work their +** way up to the root. Prefixes ending in * denotes wildcard +** and will allow partial matches. +*/ +static const struct fs_path_config android_device_files[] = { + { 00755, AID_ROOT, AID_SHELL, (1ULL << CAP_BLOCK_SUSPEND), "system/bin/glgps" }, +#ifdef NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS + { 00000, AID_ROOT, AID_ROOT, 0, "system/etc/fs_config_dirs" }, +#endif +}; diff --git a/device.mk b/device.mk index 0c71d21..235c1a7 100644 --- a/device.mk +++ b/device.mk @@ -18,7 +18,8 @@ PRODUCT_PACKAGES := \ libwpa_client \ hostapd \ wpa_supplicant \ - wpa_supplicant.conf + wpa_supplicant.conf \ + fs_config_files ifeq ($(TARGET_PREBUILT_KERNEL),) ifeq ($(USE_SVELTE_KERNEL), true)
फ़ाइल सिस्टम को पिछले वर्शन से माइग्रेट करना
Android 5.x और उससे पहले के वर्शन से फ़ाइल सिस्टम माइग्रेट करते समय, ध्यान रखें कि Android 6.x
- कुछ शामिल किए गए एलिमेंट, स्ट्रक्चर, और इनलाइन परिभाषाओं को हटाता है.
- सीधे
system/core/include/private/android_filesystem_config.h
से चलाने के बजाय,libcutils
का रेफ़रंस ज़रूरी है. डिवाइस बनाने वाली कंपनी के निजी एक्सीक्यूटेबल, जो फ़ाइल या डायरेक्ट्री स्ट्रक्चर के लिएsystem/code/include/private_filesystem_config.h
याfs_config
पर निर्भर करते हैं उन्हेंlibcutils
लाइब्रेरी डिपेंडेंसी जोड़नी होंगी. - डिवाइस बनाने वाली कंपनी के पास,
system/core/include/private/android_filesystem_config.h
की निजी शाखा की कॉपी होनी चाहिए. साथ ही,device/vendor/device/android_filesystem_config.h
पर जाने के लिए, मौजूदा टारगेट पर ज़्यादा कॉन्टेंट होना चाहिए. - टारगेट सिस्टम पर कॉन्फ़िगरेशन फ़ाइलों पर, SELinux के ज़रूरी ऐक्सेस कंट्रोल (MAC) लागू करने का अधिकार सुरक्षित रखता है.
fs_config()
का इस्तेमाल करके, कस्टम टारगेट एक्सीक्यूटेबल को लागू करने के लिए, ऐक्सेस की पुष्टि करना ज़रूरी है.