डिस्क्रेशनरी ऐक्सेस कंट्रोल (डीएसी)

बिल्ड में जोड़े गए फ़ाइल सिस्टम ऑब्जेक्ट और सेवाओं के लिए, अक्सर अलग-अलग और यूनीक आईडी की ज़रूरत होती है. इन्हें Android आईडी (एआईडी) कहा जाता है. फ़िलहाल, फ़ाइलों और सेवाओं जैसे कई रिसॉर्स, बिना वजह कोर (Android की ओर से तय किए गए) एआईडी का इस्तेमाल करते हैं. कई मामलों में, ओईएम (ओईएम की ओर से तय किए गए) एआईडी का इस्तेमाल किया जा सकता है.

Android के पुराने वर्शन (Android 7.x और इससे पहले के वर्शन) में, डिवाइस के हिसाब से एआईडी के मैकेनिज़्म को बढ़ाया गया था. इससे फ़ाइल सिस्टम की क्षमताओं और/या ओईएम के कस्टम एआईडी तय किए जा सकते थे.android_filesystem_config.h हालांकि, यह सिस्टम सहज नहीं था, क्योंकि इसमें ओईएम एआईडी के लिए, आसानी से याद रखे जा सकने वाले नामों का इस्तेमाल नहीं किया जा सकता था. इसलिए, उपयोगकर्ता और ग्रुप फ़ील्ड के लिए, रॉ न्यूमेरिक तय करना ज़रूरी था. साथ ही, न्यूमेरिक एआईडी के साथ, आसानी से याद रखे जा सकने वाले नाम को जोड़ने का कोई तरीका नहीं था.

Android के नए वर्शन (Android 8.0 और इसके बाद के वर्शन) में, फ़ाइल सिस्टम की क्षमताओं को बढ़ाने के लिए, एक नया तरीका उपलब्ध है. इस नए तरीके में, ये सुविधाएं उपलब्ध हैं:

• कॉन्फ़िगरेशन फ़ाइलों के लिए, एक से ज़्यादा सोर्स की जगहें (इससे, एक्सटेंसिबल बिल्ड कॉन्फ़िगरेशन की सुविधा मिलती है).
• ओईएम एआईडी की वैल्यू की बिल्ड-टाइम सैनिटी चेकिंग.
• ओईएम एआईडी का कस्टम हेडर जनरेट करना. इसका इस्तेमाल, सोर्स फ़ाइलों में ज़रूरत के हिसाब से किया जा सकता है.
• ओईएम एआईडी की असली वैल्यू के साथ, आसानी से याद रखे जा सकने वाला नाम जोड़ना. उपयोगकर्ता और ग्रुप के लिए, नॉन-न्यूमेरिक स्ट्रिंग आर्ग्युमेंट इस्तेमाल करने की सुविधा. जैसे, "2901" के बजाय "foo".

अन्य सुधारों में, android_ids[] कलेक्शन को system/core/libcutils/include/private/android_filesystem_config.h से हटाना शामिल है. यह कलेक्शन अब Bionic में, पूरी तरह से निजी तौर पर जनरेट किए गए कलेक्शन के तौर पर मौजूद है. इसमें getpwnam() और getgrnam() के साथ ऐक्सेसर मौजूद हैं. (इसका साइड इफ़ेक्ट यह है कि स्टेबल बाइनरी जनरेट होती हैं, क्योंकि कोर एआईडी में बदलाव किया जाता है.) टूलिंग और ज़्यादा जानकारी वाली README फ़ाइल के लिए, build/make/tools/fs_config देखें.

ध्यान दें: Android के पिछले वर्शन में, फ़ाइल सिस्टम को बदलने के तरीके का इस्तेमाल अब भी किया जा सकता है. हालांकि, इसका इस्तेमाल एआईडी के नए मैकेनिज़्म के साथ एक साथ नहीं किया जा सकता. हमारा सुझाव है कि जब भी हो सके, नए मैकेनिज़्म का इस्तेमाल करें.

Android आईडी (एआईडी) जोड़ना

Android 8.0 में, Android Open Source Project (AOSP) से android_ids[] कलेक्शन हटा दिया गया है. इसके बजाय, एआईडी के आसानी से याद रखे जा सकने वाले सभी नाम, Bionic android_ids[] कलेक्शन जनरेट करते समय, the system/core/libcutils/include/private/android_filesystem_config.h हेडर फ़ाइल से जनरेट किए जाते हैं. define से मैच करने वाले किसी भी AID_* को टूलिंग चुन लेती है और *, छोटे अक्षरों में नाम बन जाता है.

उदाहरण के लिए, private/android_filesystem_config.h में:

#define AID_SYSTEM 1000

यह बन जाता है:

• आसानी से याद रखा जा सकने वाला नाम: system
• uid: 1000
• gid: 1000

AOSP कोर एआईडी जोड़ने के लिए, बस #define को android_filesystem_config.h हेडर फ़ाइल में जोड़ें. एआईडी, बिल्ड के दौरान जनरेट होता है और उन इंटरफ़ेस के लिए उपलब्ध होता है जो उपयोगकर्ता और ग्रुप आर्ग्युमेंट का इस्तेमाल करते हैं. टूलिंग, नए एआईडी की पुष्टि करती है कि यह ऐप्लिकेशन या ओईएम की रेंज में नहीं है. यह इन रेंज में किए गए बदलावों का भी ध्यान रखती है और ओईएम के लिए रिज़र्व की गई नई रेंज या उनमें किए गए बदलावों के हिसाब से, अपने-आप फिर से कॉन्फ़िगर हो जानी चाहिए.

एआईडी कॉन्फ़िगर करना

एआईडी के नए मैकेनिज़्म को चालू करने के लिए, TARGET_FS_CONFIG_GEN को BoardConfig.mk फ़ाइल में सेट करें. इस वैरिएबल में, कॉन्फ़िगरेशन फ़ाइलों की सूची होती है. इससे, ज़रूरत के हिसाब से फ़ाइलें जोड़ी जा सकती हैं.

चेतावनी: Android के पुराने वर्शन में, TARGET_ANDROID_FILESYSTEM_CONFIG_H के पुराने तरीके के साथ, TARGET_FS_CONFIG_GEN का इस्तेमाल न करें! ऐसा करने पर, आपको गड़बड़ी का मैसेज मिलेगा.

कॉन्फ़िगरेशन फ़ाइलों के लिए, आम तौर पर config.fs नाम का इस्तेमाल किया जाता है. हालांकि, असल में कोई भी नाम इस्तेमाल किया जा सकता है. config.fs फ़ाइलें, Python ConfigParser ini फ़ॉर्मैट में होती हैं. इनमें, कैप सेक्शन (फ़ाइल सिस्टम की क्षमताओं को कॉन्फ़िगर करने के लिए) और एआईडी सेक्शन (ओईएम एआईडी को कॉन्फ़िगर करने के लिए) शामिल होता है.

कैप सेक्शन कॉन्फ़िगर करना

ध्यान दें: एंबियंट क्षमताओं का इस्तेमाल, init से लॉन्च की गई सेवाओं के लिए क्षमताओं को सेट करने के लिए किया जाता है. इस तरीके से, सेवा के कॉन्फ़िगरेशन के सभी पहलुओं को एक ही .rc फ़ाइल में रखा जाता है. हमारा सुझाव है कि इन सेवाओं के लिए, एंबियंट क्षमताओं का इस्तेमाल करें. इसके बजाय, फ़ाइल सिस्टम की क्षमताओं को कॉन्फ़िगर करने के लिए, कैप सेक्शन का इस्तेमाल न करें config.fs फ़ाइलों में. सेवाओं के लिए क्षमताओं को सेट करते समय, init से लॉन्च नहीं की गई, फ़ाइल सिस्टम की क्षमताओं को कॉन्फ़िगर करने के लिए fs_config.c का इस्तेमाल करें.

कैप सेक्शन में, बिल्ड में मौजूद फ़ाइल सिस्टम ऑब्जेक्ट पर, फ़ाइल सिस्टम की क्षमताओं को सेट करने की सुविधा मिलती है. फ़ाइल सिस्टम में भी यह सुविधा होनी चाहिए.

Android में, रूट के तौर पर स्टेबल सेवा चलाने से, Compatibility Test Suite (CTS) में गड़बड़ी होती है. इसलिए, किसी प्रोसेस या सेवा को चलाते समय, क्षमता बनाए रखने के लिए, पहले क्षमताओं को सेट अप करना होता था. इसके बाद, चलाने के लिए, सही एआईडी पर setuid/setgid का इस्तेमाल करना होता था. कैप की मदद से, इन शर्तों को पूरा करने की ज़रूरत नहीं होती. यह काम कर्नल करता है. main() को कंट्रोल मिलने पर, आपकी प्रोसेस में पहले से ही वे क्षमताएं होती हैं जिनकी उसे ज़रूरत होती है. इसलिए, आपकी सेवा, नॉन-रूट उपयोगकर्ता और ग्रुप का इस्तेमाल कर सकती है. खास अधिकारों वाली सेवाओं को शुरू करने का यह सबसे अच्छा तरीका है.

कैप सेक्शन में, इस सिंटैक्स का इस्तेमाल किया जाता है:

सेक्शन	मान	परिभाषा
[path]		कॉन्फ़िगर करने के लिए, फ़ाइल सिस्टम का पाथ. अगर पाथ, / से खत्म होता है, तो उसे डायरेक्ट्री माना जाता है. नहीं तो, वह फ़ाइल होती है. अलग-अलग फ़ाइलों में, एक ही [path] के साथ एक से ज़्यादा सेक्शन तय करना, गड़बड़ी है. Python के 3.2 या इससे पहले के वर्शन में, एक ही फ़ाइल में ऐसे सेक्शन हो सकते हैं जो पिछले सेक्शन को बदल देते हैं. Python 3.2 में, इसे स्ट्रिक्ट मोड पर सेट किया गया है.
mode	ऑक्टल फ़ाइल मोड	कम से कम तीन अंकों का मान्य ऑक्टल फ़ाइल मोड. अगर तीन तय किया जाता है, तो इसके पहले 0 जोड़ा जाता है. नहीं तो, मोड का इस्तेमाल वैसे ही किया जाता है.
user	AID_<user>	मान्य एआईडी के लिए, C define या आसानी से याद रखा जा सकने वाला नाम . उदाहरण के लिए, AID_RADIO और radio, दोनों मान्य हैं. कस्टम एआईडी तय करने के लिए, एआईडी सेक्शन कॉन्फ़िगर करना देखें.
group	AID_<group>	उपयोगकर्ता की तरह.
caps	cap*	में तय किया गया नाम. इसमें, शुरुआत में CAP_ शामिल नहीं होता.bionic/libc/kernel/uapi/linux/capability.h छोटे-बड़े अक्षरों का इस्तेमाल किया जा सकता है. कैप, रॉ भी हो सकते हैं: बाइनरी (0b0101) ऑक्टल (0455) int (42) हेक्स (0xFF) एक से ज़्यादा कैप को अलग करने के लिए, खाली जगह का इस्तेमाल करें.

इस्तेमाल करने का उदाहरण देखने के लिए, फ़ाइल सिस्टम की क्षमताओं का इस्तेमाल करना देखें.

एआईडी सेक्शन कॉन्फ़िगर करना

एआईडी सेक्शन में, ओईएम एआईडी शामिल होते हैं. इसमें इस सिंटैक्स का इस्तेमाल किया जाता है:

सेक्शन	मान	परिभाषा
[AID_<name>]		<name> में, बड़े अक्षर, संख्याएं, और अंडरस्कोर शामिल हो सकते हैं. छोटे अक्षरों वाला वर्शन, आसानी से याद रखा जा सकने वाला नाम होता है. कोड शामिल करने के लिए जनरेट की गई हेडर फ़ाइल में, ठीक AID_<name> का इस्तेमाल किया जाता है. एक ही AID_<name> के साथ एक से ज़्यादा सेक्शन तय करना, गड़बड़ी है. इसमें केस सेंसिटिविटी का ध्यान नहीं रखा जाता और इसमें [path] जैसी ही पाबंदियां लागू होती हैं. <name> की शुरुआत में, पार्टिशन का नाम होना चाहिए, ताकि यह पक्का किया जा सके कि यह अलग-अलग सोर्स के साथ काम करे.
value	<number>	C स्टाइल का मान्य नंबर स्ट्रिंग (हेक्स, ऑक्टल, बाइनरी, और डेसिमल). एक ही वैल्यू विकल्प के साथ एक से ज़्यादा सेक्शन तय करना, गड़बड़ी है. वैल्यू के विकल्प, पार्टिशन के हिसाब से तय की गई रेंज में होने चाहिए जिसका इस्तेमाल <name> में किया गया है. मान्य पार्टिशन और उनकी रेंज की सूची, system/core/libcutils/include/private/android_filesystem_config.h में तय की गई है. ये विकल्प हैं: वेंडर पार्टिशन AID_OEM_RESERVED_START(2900) - AID_OEM_RESERVED_END(2999) AID_OEM_RESERVED_2_START(5000) - AID_OEM_RESERVED_2_END(5999) सिस्टम पार्टिशन AID_SYSTEM_RESERVED_START(6000) - AID_SYSTEM_RESERVED_END(6499) ओडीएम पार्टिशन AID_ODM_RESERVED_START(6500) - AID_ODM_RESERVED_END(6999) प्रॉडक्ट का बंटवारा AID_PRODUCT_RESERVED_START(7000) - AID_PRODUCT_RESERVED_END(7499) System_ext पार्टिशन AID_SYSTEM_EXT_RESERVED_START(7500) - AID_SYSTEM_EXT_RESERVED_END(7999)

इस्तेमाल करने के उदाहरण देखने के लिए, ओईएम एआईडी के नाम तय करना और ओईएम एआईडी का इस्तेमाल करना देखें.

इस्तेमाल करने के उदाहरण

यहां दिए गए उदाहरणों में, ओईएम एआईडी तय करने और उसका इस्तेमाल करने का तरीका बताया गया है. साथ ही, फ़ाइल सिस्टम की क्षमताओं को चालू करने का तरीका भी बताया गया है. ओईएम एआईडी के नाम ([AID_name]) की शुरुआत में, "vendor_" जैसे किसी पार्टिशन का नाम होना चाहिए, ताकि यह पक्का किया जा सके कि वे AOSP के आने वाले नामों या अन्य पार्टिशन के साथ काम करें.

ओईएम एआईडी के नाम तय करना

ओईएम एआईडी तय करने के लिए, config.fs फ़ाइल बनाएं और एआईडी की वैल्यू सेट करें. उदाहरण के लिए, 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

अब नए बिल्ड पर, सिस्टम आपके कस्टम एआईडी का इस्तेमाल कर सकता है.

ओईएम एआईडी का इस्तेमाल करना

ओईएम एआईडी का इस्तेमाल करने के लिए, अपने 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 में, एआईडी के नामों के साथ काम करने वाले किसी भी इंटरफ़ेस के लिए, आसानी से याद रखे जा सकने वाले नाम का इस्तेमाल किया जा सकता है. उदाहरण के लिए:

• 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 में, ओईएम एआईडी की असली वैल्यू के साथ, आसानी से याद रखे जा सकने वाला नाम जोड़ने की सुविधा है. उपयोगकर्ता और ग्रुप के लिए, नॉन-न्यूमेरिक स्ट्रिंग आर्ग्युमेंट इस्तेमाल किए जा सकते हैं. जैसे, "2901" के बजाय "vendor_foo".

एआईडी से आसानी से याद रखे जा सकने वाले नाम में बदलना

ओईएम एआईडी के लिए, Android 8.x में oem_#### और getpwnam जैसे फ़ंक्शन के साथ oem_#### का इस्तेमाल करना ज़रूरी था. साथ ही, उन जगहों पर भी इसका इस्तेमाल करना ज़रूरी था जहां getpwnam (जैसे, init स्क्रिप्ट) की मदद से लुकअप हैंडल किए जाते हैं. Android 9 में, Bionic में getpwnam और getgrnam फ़ंक्शन का इस्तेमाल करके, Android आईडी (एआईडी) को आसानी से याद रखे जा सकने वाले नामों में बदला जा सकता है. साथ ही, आसानी से याद रखे जा सकने वाले नामों को एआईडी में भी बदला जा सकता है.

फ़ाइल सिस्टम की क्षमताओं का इस्तेमाल करना

फ़ाइल सिस्टम की क्षमताओं को चालू करने के लिए, 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

नोट: यहां, vendor_foo और system जैसे आसानी से याद रखे जा सकने वाले नाम भी इस्तेमाल किए जा सकते हैं.

फ़ाइल बनाने के बाद, TARGET_FS_CONFIG_GEN को उस फ़ाइल पर पॉइंट करें BoardConfig.mk में. उदाहरण के लिए, 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 में इंस्टॉल किया जा सके. बिल्ड सिस्टम कस्टम android_filesystem_config.h को $(TARGET_DEVICE_DIR) में खोजता है, जहां BoardConfig.mk मौजूद है. अगर यह फ़ाइल कहीं और मौजूद है, तो बोर्ड के कॉन्फ़िगरेशन से जुड़े वैरिएबल TARGET_ANDROID_FILESYSTEM_CONFIG_H को उस जगह पर सेट करें.

फ़ाइल सिस्टम कॉन्फ़िगर करना

Android 6.0 और इसके बाद के वर्शन में, फ़ाइल सिस्टम को कॉन्फ़िगर करने के लिए:

1. $(TARGET_DEVICE_DIR)/android_filesystem_config.h फ़ाइल बनाएं.
2. बोर्ड के कॉन्फ़िगरेशन फ़ाइल (उदाहरण के लिए, $(TARGET_DEVICE_DIR)/device.mk) में, PRODUCT_PACKAGES में fs_config_dirs और/या fs_config_files जोड़ें.

बदलाव का उदाहरण

इस उदाहरण में, system/bin/glgps डेमॉन को बदलने के लिए पैच दिखाया गया है, ताकि device/vendor/device डायरेक्ट्री में वेक लॉक की सुविधा जोड़ी जा सके. इन बातों का ध्यान रखें:

• हर स्ट्रक्चर एंट्री, मोड, uid, gid, क्षमताओं, और नाम होती है. system/core/include/private/android_filesystem_config.h मेनिफ़ेस्ट #defines (AID_ROOT, AID_SHELL, CAP_BLOCK_SUSPEND) देने के लिए, अपने-आप शामिल हो जाती है.
• android_device_files[] सेक्शन में, 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 का रेफ़रंस ज़रूरी है. डिवाइस बनाने वाली कंपनी के निजी तौर पर एक्ज़ीक्यूट किए जा सकने वाले ऐसे प्रोग्राम जिन्हें फ़ाइल या डायरेक्ट्री स्ट्रक्चर या fs_config के लिए, system/code/include/private_filesystem_config.h की ज़रूरत होती है उन्हें libcutils लाइब्रेरी की डिपेंडेंसी जोड़नी होंगी.
• मौजूदा टारगेट पर अतिरिक्त कॉन्टेंट के साथ, डिवाइस बनाने वाली कंपनी की निजी तौर पर ब्रांच की कॉपी, system/core/include/private/android_filesystem_config.h को device/vendor/device/android_filesystem_config.h में ले जाना होगा.
• टारगेट सिस्टम पर, कॉन्फ़िगरेशन फ़ाइलों पर SELinux Mandatory Access Controls (MAC) लागू करने का अधिकार सुरक्षित रखता है. टारगेट के कस्टम तौर पर एक्ज़ीक्यूट किए जा सकने वाले प्रोग्राम को शामिल करने वाले लागू करने के तरीके में, fs_config() का इस्तेमाल करके, ऐक्सेस पक्का करना ज़रूरी है.