GKI के लिए कर्नेल कोड विकसित करें

जेनेरिक कर्नेल इमेज (जीकेआई) अपस्ट्रीम लिनक्स कर्नेल के साथ निकटता से संरेखित करके कर्नेल विखंडन को कम करता है। हालाँकि, ऐसे वैध कारण हैं कि क्यों कुछ पैच को अपस्ट्रीम में स्वीकार नहीं किया जा सकता है, और ऐसे उत्पाद शेड्यूल हैं जिन्हें पूरा किया जाना चाहिए, इसलिए कुछ पैच एंड्रॉइड कॉमन कर्नेल (एसीके) स्रोतों में बनाए रखे जाते हैं जिनसे जीकेआई बनाया जाता है।

डेवलपर्स को पहली पसंद के रूप में लिनक्स कर्नेल मेलिंग सूची (एलकेएमएल) का उपयोग करके अपस्ट्रीम में कोड परिवर्तन सबमिट करना होगा, और एसीके android-mainline शाखा में कोड परिवर्तन तभी सबमिट करना होगा जब कोई मजबूत कारण हो कि अपस्ट्रीम व्यवहार्य न हो। वैध कारणों के उदाहरण और उनसे निपटने के तरीके इस प्रकार सूचीबद्ध हैं।

• पैच एलकेएमएल को सबमिट किया गया था, लेकिन उत्पाद रिलीज के समय इसे स्वीकार नहीं किया गया था। इस पैच को संभालने के लिए:

  • साक्ष्य प्रदान करें कि पैच एलकेएमएल को सबमिट किया गया था और पैच के लिए प्राप्त टिप्पणियाँ, या अनुमानित समय जिसके द्वारा पैच अपस्ट्रीम सबमिट किया जाएगा।
  • पैच को ACK में लाने के लिए कार्रवाई का एक तरीका तय करें, इसे अपस्ट्रीम में अनुमोदित करें, और फिर जब अंतिम अपस्ट्रीम संस्करण ACK में विलय हो जाए तो इसे ACK से बाहर निकालें।

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

• पैच अपस्ट्रीम के लिए पर्याप्त सामान्य नहीं है और उत्पाद रिलीज़ से पहले इसे दोबारा तैयार करने का समय नहीं है। इस पैच को संभालने के लिए, एक अनुमानित समय प्रदान करें जिसके द्वारा एक रिफैक्टर्ड पैच अपस्ट्रीम सबमिट किया जाएगा (समीक्षा के लिए रिफैक्टर्ड पैच अपस्ट्रीम सबमिट करने की योजना के बिना पैच को ACK में स्वीकार नहीं किया जाएगा)।

• पैच को अपस्ट्रीम द्वारा स्वीकार नहीं किया जा सकता क्योंकि... <यहां कारण डालें> । इस पैच को संभालने के लिए, एंड्रॉइड कर्नेल टीम तक पहुंचें और पैच को रीफैक्टर करने के विकल्पों पर हमारे साथ काम करें ताकि इसे समीक्षा के लिए सबमिट किया जा सके और अपस्ट्रीम में स्वीकार किया जा सके।

बहुत अधिक संभावित औचित्य हैं। जब आप अपना बग या अपना पैच सबमिट करते हैं, तो एक वैध औचित्य शामिल करें और कुछ पुनरावृत्ति और चर्चा की अपेक्षा करें। हम मानते हैं कि ACK में कुछ पैच होंगे, विशेष रूप से GKI के शुरुआती चरणों में, जबकि हर कोई सीख रहा है कि अपस्ट्रीम में कैसे काम किया जाए, लेकिन ऐसा करने के लिए उत्पाद शेड्यूल में ढील नहीं दी जा सकती। उम्मीद करें कि समय के साथ अपस्ट्रीमिंग आवश्यकताएँ और अधिक सख्त हो जाएँगी।

पैच आवश्यकताएँ

पैच को लिनक्स स्रोत ट्री में वर्णित लिनक्स कर्नेल कोडिंग मानकों के अनुरूप होना चाहिए, चाहे वे अपस्ट्रीम या एसीके में सबमिट किए गए हों। scripts/checkpatch.pl स्क्रिप्ट को गेरिट प्रीसबमिट परीक्षण के भाग के रूप में चलाया जाता है, इसलिए यह सुनिश्चित करने के लिए इसे पहले ही चला लें कि यह पास हो जाए। चेकपैच स्क्रिप्ट को प्रीसबमिट परीक्षण के समान कॉन्फ़िगरेशन के साथ चलाने के लिए, //build/kernel/static_analysis:checkpatch_presubmit उपयोग करें। विवरण के लिए, build/kernel/kleaf/docs/checkpatch.md देखें।

एसीके पैच

ACK को सबमिट किए गए पैच को Linux कर्नेल कोडिंग मानकों और योगदान दिशानिर्देशों के अनुरूप होना चाहिए। आपको प्रतिबद्ध संदेश में Change-Id टैग शामिल करना होगा; यदि आप पैच को कई शाखाओं में सबमिट करते हैं (उदाहरण के लिए, android-mainline और android12-5.4 ), तो आपको पैच के सभी उदाहरणों के लिए एक ही Change-Id उपयोग करना होगा।

अपस्ट्रीम समीक्षा के लिए पहले एलकेएमएल में पैच सबमिट करें। यदि पैच है:

• अपस्ट्रीम में स्वीकृत, यह स्वचालित रूप से android-mainline में विलय हो गया है।
• अपस्ट्रीम स्वीकार नहीं किया गया है, इसे अपस्ट्रीम सबमिशन के संदर्भ में या एलकेएमएल को सबमिट क्यों नहीं किया गया इसके स्पष्टीकरण के साथ android-mainline पर सबमिट करें।

किसी पैच को अपस्ट्रीम या android-mainline में स्वीकार किए जाने के बाद, इसे उचित एलटीएस-आधारित एसीके (जैसे कि एंड्रॉइड-विशिष्ट कोड को ठीक करने वाले पैच के लिए android12-5.4 और android11-5.4 ) पर बैकपोर्ट किया जा सकता है। android-mainline पर सबमिट करने से नए अपस्ट्रीम रिलीज़ उम्मीदवारों के साथ परीक्षण सक्षम हो जाता है और गारंटी मिलती है कि पैच अगले एलटीएस-आधारित एसीके में है। अपवादों में ऐसे मामले शामिल हैं जहां एक अपस्ट्रीम पैच को android12-5.4 पर बैकपोर्ट किया गया है (क्योंकि पैच पहले से ही android-mainline में होने की संभावना है)।

अपस्ट्रीम पैच

जैसा कि योगदान दिशानिर्देशों में निर्दिष्ट है, एसीके कर्नेल के लिए नियत अपस्ट्रीम पैच निम्नलिखित समूहों में आते हैं (स्वीकार किए जाने की संभावना के क्रम में सूचीबद्ध)।

• UPSTREAM: - यदि उचित उपयोग का मामला है तो 'एंड्रॉइड-मेनलाइन' से चुने गए पैच को ACK में स्वीकार किए जाने की संभावना है।
• BACKPORT: - अपस्ट्रीम से पैच जो साफ-सुथरे ढंग से नहीं चुने जाते हैं और उनमें संशोधन की आवश्यकता है, उन्हें भी स्वीकार किए जाने की संभावना है यदि उचित उपयोग का मामला हो।
• FROMGIT: - लिनक्स मेनलाइन पर सबमिट करने की तैयारी में अनुरक्षक शाखा से चुने गए पैच को आगामी समय सीमा होने पर स्वीकार किया जा सकता है। इन्हें सामग्री और शेड्यूल दोनों के लिए उचित ठहराया जाना चाहिए।
• FROMLIST: - पैच जो एलकेएमएल को सबमिट कर दिए गए हैं लेकिन अभी तक अनुरक्षक शाखा में स्वीकार नहीं किए गए हैं, उन्हें स्वीकार किए जाने की संभावना नहीं है, जब तक कि औचित्य पर्याप्त रूप से बाध्यकारी न हो कि पैच स्वीकार किया जाएगा चाहे वह अपस्ट्रीम लिनक्स में आए या नहीं (हम मानते हैं) कि ऐसा नहीं होगा)। एंड्रॉइड कर्नेल टीम के साथ चर्चा को सुविधाजनक बनाने के लिए FROMLIST पैच से जुड़ा कोई मुद्दा होना चाहिए।

Android-विशिष्ट पैच

यदि आप अपस्ट्रीम में आवश्यक परिवर्तन नहीं कर सकते हैं, तो आप सीधे ACK को आउट-ऑफ-ट्री पैच सबमिट करने का प्रयास कर सकते हैं। आउट-ऑफ़-ट्री पैच सबमिट करने के लिए आवश्यक है कि आप आईटी में एक मुद्दा बनाएं जो पैच और तर्क का हवाला देता है कि पैच को अपस्ट्रीम में सबमिट क्यों नहीं किया जा सकता है (उदाहरण के लिए पिछली सूची देखें)। हालाँकि, ऐसे कुछ मामले हैं जहाँ कोड को अपस्ट्रीम सबमिट नहीं किया जा सकता है। इन मामलों को निम्नानुसार कवर किया गया है और उन्हें एंड्रॉइड-विशिष्ट पैच के लिए योगदान दिशानिर्देशों का पालन करना होगा और विषय में ANDROID: उपसर्ग के साथ टैग किया जाना चाहिए।

Gki_defconfig में परिवर्तन

gki_defconfig में सभी CONFIG परिवर्तन Arm64 और x86 दोनों संस्करणों पर लागू होने चाहिए, जब तक कि CONFIG आर्किटेक्चर-विशिष्ट न हो। CONFIG सेटिंग में बदलाव का अनुरोध करने के लिए, परिवर्तन पर चर्चा करने के लिए आईटी में एक मुद्दा बनाएं। कोई भी CONFIG परिवर्तन जो कर्नेल मॉड्यूल इंटरफ़ेस (KMI) के जमने के बाद उसे प्रभावित करता है, अस्वीकार कर दिया जाता है। ऐसे मामलों में जहां भागीदार एकल कॉन्फिगरेशन के लिए विरोधाभासी सेटिंग्स का अनुरोध करते हैं, हम संबंधित बग पर चर्चा के माध्यम से विवादों का समाधान करते हैं।

वह कोड जो अपस्ट्रीम में मौजूद नहीं है

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

इस श्रेणी में अन्य परिवर्तन KMI प्रतिनिधित्व फ़ाइलों, KMI प्रतीक सूचियों, gki_defconfig , बिल्ड स्क्रिप्ट या कॉन्फ़िगरेशन, या अन्य स्क्रिप्ट के अपडेट हैं जो अपस्ट्रीम में मौजूद नहीं हैं।

आउट-ऑफ़-ट्री मॉड्यूल

अपस्ट्रीम लिनक्स सक्रिय रूप से आउट-ऑफ़-ट्री मॉड्यूल के निर्माण के लिए समर्थन को हतोत्साहित करता है। यह एक उचित स्थिति है क्योंकि लिनक्स अनुरक्षक इन-कर्नेल स्रोत या बाइनरी संगतता के बारे में गारंटी नहीं देते हैं और उस कोड का समर्थन नहीं करना चाहते हैं जो ट्री में नहीं है। हालाँकि, GKI विक्रेता मॉड्यूल के लिए ABI गारंटी देता है , यह सुनिश्चित करते हुए कि KMI इंटरफ़ेस कर्नेल के समर्थित जीवनकाल के लिए स्थिर है। इसलिए, विक्रेता मॉड्यूल का समर्थन करने के लिए परिवर्तनों का एक वर्ग है जो ACK के लिए स्वीकार्य हैं लेकिन अपस्ट्रीम के लिए स्वीकार्य नहीं हैं।

उदाहरण के लिए, एक पैच पर विचार करें जो EXPORT_SYMBOL_GPL() मैक्रोज़ जोड़ता है जहां निर्यात का उपयोग करने वाले मॉड्यूल स्रोत ट्री में नहीं हैं। जबकि आपको EXPORT_SYMBOL_GPL() अपस्ट्रीम के लिए अनुरोध करने और नए निर्यात किए गए प्रतीक का उपयोग करने वाले मॉड्यूल की आपूर्ति करने का प्रयास करना चाहिए, यदि मॉड्यूल को अपस्ट्रीम में सबमिट नहीं किया जा रहा है, तो इसके लिए कोई वैध औचित्य है, तो आप इसके बजाय ACK को पैच सबमिट कर सकते हैं। आपको इस मुद्दे में इस बात का औचित्य शामिल करना होगा कि मॉड्यूल को अपस्ट्रीम क्यों नहीं किया जा सकता है। (गैर-जीपीएल संस्करण, EXPORT_SYMBOL() अनुरोध न करें।)

छुपी हुई कॉन्फ़िगरेशन

कुछ इन-ट्री मॉड्यूल स्वचालित रूप से छिपी हुई कॉन्फ़िगरेशन का चयन करते हैं जिन्हें gki_defconfig में निर्दिष्ट नहीं किया जा सकता है। उदाहरण के लिए, CONFIG_SND_SOC_SOF=y कॉन्फ़िगर होने पर CONFIG_SND_SOC_TOPOLOGY स्वचालित रूप से चयनित हो जाती है। आउट-ऑफ-ट्री मॉड्यूल बिल्डिंग को समायोजित करने के लिए, जीकेआई में छिपी हुई कॉन्फ़िगरेशन को सक्षम करने के लिए एक तंत्र शामिल है।

किसी छिपे हुए कॉन्फ़िगरेशन को सक्षम करने के लिए, init/Kconfig.gki में एक select कथन जोड़ें ताकि यह CONFIG_GKI_HACKS_TO_FIX कर्नेल कॉन्फ़िगरेशन के आधार पर स्वचालित रूप से चयनित हो, जो gki_defconfig में सक्षम है। इस तंत्र का उपयोग केवल छुपी हुई कॉन्फ़िगरेशन के लिए करें; यदि कॉन्फ़िगरेशन छिपा हुआ नहीं है, तो इसे gki_defconfig में स्पष्ट रूप से या निर्भरता के रूप में निर्दिष्ट किया जाना चाहिए।

लोड करने योग्य गवर्नर

कर्नेल फ्रेमवर्क (जैसे cpufreq ) के लिए जो लोड करने योग्य गवर्नर का समर्थन करते हैं, आप डिफ़ॉल्ट गवर्नर को ओवरराइड कर सकते हैं (जैसे कि cpufreq के schedutil गवर्नर)। फ्रेमवर्क के लिए (जैसे कि थर्मल फ्रेमवर्क) जो लोड करने योग्य गवर्नर या ड्राइवर का समर्थन नहीं करते हैं लेकिन फिर भी एक की आवश्यकता होती है विक्रेता-विशिष्ट कार्यान्वयन, आईटी में एक समस्या बनाएं और एंड्रॉइड कर्नेल टीम से परामर्श लें।

हम आवश्यक समर्थन जोड़ने के लिए आपके और अपस्ट्रीम अनुरक्षकों के साथ काम करेंगे।

विक्रेता हुक

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

विक्रेता हुक दो प्रकारों (सामान्य और प्रतिबंधित) में आते हैं जो ट्रेसप्वाइंट (ट्रेस घटनाओं पर नहीं) पर आधारित होते हैं जिन्हें विक्रेता मॉड्यूल संलग्न कर सकते हैं। उदाहरण के लिए, कार्य निकास पर लेखांकन करने के लिए एक नया sched_exit() फ़ंक्शन जोड़ने के बजाय, विक्रेता do_exit() में एक हुक जोड़ सकते हैं जिसे एक विक्रेता मॉड्यूल प्रसंस्करण के लिए संलग्न कर सकता है। एक उदाहरण कार्यान्वयन में निम्नलिखित विक्रेता हुक शामिल हैं।

• सामान्य विक्रेता हुक trace_ name के साथ एक ट्रेसपॉइंट फ़ंक्शन बनाने के लिए DECLARE_HOOK() का उपयोग करते हैं, जहां name ट्रेस के लिए अद्वितीय पहचानकर्ता है। परंपरा के अनुसार, सामान्य विक्रेता हुक नाम android_vh से शुरू होते हैं, इसलिए sched_exit() हुक का नाम android_vh_sched_exit होगा।
• शेड्यूलर हुक जैसे मामलों के लिए प्रतिबंधित विक्रेता हुक की आवश्यकता होती है, जहां संलग्न फ़ंक्शन को कॉल किया जाना चाहिए, भले ही सीपीयू ऑफ़लाइन हो या गैर-परमाणु संदर्भ की आवश्यकता हो। प्रतिबंधित विक्रेता हुक को अलग नहीं किया जा सकता है, इसलिए प्रतिबंधित हुक से जुड़े मॉड्यूल कभी भी अनलोड नहीं हो सकते हैं। प्रतिबंधित विक्रेता हुक नाम android_rvh से शुरू होते हैं।

विक्रेता हुक जोड़ने के लिए, आईटी में एक समस्या दर्ज करें और पैच सबमिट करें (जैसा कि सभी एंड्रॉइड-विशिष्ट पैच के साथ, एक समस्या मौजूद होनी चाहिए और आपको औचित्य प्रदान करना होगा)। विक्रेता हुक के लिए समर्थन केवल ACK में है, इसलिए इन पैच को अपस्ट्रीम लिनक्स पर न भेजें।

संरचनाओं में विक्रेता फ़ील्ड जोड़ें

आप ANDROID_VENDOR_DATA() मैक्रोज़ का उपयोग करके android_vendor_data फ़ील्ड जोड़कर विक्रेता डेटा को प्रमुख डेटा संरचनाओं के साथ जोड़ सकते हैं। उदाहरण के लिए, मूल्य-वर्धित सुविधाओं का समर्थन करने के लिए, फ़ील्ड को संरचनाओं में जोड़ें जैसा कि निम्नलिखित कोड नमूने में दिखाया गया है।

विक्रेताओं द्वारा आवश्यक फ़ील्ड और OEM द्वारा आवश्यक फ़ील्ड के बीच संभावित टकराव से बचने के लिए, OEM को कभी भी ANDROID_VENDOR_DATA() मैक्रोज़ का उपयोग करके घोषित फ़ील्ड का उपयोग नहीं करना चाहिए। इसके बजाय, OEM को android_oem_data फ़ील्ड घोषित करने के लिए ANDROID_OEM_DATA() का उपयोग करना चाहिए।

#include <linux/android_vendor.h>
...
struct important_kernel_data {
  [all the standard fields];
  /* Create vendor data for use by hook implementations. The
   * size of vendor data is based on vendor input. Vendor data
   * can be defined as single u64 fields like the following that
   * declares a single u64 field named "android_vendor_data1" :
   */
  ANDROID_VENDOR_DATA(1);

  /*
   * ...or an array can be declared. The following is equivalent to
   * u64 android_vendor_data2[20]:
   */
  ANDROID_VENDOR_DATA_ARRAY(2, 20);

  /*
   * SoC vendors must not use fields declared for OEMs and
   * OEMs must not use fields declared for SoC vendors.
   */
  ANDROID_OEM_DATA(1);

  /* no further fields */
}

विक्रेता हुक को परिभाषित करें

विक्रेता हुक को कर्नेल कोड में ट्रेसपॉइंट के रूप में जोड़ें, उन्हें DECLARE_HOOK() या DECLARE_RESTRICTED_HOOK() का उपयोग करके घोषित करें और फिर उन्हें ट्रेसपॉइंट के रूप में कोड में जोड़ें। उदाहरण के लिए, मौजूदा do_exit() कर्नेल फ़ंक्शन में trace_android_vh_sched_exit() जोड़ने के लिए:

#include <trace/hooks/exit.h>
void do_exit(long code)
{
    struct task_struct *tsk = current;
    ...
    trace_android_vh_sched_exit(tsk);
    ...
}

trace_android_vh_sched_exit() फ़ंक्शन प्रारंभ में केवल तभी जांचता है जब कुछ संलग्न हो। हालाँकि, यदि कोई विक्रेता मॉड्यूल register_trace_android_vh_sched_exit() का उपयोग करके एक हैंडलर को पंजीकृत करता है, तो पंजीकृत फ़ंक्शन को कॉल किया जाता है। हैंडलर को रखे गए ताले, आरसीएस स्थिति और अन्य कारकों के संदर्भ में अवगत होना चाहिए। हुक को include/trace/hooks निर्देशिका में हेडर फ़ाइल में परिभाषित किया जाना चाहिए।

उदाहरण के लिए, निम्नलिखित कोड include/trace/hooks/exit.h फ़ाइल में trace_android_vh_sched_exit() के लिए एक संभावित घोषणा देता है।

/* SPDX-License-Identifier: GPL-2.0 */
#undef TRACE_SYSTEM
#define TRACE_SYSTEM sched
#define TRACE_INCLUDE_PATH trace/hooks

#if !defined(_TRACE_HOOK_SCHED_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_HOOK_SCHED_H
#include <trace/hooks/vendor_hooks.h>
/*
 * Following tracepoints are not exported in tracefs and provide a
 * mechanism for vendor modules to hook and extend functionality
 */

struct task_struct;

DECLARE_HOOK(android_vh_sched_exit,
             TP_PROTO(struct task_struct *p),
             TP_ARGS(p));

#endif /* _TRACE_HOOK_SCHED_H */

/* This part must be outside protection */
#include <trace/define_trace.h>

विक्रेता हुक के लिए आवश्यक इंटरफ़ेस को तुरंत चालू करने के लिए, हुक घोषणा के साथ हेडर फ़ाइल को drivers/android/vendor_hooks.c में जोड़ें और प्रतीकों को निर्यात करें। उदाहरण के लिए, निम्न कोड android_vh_sched_exit() हुक की घोषणा को पूरा करता है।

#ifndef __GENKSYMS__
/* struct task_struct */
#include <linux/sched.h>
#endif

#define CREATE_TRACE_POINTS
#include <trace/hooks/vendor_hooks.h>
#include <trace/hooks/exit.h>
/*
 * Export tracepoints that act as a bare tracehook (i.e. have no trace
 * event associated with them) to allow external modules to probe
 * them.
 */
EXPORT_TRACEPOINT_SYMBOL_GPL(android_vh_sched_exit);

ध्यान दें : एबीआई स्थिरता की गारंटी के लिए हुक घोषणा के भीतर उपयोग की जाने वाली डेटा संरचनाओं को पूरी तरह से परिभाषित करने की आवश्यकता है। अन्यथा अपारदर्शी संकेतकों को अस्वीकार करना या आकार के संदर्भों में संरचना का उपयोग करना असुरक्षित है। ऐसे डेटा संरचनाओं की पूरी परिभाषा प्रदान करने वाले drivers/android/vendor_hooks.c के #ifndef __GENKSYMS__ अनुभाग के अंदर जाना चाहिए। KMI को तोड़ने वाले CRC परिवर्तनों से बचने के लिए include/trace/hooks में हेडर फ़ाइलों में प्रकार परिभाषाओं के साथ कर्नेल हेडर फ़ाइल शामिल नहीं होनी चाहिए। इसके बजाय आगे प्रकार घोषित करें।

विक्रेता हुक से जोड़ें

विक्रेता हुक का उपयोग करने के लिए, विक्रेता मॉड्यूल को हुक के लिए एक हैंडलर पंजीकृत करने की आवश्यकता होती है (आमतौर पर मॉड्यूल आरंभीकरण के दौरान किया जाता है)। उदाहरण के लिए, निम्न कोड trace_android_vh_sched_exit() के लिए मॉड्यूल foo.ko हैंडलर दिखाता है।

#include <trace/hooks/sched.h>
...
static void foo_sched_exit_handler(void *data, struct task_struct *p)
{
    foo_do_exit_accounting(p);
}
...
static int foo_probe(..)
{
    ...
    rc = register_trace_android_vh_sched_exit(foo_sched_exit_handler, NULL);
    ...
}

कोर कर्नेल विशेषताएँ

यदि पिछली तकनीकों में से कोई भी आपको मॉड्यूल से किसी सुविधा को लागू करने में सक्षम नहीं बनाती है, तो आपको कोर कर्नेल में एंड्रॉइड-विशिष्ट संशोधन के रूप में सुविधा को जोड़ना होगा। बातचीत शुरू करने के लिए इश्यू ट्रैकर (आईटी) में एक मुद्दा बनाएं।

उपयोगकर्ता एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (यूएपीआई)

• यूएपीआई हेडर फ़ाइलें। यूएपीआई हेडर फ़ाइलों में परिवर्तन अपस्ट्रीम में होने चाहिए, जब तक कि परिवर्तन एंड्रॉइड-विशिष्ट इंटरफ़ेस में न हों। विक्रेता मॉड्यूल और विक्रेता यूजरस्पेस कोड के बीच इंटरफेस को परिभाषित करने के लिए विक्रेता-विशिष्ट हेडर फ़ाइलों का उपयोग करें।
• sysfs नोड्स. GKI कर्नेल में नए sysfs नोड्स न जोड़ें (ऐसे जोड़ केवल विक्रेता मॉड्यूल में मान्य हैं)। एसओसी- और डिवाइस-अज्ञेयवादी पुस्तकालयों और एंड्रॉइड फ्रेमवर्क वाले जावा कोड द्वारा उपयोग किए जाने वाले sysfs नोड्स को केवल संगत तरीकों से बदला जा सकता है और यदि वे एंड्रॉइड-विशिष्ट sysfs नोड्स नहीं हैं तो उन्हें अपस्ट्रीम में बदला जाना चाहिए। आप विक्रेता उपयोगकर्ता स्थान द्वारा उपयोग किए जाने वाले विक्रेता-विशिष्ट sysfs नोड्स बना सकते हैं । डिफ़ॉल्ट रूप से, SELinux का उपयोग करके यूजरस्पेस द्वारा sysfs नोड्स तक पहुंच अस्वीकार कर दी जाती है। अधिकृत विक्रेता सॉफ़्टवेयर द्वारा पहुंच की अनुमति देने के लिए उचित SELinux लेबल जोड़ना विक्रेता पर निर्भर है।
• डीबगएफएस नोड्स। विक्रेता मॉड्यूल केवल डिबगिंग के लिए debugfs में नोड्स को परिभाषित कर सकते हैं (क्योंकि debugfs डिवाइस के सामान्य संचालन के दौरान माउंट नहीं किया जाता है)।