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

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

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[] कलेक्शन को हटा दिया है. इसके बजाय, AID के हिसाब से सभी नाम, system/core/libcutils/include/private/android_filesystem_config.h हेडर फ़ाइल से जनरेट किए जाते हैं. ऐसा तब होता है, जब Bionic android_ids[] कलेक्शन जनरेट किया जाता है. टूल, AID_* से मैच करने वाला कोई भी define चुन लेता है और * लोअरकेस नाम बन जाता है.

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

#define AID_SYSTEM 1000

यह हो जाता है:

  • कोई अन्य नाम: system
  • uid: 1000
  • gid: 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_<user> मान्य AID के लिए C define या आसान नाम (उदाहरण के लिए, AID_RADIO और radio, दोनों स्वीकार किए जाते हैं). कस्टम एआईडी तय करने के लिए, एआईडी सेक्शन को कॉन्फ़िगर करना लेख पढ़ें.
group AID_<group> उपयोगकर्ता के नाम जैसा ही.
caps cap* bionic/libc/kernel/uapi/linux/capability.h में बताए गए नाम में, CAP_ को हटा दें. छोटे-बड़े अक्षरों का इस्तेमाल किया जा सकता है. कैप को इनमें से किसी भी तौर पर इस्तेमाल किया जा सकता है:
  • बाइनरी (0b0101)
  • ऑक्टल (0455)
  • int (42)
  • हेक्स (0xFF)
एक से ज़्यादा कैप को अलग करने के लिए, स्पेस का इस्तेमाल करें.

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

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 में दी गई है. इसके विकल्प हैं:
  • वेंडर का पार्टीशन
    • 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)
  • ODM पार्टीशन
    • AID_ODM_RESERVED_START(6500) - AID_ODM_RESERVED_END(6999)
  • प्रॉडक्ट का बंटवारा
    • AID_PRODUCT_RESERVED_START(7000) - AID_PRODUCT_RESERVED_END(7499)
  • System_ext Partition
    • AID_SYSTEM_EXT_RESERVED_START(7500) - AID_SYSTEM_EXT_RESERVED_END(7999)

इस्तेमाल के उदाहरणों के लिए, 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 का इस्तेमाल करने के लिए, अपने 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

/vendor/etc/passwd और /vendor/etc/group, उपयोगकर्ता के नाम से यूआईडी में बदलाव करते हैं. इसलिए, वेंडर के partition को माउंट करना ज़रूरी है.

आसान नाम जोड़ना

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

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

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

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

  1. $(TARGET_DEVICE_DIR)/android_filesystem_config.h फ़ाइल बनाएं.
  2. बोर्ड कॉन्फ़िगरेशन फ़ाइल में, 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() का इस्तेमाल करके, कस्टम टारगेट एक्सीक्यूटेबल को लागू करने के लिए, ऐक्सेस की पुष्टि करना ज़रूरी है.