इस पेज में Android 8 के बाइंडर ड्राइवर में हुए बदलावों के बारे में बताया गया है. बाइंडर आईपीसी इस्तेमाल करने के बारे में जानकारी, और SELinux नीति की ज़रूरी जानकारी देता है.
बाइंडर ड्राइवर में बदलाव
Android 8 की शुरुआत से, Android फ़्रेमवर्क और एचएएल, अब एक-दूसरे के साथ शेयर करते हैं. क्योंकि यह बातचीत काफ़ी हद तक बाइंडर की संख्या में बढ़ोतरी करती है Android 8 में कई ऐसे सुधार किए गए हैं जो आईपीसी को सुरक्षित रखने के लिए डिज़ाइन किए गए हैं तेज़. SoC वेंडर और OEM को सीधे तौर पर, इन ब्रांच से मर्ज करना चाहिए Android-4.4, android-4.9 और इसके बाद के वर्शन kernel/common प्रोजेक्ट में सबमिट किया जाता है.
एक से ज़्यादा बाइंडर डोमेन (संदर्भ)
सामान्य-4.4 और उससे ज़्यादा, अपस्ट्रीम भी शामिल हैबाइंडर ट्रैफ़िक को फ़्रेमवर्क (डिवाइस-स्वतंत्र) और वेंडर (डिवाइस के हिसाब से) कोड के साथ, Android 8 ने बाइंडर का सिद्धांत पेश किया कॉन्टेक्स्ट. हर बाइंडर कॉन्टेक्स्ट का अपना डिवाइस नोड और उसका कॉन्टेक्स्ट होता है (सेवा) मैनेजर के पास करना है. कॉन्टेक्स्ट मैनेजर को सिर्फ़ इस डिवाइस से ऐक्सेस किया जा सकता है वह नोड जिससे वह संबंधित है और किसी खास नोड से बाइंडर नोड पास करता है है, तो उसे उसी संदर्भ से सिर्फ़ दूसरी प्रोसेस से ऐक्सेस किया जा सकता है, इसलिए एक-दूसरे से पूरी तरह आइसोलेट कर दिया जाता है. इस्तेमाल करने के बारे में जानकारी के लिए, इसे देखें vndbinder और vndservicemanager.
स्कैटर-गेदर
सामान्य-4.4 और उससे ज़्यादा, अपस्ट्रीम भी शामिल हैAndroid के पिछले वर्शन में, बाइंडर कॉल में मौजूद हर डेटा कॉपी किया गया था तीन बार:
- इसे एक बार क्रम से लगाकर,
Parcelकॉल करने की प्रोसेस में Parcelको टारगेट में कॉपी करने के लिए, कर्नेल ड्राइवर में एक बार प्रोसेस- टारगेट प्रोसेस में
Parcelको क्रम से हटाने के लिए एक बार
Android 8 की सेवाएं
स्कैटर-गेदर
ऑप्टिमाइज़ेशन का इस्तेमाल करें. इसके बजाय
डेटा को पहले, Parcel में क्रम से लगाने पर, डेटा अपने ओरिजनल फ़ॉर्मैट में ही रहता है
स्ट्रक्चर और मेमोरी लेआउट को पूरा करता है और ड्राइवर उसे तुरंत टारगेट में कॉपी कर देता है
प्रोसेस. डेटा को टारगेट करने की प्रोसेस में होने के बाद, स्ट्रक्चर और मेमोरी
लेआउट वही है और डेटा को दूसरी कॉपी की ज़रूरत के बिना पढ़ा जा सकता है.
बारीक कटा हुआ लॉकिंग
सामान्य-4.4 और उससे ज़्यादा, अपस्ट्रीम भी शामिल हैAndroid के पिछले वर्शन में, बाइंडर ड्राइवर ने सुरक्षा के लिए ग्लोबल लॉक का इस्तेमाल किया था अहम डेटा स्ट्रक्चर को एक साथ ऐक्सेस किए जाने पर. हालांकि, लॉक के लिए विवाद था, तो मुख्य समस्या यह थी कि अगर थ्रेड कम प्राथमिकता वाला था, तो लॉक को लॉक कर देता है और फिर उसे निकाल देता है. इस वजह से, ज़्यादा प्राथमिकता वाले ऐसे थ्रेड जिनके लिए एक ही लॉक सेट करना हो. इससे जैंक होने के बावजूद प्लैटफ़ॉर्म.
इस समस्या को हल करने के शुरुआती प्रयास में प्रीम्प्टेशन को अक्षम करना शामिल था ग्लोबल लॉक को पकड़े हुए. हालांकि, यह सही समाधान के बजाय हैकिंग जैसा था, आखिर में, अपस्ट्रीम ने इसे अस्वीकार कर दिया और खारिज कर दिया. बाद की कोशिशें लॉक करने के तरीके को और ज़्यादा बारीकी से दिखाने पर फ़ोकस किया है. इसका एक वर्शन चालू है Pixel डिवाइसों पर. जबकि, इनमें से ज़्यादातर बदलाव किए गए थे सार्वजनिक किए गए, लेकिन बाद के वर्शन में काफ़ी सुधार किए गए.
सटीक लॉक लागू करने में छोटी-छोटी समस्याओं का पता लगाने के बाद, हम लॉक करने के अलग-अलग सिस्टम के साथ एक बेहतर समाधान तैयार किया है और सबमिट किया है सभी सामान्य कर्नेल ब्रांच में किए गए बदलाव. हम इसकी लगातार जांच कर रहे हैं बड़ी संख्या में अलग-अलग डिवाइसों पर लागू करना; क्योंकि हमें किसी अन्य कंपनी के बारे में बची हुई समस्याएं, डिवाइसों की शिपिंग के लिए यह सुझाया गया तरीका है Android 8 के साथ काम करता है.
रीयल-टाइम में प्राथमिकता इनहेरिटेंस
सामान्य-4.4 और कॉमन-4.9 (अपस्ट्रीम जल्द ही उपलब्ध होगा)बाइंडर ड्राइवर हमेशा बेहतर प्रायॉरिटी इनहेरिटेंस के साथ काम करता है. इस तौर पर बढ़ती हुई प्रोसेस की वजह से, Android में रीयल-टाइम प्राथमिकता के हिसाब से प्रोसेस की जाती हैं. इसमें, अब इस पर विचार करते हैं कि अगर रीयल-टाइम थ्रेड एक बाइंडर कॉल करती है, तो उस कॉल को हैंडल करने वाली थ्रेड, जो रीयल-टाइम प्राथमिकता पर चलती है. यहां की यात्रा पर हूं Android 8, अब रीयल-टाइम प्रायॉरिटी इनहेरिटेंस को लागू करता है. बाइंडर ड्राइवर में.
ट्रांज़ैक्शन-लेवल की प्राथमिकता इनहेरिटेंस के अलावा, नोड प्राथमिकता इनहेरिटेंस की मदद से, नोड (बाइंडर सर्विस ऑब्जेक्ट) को यह तय करने की अनुमति मिलती है कि कम से कम वह प्राथमिकता जिस पर इस नोड में आने वाले कॉल चलाए जाने चाहिए. इसके पिछले वर्शन Android पहले से ही अच्छे मानों के साथ नोड प्राथमिकता इनहेरिटेंस का समर्थन करता है, लेकिन Android 8, रीयल-टाइम शेड्यूल करने की नीतियों के नोड इनहेरिटेंस के साथ काम करता है.
यूज़रस्पेस में बदलाव
Android 8 में, यूज़र स्पेस के मौजूदा वर्शन के साथ काम करने के लिए, सभी ज़रूरी बदलाव शामिल हैं
एक अपवाद के साथ सामान्य कर्नेल में बाइंडर ड्राइवर: मूल
लागू करने पर, रीयल-टाइम प्रायॉरिटी इनहेरिटेंस को बंद किया जा सकेगा
/dev/binder ने
ioctl. बाद में हुए डेवलपमेंट की वजह से प्राथमिकता का कंट्रोल बदल गया
इनहेरिटेंस के लिए हर बाइंडर मोड (न कि हर बाइंडर मोड) के हिसाब से
संदर्भ). इसलिए, ioctl Android की सामान्य शाखा में नहीं है और इसके बजाय
जिसे हमारे कॉमन कर्नेल में सबमिट किया गया है.
इस बदलाव का असर यह होता है कि रीयल-टाइम प्रायॉरिटी इनहेरिटेंस बंद हो जाता है
हर नोड के लिए डिफ़ॉल्ट. Android की परफ़ॉर्मेंस टीम को यह पता चल गया है
में सभी नोड के लिए रीयल-टाइम प्राथमिकता इनहेरिटेंस चालू करने का फ़ायदा मिलता है
hwbinder डोमेन. उसी इफ़ेक्ट को पाने के लिए, चेरी चुनें
यह बदलाव यूज़रस्पेस में किया जा सकता है.
सामान्य कर्नेल के लिए SHA
बाइंडर ड्राइवर में ज़रूरी बदलाव पाने के लिए, सही SHA से सिंक करें:
- कॉमन-3.18
cc8b90c121de ANDROID: बाइंडर: बहाल करने के लिए prio अनुमतियों की जांच न करें. - कॉमन-4.4
76b376eac7a2 ANDROID: बाइंडर: बहाल करने के लिए prio अनुमतियों की जांच न करें. - कॉमन-4.9
ecd972d4f9b5 ANDROID: बाइंडर: बहाल करने के लिए मूल अनुमति की जाँच न करें.
बाइंडर आईपीसी के साथ काम करें
पहले भी, वेंडर प्रोसेस में बाइंडर इंटरप्रोसेस कम्यूनिकेशन का इस्तेमाल होता था
(IPC) का इस्तेमाल करें. Android 8 में, /dev/binder डिवाइस नोड
उस प्लैटफ़ॉर्म पर खास तौर पर फ़्रेमवर्क से जुड़ी प्रोसेस लागू हो जाएगी. इसका मतलब है कि वेंडर की प्रोसेस अब पूरी तरह से लागू नहीं होंगी
उसे ऐक्सेस कर सकता है. वेंडर प्रोसेस, /dev/hwbinder को ऐक्सेस कर सकती हैं, लेकिन
HIDL का इस्तेमाल करने के लिए, अपने एआईडीएल इंटरफ़ेस को बदलना ज़रूरी है. उन वेंडर के लिए जो जारी रखना चाहते हैं
यह वेंडर प्रोसेस के बीच AIDL इंटरफ़ेस का इस्तेमाल करके, Android पर इस तरह से बाइंडर आईपीसी काम करता है:
जिनकी जानकारी नीचे दी गई है. Android 10 में स्टेबल एआईडीएल
स्थिरता से जुड़ी समस्या को हल करते हुए, /dev/binder का इस्तेमाल करने की प्रोसेस
HIDL और /dev/hwbinder की समस्या हल होने की गारंटी देता है. स्टेबल चैनल इस्तेमाल करने का तरीका
एआईडीएल, देखें
एचएएल के लिए एआईडीएल.
वीएनडीबाइंडर
Android 8, वेंडर सेवाओं के लिए नए बाइंडर डोमेन के साथ काम करता है. इस डोमेन को ऐक्सेस किया जा सकता है
/dev/binder के बजाय, /dev/vndbinder का इस्तेमाल किया जा रहा है.
/dev/vndbinder के अलावा, Android पर अब ये तीन सुविधाएं उपलब्ध हैं
आईपीसी डोमेन:
| आईपीसी डोमेन | ब्यौरा |
|---|---|
/dev/binder |
एआईडीएल इंटरफ़ेस के साथ फ़्रेमवर्क/ऐप्लिकेशन प्रोसेस के बीच आईपीसी |
/dev/hwbinder |
HIDL इंटरफ़ेस के साथ फ़्रेमवर्क/वेंडर प्रोसेस के बीच आईपीसी
HIDL इंटरफ़ेस वाली वेंडर प्रोसेस के बीच आईपीसी |
/dev/vndbinder |
एआईडीएल इंटरफ़ेस के साथ वेंडर/वेंडर प्रोसेस के बीच आईपीसी |
/dev/vndbinder दिखाने के लिए, कर्नेल कॉन्फ़िगरेशन की जांच करें
आइटम CONFIG_ANDROID_BINDER_DEVICES को इस पर सेट किया गया
"binder,hwbinder,vndbinder" (यह Android की
सामान्य कर्नेल ट्री.
आम तौर पर, वेंडर प्रोसेस में बाइंडर ड्राइवर को सीधे तौर पर नहीं खोला जाता. इसके बजाय, यह सीधे तौर पर नहीं खुलता
libbinder यूज़रस्पेस लाइब्रेरी से लिंक करें, जिससे
बाइंडर ड्राइवर. ::android::ProcessState() के लिए कोई तरीका जोड़ा जा रहा है
libbinder के लिए बाइंडर ड्राइवर चुनता है. वेंडर की प्रोसेस में
ProcessState, पर कॉल करने से पहले इस तरीके को कॉल करें
IPCThreadState या सामान्य तौर पर कोई बाइंडर कॉल करने से पहले. यहां की यात्रा पर हूं
इसका इस्तेमाल करें, वेंडर प्रोसेस के main() के बाद यह कॉल करें
(क्लाइंट और सर्वर):
ProcessState::initWithDriver("/dev/vndbinder");
Vndservicemanager
पहले, बाइंडर सेवाएं servicemanager के साथ रजिस्टर होती थीं,
जहां उन्हें अन्य प्रोसेस की मदद से वापस लाया जा सकता है. Android 8 में,
servicemanager का इस्तेमाल अब खास तौर पर फ़्रेमवर्क और ऐप्लिकेशन में किया जाता है
और वेंडर प्रोसेस अब इसे ऐक्सेस नहीं कर सकते.
हालांकि, वेंडर सेवाएं अब vndservicemanager का इस्तेमाल कर सकती हैं. यह नई सुविधा है
servicemanager का इंस्टेंस जो /dev/vndbinder का इस्तेमाल करता है
होता है, जो /dev/binder के बजाय समान स्रोतों से बनाया गया है
फ़्रेमवर्क servicemanager. वेंडर की प्रोसेस को
vndservicemanager से बात करने के लिए बदलाव; वेंडर प्रोसेस खुलने पर
/dev/vndbinder, सेवा लुकअप अपने आप यहां जाएंगे
vndservicemanager.
vndservicemanager बाइनरी, Android के डिफ़ॉल्ट में शामिल है
डिवाइस बनाते हैं.
SELinux नीति
वेंडर की ऐसी प्रोसेस जिनके साथ कम्यूनिकेट करने के लिए, बाइंडर फ़ंक्शन का इस्तेमाल करना है एक-दूसरे को इनकी ज़रूरत होती है:
/dev/vndbinderका ऐक्सेस.- बाइंडर
{transfer, call}ने हुक कोvndservicemanager. - कॉल करने वाले किसी भी वेंडर डोमेन A के लिए
binder_call(A, B)वेंडर डोमेन B में, वेंडर बाइंडर इंटरफ़ेस पर. - इस देश में
{add, find}सेवाओं को इस्तेमाल करने की अनुमतिvndservicemanager.
पहली और दूसरी ज़रूरी शर्तों को पूरा करने के लिए, vndbinder_use() का इस्तेमाल करें
मैक्रो:
vndbinder_use(some_vendor_process_domain);
तीसरी शर्त को पूरा करने के लिए, वेंडर के लिए binder_call(A, B)
ऐसी प्रोसेस A और B मौजूद रह सकती हैं जिन्हें बाइंडर के बारे में बात करने की ज़रूरत होती है, लेकिन वे वैसी नहीं होतीं
नाम बदलना होगा.
चौथी ज़रूरी शर्त को पूरा करने के लिए, आपको सेवा के नामों में बदलाव करने होंगे, और नियमों को मैनेज किया जाता है.
SELinux के बारे में जानकारी के लिए सुरक्षा की बेहतर सुविधा वाले पेज देखें Android में Linux. Android 8.0 में SELinux पर विवरण के लिए, देखें Android के लिए SELinux 8.0 है.
सेवा के नाम
पहले, वेंडर रजिस्टर किए गए सेवा के नामों को
service_contexts फ़ाइल और ऐक्सेस करने के लिए, इससे जुड़े नियम जोड़े गए
उस फ़ाइल को कॉपी कर सकते हैं. service_contexts फ़ाइल का उदाहरण:
device/google/marlin/sepolicy:
AtCmdFwd u:object_r:atfwd_service:s0 cneservice u:object_r:cne_service:s0 qti.ims.connectionmanagerservice u:object_r:imscm_service:s0 rcs u:object_r:radio_service:s0 uce u:object_r:uce_service:s0 vendor.qcom.PeripheralManager u:object_r:per_mgr_service:s0
Android 8 में, vndservicemanager
इसके बजाय vndservice_contexts फ़ाइल का इस्तेमाल करें. वेंडर की सेवाओं को इस पर माइग्रेट किया जा रहा है
vndservicemanager (और जो पहले से पुराने में हैं
service_contexts फ़ाइल) को
vndservice_contexts फ़ाइल.
सेवा के लेबल
पहले, सेवा लेबल, जैसे कि u:object_r:atfwd_service:s0
को service.te फ़ाइल में तय किया गया था. उदाहरण:
type atfwd_service, service_manager_type;
Android 8 में, आपको टाइप बदलना होगा
vndservice_manager_type और नियम को
vndservice.te फ़ाइल. उदाहरण:
type atfwd_service, vndservice_manager_type;
सर्विस मैनेजर के नियम
पहले, नियमों को डोमेन को इनसे सेवाएं जोड़ने या ढूंढने का ऐक्सेस दिया जाता था
servicemanager. उदाहरण:
allow atfwd atfwd_service:service_manager find; allow some_vendor_app atfwd_service:service_manager add;
Android 8 में, ये नियम लागू रह सकते हैं और एक ही क्लास का इस्तेमाल कर सकते हैं. उदाहरण:
allow atfwd atfwd_service:service_manager find; allow some_vendor_app atfwd_service:service_manager add;