कॉन्फिगस्टोर एचएएल

एंड्रॉइड 10 में, कॉन्फिगस्टोर एचएएल vendor विभाजन में कॉन्फ़िगरेशन मानों को संग्रहीत करने के लिए बिल्ड फ़्लैग का उपयोग करता है, और system विभाजन में एक सेवा एचआईडीएल का उपयोग करके उन मानों तक पहुंचती है (यह एंड्रॉइड 9 में भी सच है)। हालाँकि, उच्च मेमोरी खपत और कठिन उपयोग के कारण, कॉन्फिगस्टोर एचएएल को हटा दिया गया है।

कॉन्फ़िगस्टोर HAL लीगेसी विक्रेता विभाजन का समर्थन करने के लिए AOSP में बना हुआ है। एंड्रॉइड 10 या उसके बाद के संस्करण चलाने वाले उपकरणों पर, surfaceflinger पहले सिस्टम गुणों को पढ़ता है; यदि `SurfaceFlingerProperties.sysprop` में कॉन्फिग आइटम के लिए कोई सिस्टम प्रॉपर्टी परिभाषित नहीं की गई है, तो `surfaceflinger` कॉन्फिगस्टोर HAL पर वापस आ जाता है।

एंड्रॉइड 8.0 अखंड एंड्रॉइड ओएस को सामान्य ( system.img ) और हार्डवेयर-विशिष्ट ( vendor.img और odm.img ) विभाजन में विभाजित करता है। इस परिवर्तन के परिणामस्वरूप, सिस्टम विभाजन में स्थापित मॉड्यूल से सशर्त संकलन को हटा दिया जाना चाहिए और ऐसे मॉड्यूल को रनटाइम पर सिस्टम की कॉन्फ़िगरेशन निर्धारित करनी होगी (और उस कॉन्फ़िगरेशन के आधार पर अलग-अलग व्यवहार करना होगा)।

कॉन्फिगस्टोर एचएएल एंड्रॉइड फ्रेमवर्क को कॉन्फ़िगर करने के लिए उपयोग किए जाने वाले रीड-ओनली कॉन्फ़िगरेशन आइटम तक पहुंचने के लिए एपीआई का एक सेट प्रदान करता है। यह पृष्ठ कॉन्फ़िगस्टोर एचएएल के डिज़ाइन का वर्णन करता है (और इस उद्देश्य के लिए सिस्टम गुणों का उपयोग क्यों नहीं किया गया); इस अनुभाग के अन्य पृष्ठ एचएएल इंटरफ़ेस , सेवा कार्यान्वयन और क्लाइंट-साइड उपयोग का विवरण देते हैं, सभी एक उदाहरण के रूप में surfaceflinger उपयोग करते हैं। कॉन्फ़िगस्टोर इंटरफ़ेस क्लासों की सहायता के लिए, इंटरफ़ेस क्लासेस और आइटम जोड़ना देखें।

सिस्टम गुणों का उपयोग क्यों न करें?

हमने सिस्टम गुणों का उपयोग करने पर विचार किया लेकिन कई मूलभूत मुद्दे पाए गए, जिनमें शामिल हैं:

  • मानों पर लंबाई सीमा. सिस्टम गुणों की उनके मानों की लंबाई (92 बाइट्स) पर सख्त सीमाएँ होती हैं। इसके अलावा, चूंकि इन सीमाओं को सी मैक्रोज़ के रूप में एंड्रॉइड ऐप्स पर सीधे उजागर किया गया है, लंबाई बढ़ाने से बैकवर्ड-संगतता समस्याएं हो सकती हैं।
  • किसी प्रकार का समर्थन नहीं. सभी मान अनिवार्य रूप से स्ट्रिंग हैं, और एपीआई बस स्ट्रिंग को int या bool में पार्स करते हैं। अन्य मिश्रित डेटा प्रकार (उदाहरण के लिए, सरणी और संरचना) को क्लाइंट द्वारा एन्कोड/डीकोड किया जाना चाहिए (उदाहरण के लिए, "aaa,bbb,ccc" तीन स्ट्रिंग्स की सरणी के रूप में कोड किया जा सकता है)।
  • अधिलेखित करता है. क्योंकि रीड-ओनली सिस्टम गुणों को राइट-वन्स प्रॉपर्टीज के रूप में कार्यान्वित किया जाता है, विक्रेता/ओडीएम जो एओएसपी-परिभाषित रीड-ओनली मानों को ओवरराइड करना चाहते हैं, उन्हें एओएसपी-परिभाषित रीड-ओनली मानों से पहले अपने स्वयं के रीड-ओनली मानों को आयात करना होगा। इसके परिणामस्वरूप, विक्रेता-परिभाषित पुनर्लेखन योग्य मान AOSP-परिभाषित मानों द्वारा ओवरराइड हो जाते हैं।
  • स्थान संबंधी आवश्यकताओं को संबोधित करें. सिस्टम गुण प्रत्येक प्रक्रिया में अपेक्षाकृत बड़ी मात्रा में पता स्थान लेते हैं। सिस्टम गुणों को 128 केबी के निश्चित आकार के साथ prop_area इकाइयों में समूहीकृत किया जाता है, जिनमें से सभी को एक प्रक्रिया पता स्थान पर आवंटित किया जाता है, भले ही इसमें केवल एक सिस्टम प्रॉपर्टी तक पहुंच हो। यह 32-बिट डिवाइस पर समस्याएँ पैदा कर सकता है जहाँ पता स्थान कीमती है।

हमने अनुकूलता से समझौता किए बिना इन सीमाओं को पार करने का प्रयास किया, लेकिन यह चिंता बनी रही कि सिस्टम गुण केवल-पढ़ने के लिए कॉन्फ़िगरेशन आइटम तक पहुंच का समर्थन करने के लिए डिज़ाइन नहीं किए गए थे। अंततः हमने निर्णय लिया कि सिस्टम गुण वास्तविक समय में संपूर्ण एंड्रॉइड पर कुछ गतिशील रूप से अपडेट किए गए आइटम साझा करने के लिए बेहतर अनुकूल हैं, और केवल-पढ़ने के लिए कॉन्फ़िगरेशन आइटम तक पहुंचने के लिए समर्पित एक नई प्रणाली की आवश्यकता मौजूद है।

कॉन्फिगस्टोर एचएएल डिज़ाइन

मूल डिज़ाइन सरल है:

कॉन्फिगस्टोर एचएएल डिज़ाइन

चित्र 1. कॉन्फ़िगस्टोर एचएएल डिज़ाइन

  • HIDL में बिल्ड फ़्लैग (वर्तमान में फ़्रेमवर्क को सशर्त रूप से संकलित करने के लिए उपयोग किया जाता है) का वर्णन करें।
  • विक्रेता और OEM एचएएल सेवा को लागू करके बिल्ड फ़्लैग के लिए SoC और डिवाइस-विशिष्ट मान प्रदान करते हैं।
  • रनटाइम पर कॉन्फ़िगरेशन आइटम का मान खोजने के लिए एचएएल सेवा का उपयोग करने के लिए ढांचे को संशोधित करें।

फ़्रेमवर्क द्वारा वर्तमान में संदर्भित कॉन्फ़िगरेशन आइटम एक संस्करण वाले HIDL पैकेज ( android.hardware.configstore@1.0 ) में शामिल हैं। विक्रेता/ओईएम इस पैकेज में इंटरफेस लागू करके कॉन्फ़िगरेशन आइटम के लिए मूल्य प्रदान करते हैं, और फ्रेमवर्क इंटरफेस का उपयोग तब करता है जब उसे कॉन्फ़िगरेशन आइटम के लिए मूल्य प्राप्त करने की आवश्यकता होती है।

सुरक्षा संबंधी विचार

समान इंटरफ़ेस में परिभाषित बिल्ड फ़्लैग समान SELinux नीति से प्रभावित होते हैं। यदि एक या अधिक बिल्ड फ़्लैग में भिन्न SELinux नीतियाँ होनी चाहिए, तो उन्हें दूसरे इंटरफ़ेस से अलग किया जाना चाहिए । इसके लिए android.hardware.configstore package में बड़े संशोधन की आवश्यकता हो सकती है क्योंकि अलग किए गए इंटरफ़ेस अब पिछड़े-संगत नहीं हैं।