विवेकाधीन अभिगम नियंत्रण (डीएसी)

बिल्ड में जोड़े गए फ़ाइल सिस्टम ऑब्जेक्ट और सेवाओं को अक्सर अलग, अद्वितीय आईडी की आवश्यकता होती है, जिन्हें एंड्रॉइड आईडी (एआईडी) के रूप में जाना जाता है। वर्तमान में, कई संसाधन जैसे फ़ाइलें और सेवाएँ अनावश्यक रूप से कोर (एंड्रॉइड-परिभाषित) एआईडी का उपयोग करते हैं; कई मामलों में आप इसके बजाय OEM (OEM-परिभाषित) AID का उपयोग कर सकते हैं।

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

एंड्रॉइड के नए संस्करण (एंड्रॉइड 8.0 और उच्चतर) फ़ाइल सिस्टम क्षमताओं को बढ़ाने के लिए एक नई विधि का समर्थन करते हैं। इस नई पद्धति में निम्नलिखित के लिए समर्थन है:

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

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

एंड्रॉइड आईडी (एआईडी) जोड़ना

एंड्रॉइड 8.0 ने एंड्रॉइड ओपन सोर्स प्रोजेक्ट (एओएसपी) से android_ids[] ऐरे को हटा दिया। बायोनिक android_ids[] सरणी उत्पन्न करते समय सभी AID-अनुकूल नाम system/core/libcutils/include/private/android_filesystem_config.h हेडर फ़ाइल से उत्पन्न होते हैं। किसी भी define मिलान AID_* टूलिंग द्वारा उठाया जाता है और * लोअरकेस नाम बन जाता है।

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

#define AID_SYSTEM 1000

बन जाता है:

  • अनुकूल नाम: तंत्र
  • यूआईडी: 1000
  • gid: 1000

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

एड्स को कॉन्फ़िगर करना

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

परंपरा के अनुसार, कॉन्फ़िगरेशन फ़ाइलें config.fs नाम का उपयोग करती हैं, लेकिन व्यवहार में आप किसी भी नाम का उपयोग कर सकते हैं। config.fs फ़ाइलें Python ConfigParser ini प्रारूप में हैं और इसमें एक कैप्स अनुभाग (फ़ाइल सिस्टम क्षमताओं को कॉन्फ़िगर करने के लिए) और एक AIDs अनुभाग (OEM AIDs कॉन्फ़िगर करने के लिए) शामिल हैं।

कैप्स अनुभाग को कॉन्फ़िगर करना

कैप्स अनुभाग बिल्ड के भीतर फ़ाइल सिस्टम ऑब्जेक्ट पर फ़ाइल सिस्टम क्षमताओं को सेट करने का समर्थन करता है (फ़ाइल सिस्टम को भी इस कार्यक्षमता का समर्थन करना चाहिए)।

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

कैप्स अनुभाग निम्नलिखित सिंटैक्स का उपयोग करता है:

अनुभाग कीमत परिभाषा
[path] कॉन्फ़िगर करने के लिए फ़ाइल सिस्टम पथ. / से समाप्त होने वाले पथ को dir माना जाता है, अन्यथा यह एक फ़ाइल है।

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

उपयोग के उदाहरण के लिए, फ़ाइल सिस्टम क्षमताओं का उपयोग करना देखें।

सहायता अनुभाग को कॉन्फ़िगर करना

AID अनुभाग में OEM AID शामिल हैं और निम्नलिखित सिंटैक्स का उपयोग करता है:

अनुभाग कीमत परिभाषा
[AID_<name>] <name> में सेट अपरकेस, संख्याएं और अंडरस्कोर में वर्ण शामिल हो सकते हैं। लोअरकेस संस्करण का उपयोग मित्रतापूर्ण नाम के रूप में किया जाता है। कोड समावेशन के लिए जेनरेट की गई हेडर फ़ाइल सटीक AID_<name> का उपयोग करती है।

समान AID_<name> ( [path] जैसी ही बाधाओं के साथ केस असंवेदनशील) के साथ एकाधिक अनुभाग निर्दिष्ट करना एक त्रुटि है।

यह सुनिश्चित करने के लिए कि यह विभिन्न स्रोतों के साथ विरोध नहीं करता है, <name> एक विभाजन नाम से शुरू होना चाहिए।
value <संख्या> एक वैध सी शैली संख्या स्ट्रिंग (हेक्स, ऑक्टल, बाइनरी और दशमलव)।

समान मान विकल्प के साथ एकाधिक अनुभाग निर्दिष्ट करना एक त्रुटि है।

मान विकल्प <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)

उपयोग के उदाहरणों के लिए, OEM AID नामों को परिभाषित करना और OEM AID का उपयोग करना देखें।

उपयोग के उदाहरण

निम्नलिखित उदाहरण विस्तार से बताते हैं कि OEM AID को कैसे परिभाषित और उपयोग किया जाए और फ़ाइल सिस्टम क्षमताओं को कैसे सक्षम किया जाए। OEM AID नाम ( [AID_ नाम ] ) को विभाजन नाम जैसे " vender_ " से शुरू होना चाहिए ताकि यह सुनिश्चित किया जा सके कि वे भविष्य के AOSP नामों या अन्य विभाजनों के साथ विरोध न करें।

OEM सहायता नामों को परिभाषित करना

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 सहायता का उपयोग करना

OEM AID का उपयोग करने के लिए, अपने C कोड में, अपने संबंधित मेकफ़ाइल में 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

मैत्रीपूर्ण नामों का उपयोग करना

एंड्रॉइड 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
    

क्योंकि अनुकूल नाम से यूआईडी तक आंतरिक मैपिंग /vendor/etc/passwd और /vendor/etc/group द्वारा की जाती है, विक्रेता विभाजन को माउंट किया जाना चाहिए।

मैत्रीपूर्ण नाम जोड़ना

एंड्रॉइड 9 में वास्तविक ओईएम एआईडी मूल्य के साथ एक अनुकूल नाम जोड़ने के लिए समर्थन शामिल है। आप उपयोगकर्ता और समूह के लिए गैर-संख्यात्मक स्ट्रिंग तर्कों का उपयोग कर सकते हैं, अर्थात "2901" के बजाय " vender_foo "।

सहायता से मैत्रीपूर्ण नामों में परिवर्तित करना

ओईएम एआईडी के लिए, एंड्रॉइड 8.x को getpwnam और इसी तरह के कार्यों के साथ oem_#### के उपयोग की आवश्यकता होती है, साथ ही उन स्थानों पर भी जो getpwnam (जैसे init स्क्रिप्ट) के माध्यम से लुकअप को संभालते हैं। एंड्रॉइड 9 में, आप एंड्रॉइड आईडी (एआईडी) को फ्रेंडली नामों में बदलने और इसके विपरीत के लिए बायोनिक में 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)

एंड्रॉइड 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 . निर्देशिकाओं और फ़ाइलों के लिए अलग-अलग मिलान और पार्सिंग नियमों का उपयोग करना (जो अतिरिक्त ग्लोब अभिव्यक्तियों का उपयोग कर सकता है) ने एंड्रॉइड को दो अलग-अलग तालिकाओं में निर्देशिकाओं और फ़ाइलों को संभालने में सक्षम बनाया। system/core/libcutils/fs_config.c में संरचना परिभाषाएँ न केवल निर्देशिकाओं और फ़ाइलों के रनटाइम पढ़ने की अनुमति देती हैं, बल्कि होस्ट ${OUT}/system/etc/fs_config_dirs और ${OUT}/system/etc/fs_config_files के रूप में फ़ाइल सिस्टम छवियों के निर्माण के लिए निर्माण समय के दौरान समान फ़ाइलों का उपयोग कर सकता है। ${OUT}/system/etc/fs_config_files

जबकि फ़ाइल सिस्टम को विस्तारित करने की ओवरराइड विधि को एंड्रॉइड 8.0 में पेश किए गए मॉड्यूलर कॉन्फिग सिस्टम द्वारा प्रतिस्थापित कर दिया गया है, फिर भी आप चाहें तो पुरानी विधि का उपयोग कर सकते हैं। निम्नलिखित अनुभाग विस्तार से बताते हैं कि ओवरराइड फ़ाइलों को कैसे उत्पन्न करें और शामिल करें और फ़ाइल सिस्टम को कॉन्फ़िगर करें।

ओवरराइड फ़ाइलें उत्पन्न करना

आप build/tools/fs_config में fs_config_generate टूल का उपयोग करके संरेखित बाइनरी फ़ाइलें /system/etc/fs_config_dirs और /system/etc/fs_config_files उत्पन्न कर सकते हैं। उपकरण DAC आवश्यकताओं को एक बफर में प्रबंधित करने के लिए libcutils लाइब्रेरी फ़ंक्शन ( fs_config_generate() ) का उपयोग करता है और DAC नियमों को संस्थागत बनाने के लिए एक सम्मिलित फ़ाइल के लिए नियमों को परिभाषित करता है।

उपयोग करने के लिए, 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 को परिभाषित कर सकते हैं (नीचे उदाहरण देखें)। आप android_filesystem_config.h के लागू बेसनाम के साथ, बोर्ड कॉन्फ़िगरेशन में TARGET_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 सेट करें।

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

एंड्रॉइड 6.0 और उच्चतर में फ़ाइल सिस्टम को कॉन्फ़िगर करने के लिए:

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

ओवरराइड उदाहरण

यह उदाहरण device/ vendor / device निर्देशिका में वेक लॉक समर्थन जोड़ने के लिए system/bin/glgps डेमॉन को ओवरराइड करने के लिए एक पैच दिखाता है। निम्नलिखित को ध्यान में रखें:

  • प्रत्येक संरचना प्रविष्टि मोड, यूआईडी, जीआईडी, क्षमताएं और नाम है। system/core/include/private/android_filesystem_config.h मेनिफेस्ट #defines ( AID_ROOT , AID_SHELL , CAP_BLOCK_SUSPEND ) प्रदान करने के लिए स्वचालित रूप से शामिल किया गया है।
  • android_device_files[] अनुभाग में अनिर्दिष्ट होने पर system/etc/fs_config_dirs तक पहुंच को दबाने की कार्रवाई शामिल है, जो निर्देशिका ओवरराइड के लिए सामग्री की कमी के लिए अतिरिक्त DAC सुरक्षा के रूप में कार्य करती है। हालाँकि, यह कमजोर सुरक्षा है; यदि किसी के पास /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 filesystem
+** 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 लाइब्रेरी निर्भरताएँ जोड़नी होंगी।
  • डिवाइस/विक्रेता device/ vendor / device /android_filesystem_config.h पर जाने के लिए मौजूदा लक्ष्यों पर अतिरिक्त सामग्री के साथ system/core/include/private/android_filesystem_config.h की डिवाइस निर्माता निजी शाखा प्रतियों की आवश्यकता है।
  • लक्ष्य प्रणाली पर कॉन्फ़िगरेशन फ़ाइलों पर SELinux अनिवार्य एक्सेस कंट्रोल (MAC) लागू करने का अधिकार सुरक्षित रखता है, कार्यान्वयन जिसमें fs_config() का उपयोग करके कस्टम लक्ष्य निष्पादन योग्य शामिल हैं, उन्हें पहुंच सुनिश्चित करनी चाहिए।