تعمل صورة النواة العامة (GKI) على تقليل تجزئة النواة من خلال التوافق بشكل كبير مع نواة Linux الأصلية. ومع ذلك، هناك أسباب وجيهة لعدم قبول بعض حِزم التصحيح في المصدر الرئيسي، كما أنّ هناك جداول زمنية للمنتجات يجب الالتزام بها، لذا يتم الاحتفاظ ببعض حِزم التصحيح في مصادر "نواة Android العامة" (ACK) التي يتم إنشاء GKI منها.
على المطوّرين إرسال تغييرات الرموز البرمجية إلى المصدر باستخدام قائمة Linux Kernel Mailing List (LKML) كخيار أول، وإرسال تغييرات الرموز البرمجية إلى فرع ACK android-mainline
فقط عند توفّر سبب قوي لعدم إمكانية إرسالها إلى المصدر. في ما يلي أمثلة على الأسباب الصالحة وكيفية التعامل معها.
تم إرسال رمز التصحيح إلى LKML، ولكن لم يتم قبوله في الوقت المناسب لإصدار المنتج. للتعامل مع هذا التصحيح، اتّبِع الخطوات التالية:
- قدِّم دليلًا على أنّه تم إرسال تصحيح إلى LKML وتلقّي تعليقات عليه، أو قدِّم وقتًا تقديريًا لإرسال التصحيح إلى المصدر.
- حدِّد مسار عمل لتضمين التصحيح في ACK والحصول على موافقة عليه في المصدر، ثم أزِله من ACK عند دمج الإصدار النهائي من المصدر في ACK.
يحدّد التصحيح
EXPORT_SYMBOLS_GPL()
لوحدة مورّد، ولكن تعذّر إرساله إلى المصدر لأنّه لا توجد وحدات في الشجرة تستخدم هذا الرمز. للتعامل مع هذا الرمز البرمجي للتصحيح، يُرجى تقديم تفاصيل حول سبب عدم إمكانية إرسال الوحدة إلى المصدر الرئيسي والبدائل التي أخذتها في الاعتبار قبل تقديم هذا الطلب.التصحيح ليس عامًا بما يكفي ليتم دمجه في الإصدارات المستقبلية، ولا يتوفّر الوقت لإعادة تصميمه قبل إصدار المنتج. للتعامل مع تصحيح الأخطاء هذا، يجب تقديم وقت تقديري لإرسال تصحيح أخطاء مُعاد تصميمه إلى المصدر (لن يتم قبول تصحيح الأخطاء في ACK بدون خطة لإرسال تصحيح أخطاء مُعاد تصميمه إلى المصدر للمراجعة).
لا يمكن قبول التصحيح من قِبل المصدر لأنّ... <insert reason here>. للتعامل مع هذا التصحيح، يُرجى التواصل مع فريق نواة Android والعمل معنا على خيارات إعادة تصميم التصحيح ليتم إرساله للمراجعة وقبوله في المصدر.
هناك الكثير من المبرّرات المحتملة الأخرى. عند إرسال الخطأ أو التصحيح، يجب تضمين مبرّر صالح وتوقُّع بعض التكرار والمناقشة. ندرك أنّ حزمة ACK تتضمّن بعض التصحيحات، خاصةً في المراحل المبكرة من GKI، بينما يتعلّم الجميع كيفية العمل في المصدر، ولكن لا يمكن تأجيل جداول المنتجات لإتاحة ذلك. نتوقّع أن تصبح متطلبات النقل إلى المصدر أكثر صرامة بمرور الوقت.
متطلبات التصحيح
يجب أن تتوافق تصحيحات الأخطاء مع معايير ترميز نواة Linux الموضّحة في
شجرة مصدر Linux،
سواء تم إرسالها إلى المصدر الرئيسي أو إلى ACK. يتم تنفيذ scripts/checkpatch.pl
النص البرمجي كجزء من اختبارات الإرسال المسبق في Gerrit، لذا نفِّذه مسبقًا للتأكّد من اجتيازه. لتشغيل البرنامج النصي checkpatch باستخدام الإعدادات نفسها المستخدَمة في اختبارات ما قبل الإرسال، استخدِم //build/kernel/static_analysis:checkpatch_presubmit
.
للاطّلاع على التفاصيل، يُرجى الانتقال إلى
build/kernel/kleaf/docs/checkpatch.md.
تصحيحات ACK
يجب أن تتوافق تصحيحات ACK مع معايير ترميز نواة Linux وإرشادات المساهمة.
يجب تضمين علامة Change-Id
في رسالة الالتزام. وفي حال إرسال تصحيح إلى فروع متعددة (مثل android-mainline
وandroid12-5.4
)، يجب استخدام Change-Id
نفسه لجميع مثيلات التصحيح.
أرسِل تصحيحات إلى LKML أولاً لإجراء مراجعة في المصدر. إذا كان التصحيح:
- تم قبول التغيير في المصدر الرئيسي، وسيتم دمجه تلقائيًا في
android-mainline
. - إذا لم يتم قبولها في المصدر، أرسِلها إلى
android-mainline
مع الإشارة إلى عملية الإرسال إلى المصدر أو توضيح سبب عدم إرسالها إلى LKML.
بعد قبول تصحيح إما في المصدر أو في android-mainline
، يمكن نقل التصحيح إلى إصدار ACK المناسب المستند إلى LTS (مثل android12-5.4
وandroid11-5.4
للتصحيحات التي تعمل على إصلاح الرمز البرمجي الخاص بنظام Android). يؤدي إرسال التصحيح إلى
android-mainline
إلى إتاحة الاختبار باستخدام أحدث الإصدارات التجريبية من المصدر
ويضمن تضمين التصحيح في حزمة ACK التالية المستندة إلى إصدار LTS. وتشمل الاستثناءات الحالات التي يتم فيها نقل إصلاح من إصدار أحدث إلى الإصدار android12-5.4
(لأنّ الإصلاح من المحتمل أن يكون متوفّرًا في الإصدار android-mainline
).
رموز التصحيح الأصلية
وفقًا لما هو محدّد في إرشادات المساهمة، تنقسم تصحيحات المصدر التي يتم إرسالها إلى نواة ACK إلى المجموعات التالية (المدرَجة حسب احتمال قبولها).
UPSTREAM:
- من المرجّح أن يتم قبول تصحيحات تم اختيارها من android-mainline في ACK إذا كانت هناك حالة استخدام معقولة.BACKPORT:
- من المرجّح أيضًا قبول التصحيحات من المصدر الرئيسي التي لا يمكن تطبيقها بشكل سليم وتحتاج إلى تعديل، وذلك إذا كان هناك حالة استخدام معقولة.-
FROMGIT:
- قد يتم قبول تصحيحات تم اختيارها من فرع خاص بالمشرفين استعدادًا لإرسالها إلى الإصدار الرئيسي من Linux، وذلك إذا كان هناك موعد نهائي وشيك. ويجب تقديم مبرّرات لكلّ من المحتوى والجدول الزمني. FROMLIST:
- من غير المرجّح أن يتم قبول تصحيحات تم إرسالها إلى LKML ولكن لم يتم قبولها في فرع الصيانة بعد، إلا إذا كان التبرير مقنعًا بما يكفي ليتم قبول التصحيح سواء تم إدراجه في Linux الأساسي أم لا (نفترض أنّه لن يتم إدراجه). يجب أن تكون هناك مشكلة مرتبطة بتصحيحاتFROMLIST
لتسهيل المناقشة مع فريق نواة Android.
تصحيحات خاصة بنظام Android
إذا لم تتمكّن من إجراء التغييرات المطلوبة في المصدر، يمكنك محاولة إرسال تصحيحات خارج المصدر إلى ACK مباشرةً. يتطلّب إرسال رموز تصحيح خارج الشجرة إنشاء مشكلة في فريق تكنولوجيا المعلومات تشير إلى رمز التصحيح والسبب الذي يمنع إرسال رمز التصحيح إلى المصدر (راجِع القائمة السابقة للاطّلاع على أمثلة).
ومع ذلك، هناك بعض الحالات التي لا يمكن فيها إرسال الرمز البرمجي إلى المصدر. يتم تناول هذه الحالات على النحو التالي، ويجب أن تتّبع إرشادات المساهمة الخاصة بتصحيحات Android، ويجب وضع العلامة ANDROID:
في بداية الموضوع.
التغييرات في gki_defconfig
يجب تطبيق جميع تغييرات CONFIG
على gki_defconfig
على كلّ من إصدارَي arm64 وx86، ما لم يكن CONFIG
خاصًا ببنية معيّنة. لطلب تغيير في إعداد CONFIG
، أنشئ مشكلة في قسم تكنولوجيا المعلومات لمناقشة التغيير. سيتم رفض أي
CONFIG
تغيير يؤثر في واجهة وحدة النواة (KMI) بعد تجميدها. في الحالات التي يطلب فيها الشركاء إعدادات متضاربة لتكوين واحد، نحلّ التعارضات من خلال مناقشة الأخطاء ذات الصلة.
رمز غير متوفّر في المصدر
لا يمكن إرسال تعديلات على الرمز البرمجي المخصّص لنظام التشغيل Android إلى المصدر. على سبيل المثال، على الرغم من أنّ برنامج تشغيل Binder يتم الاحتفاظ به في المصدر، لا يمكن إرسال التعديلات على ميزات Binder التي تعتمد على أولوية التوريث إلى المصدر لأنّها خاصة بنظام Android. يجب أن تكون صريحًا في وصف الخطأ وتوضيح سبب عدم إمكانية إرسال الرمز البرمجي إلى المصدر. إذا أمكن ذلك، قسِّم التصحيحات إلى أجزاء يمكن إرسالها إلى المصدر وأجزاء خاصة بنظام Android لا يمكن إرسالها إلى المصدر لتقليل مقدار الرمز البرمجي غير المتوفّر في المصدر الذي يتم الاحتفاظ به في ACK.
تشمل التغييرات الأخرى في هذه الفئة تعديلات على ملفات تمثيل KMI أو قوائم رموز KMI أو gki_defconfig
أو نصوص برمجية أو إعدادات أو نصوص برمجية أخرى غير متوفرة في المصدر.
الوحدات النمطية غير المضمّنة في الشجرة
يُثني نظام التشغيل Linux الأساسي بشدة عن إتاحة إنشاء وحدات خارج الشجرة. وهذا موقف منطقي لأنّ المشرفين على Linux لا يقدّمون ضمانات بشأن توافق المصدر أو الرمز الثنائي داخل النواة، ولا يريدون دعم الرموز غير المتوفرة في الشجرة. ومع ذلك، توفّر GKI ضمانات توافق واجهة التطبيق الثنائية (ABI) لوحدات المورّد، ما يضمن ثبات واجهات KMI طوال فترة الدعم المحدّدة لنواة النظام. لذلك، هناك فئة من التغييرات التي تتيح استخدام وحدات المورّد، وهي مقبولة في ACK ولكنها غير مقبولة في المصدر.
على سبيل المثال، لنفترض أنّ هناك تصحيحًا يضيف وحدات ماكرو EXPORT_SYMBOL_GPL()
حيث لا تكون الوحدات التي تستخدم التصدير في شجرة المصدر. مع أنّه عليك محاولة طلب EXPORT_SYMBOL_GPL()
في المصدر وتوفير وحدة تستخدم الرمز الذي تم تصديره حديثًا، يمكنك إرسال التصحيح إلى ACK بدلاً من ذلك إذا كان هناك مبرّر صالح لعدم إرسال الوحدة إلى المصدر. يجب تضمين مبرّر لعدم إمكانية نقل الوحدة إلى الإصدارات الأحدث في المشكلة. (لا تطلب الصيغة غير المتوافقة مع GPL، EXPORT_SYMBOL()
.)
الإعدادات المخفية
تختار بعض الوحدات النمطية داخل الشجرة تلقائيًا إعدادات مخفية لا يمكن تحديدها في gki_defconfig
. على سبيل المثال، يتم اختيار CONFIG_SND_SOC_TOPOLOGY
تلقائيًا عند ضبط CONFIG_SND_SOC_SOF=y
. لتوفير إمكانية إنشاء وحدات خارج شجرة المصدر، تتضمّن صورة النواة العامة (GKI) آلية لتفعيل الإعدادات المخفية.
لتفعيل إعداد مخفي، أضِف عبارة select
في init/Kconfig.gki
ليتم اختيارها تلقائيًا استنادًا إلى إعدادات نواة CONFIG_GKI_HACKS_TO_FIX
، والتي يتم تفعيلها في gki_defconfig
. لا تستخدِم هذه الآلية إلا للإعدادات المخفية،
وإذا لم يكن الإعداد مخفيًا، يجب تحديده في gki_defconfig
إما
بشكل صريح أو كعنصر تابع.
المحافظات التي يمكن تحميلها
بالنسبة إلى أُطر عمل النواة (مثل cpufreq
) التي تتيح استخدام أدوات تحكّم قابلة للتحميل، يمكنك تجاهل أداة التحكّم التلقائية (مثل أداة التحكّم schedutil
في cpufreq
). بالنسبة إلى الأُطر (مثل إطار العمل الحراري) التي لا تتوافق مع أدوات التحكم أو برامج التشغيل القابلة للتحميل ولكنها لا تزال تتطلّب تنفيذًا خاصًا بالمورّد، يمكنك إنشاء مشكلة في قسم تكنولوجيا المعلومات والتواصل مع فريق نواة Android.
وسنتعاون معك ومع المشرفين على الإصدارات السابقة لإضافة الدعم اللازم.
عمليات دمج المورّدين
في الإصدارات السابقة، كان بإمكانك إضافة تعديلات خاصة بمورّد معيّن مباشرةً إلى النواة الأساسية. لا يمكن إجراء ذلك باستخدام GKI 2.0 لأنّه يجب تنفيذ الرمز الخاص بالمنتج في الوحدات، ولن يتم قبوله في النواة الأساسية أو في ACK. لإتاحة ميزات ذات قيمة مضافة يعتمد عليها الشركاء بأقل تأثير ممكن في رمز النواة الأساسي، تقبل GKI خطافات المورّد التي تسمح باستدعاء الوحدات من رمز النواة الأساسي. بالإضافة إلى ذلك، يمكن إضافة حقول بيانات خاصة بالمورّدين إلى بنى البيانات الرئيسية، وهي حقول متاحة لتخزين بيانات خاصة بالمورّدين من أجل تنفيذ هذه الميزات.
تتوفّر خطافات المورّد بنوعَين (عادي ومقيّد) يستندان إلى نقاط التتبُّع (وليس أحداث التتبُّع) التي يمكن لوحدات المورّد ربطها. على سبيل المثال، بدلاً من إضافة وظيفة sched_exit()
جديدة لإجراء محاسبة عند الخروج من مهمة، يمكن للمورّدين إضافة خطاف في do_exit()
يمكن لوحدة المورّد ربطها للمعالجة. يتضمّن مثال التنفيذ خطافات المورّد التالية.
- تستخدِم خطافات المورّد العادية
DECLARE_HOOK()
لإنشاء دالة نقطة تتبُّع بالاسمtrace_name
حيثname
هو المعرّف الفريد للتتبُّع. وفقًا للاتفاقية، تبدأ أسماء دوال ربط المورّد العادية بـandroid_vh
، لذا سيكون اسم دالة الربطsched_exit()
هوandroid_vh_sched_exit
. - تكون خطافات المورّد المقيدة مطلوبة في حالات مثل خطافات المجدول حيث يجب استدعاء الدالة المرفقة حتى إذا كان وحدة المعالجة المركزية غير متصلة بالإنترنت أو تتطلب سياقًا غير ذري. لا يمكن فصل خطافات المورّدين المحظورة، وبالتالي لا يمكن أبدًا إلغاء تحميل الوحدات التي تتصل بخطاف محظور. تبدأ أسماء دوال ربط المورّدين المحظورة بالرمز
android_rvh
.
لإضافة دالة ربط خاصة بمورّد، سجِّل مشكلة في قسم تكنولوجيا المعلومات وأرسِل تصحيحات (كما هو الحال مع جميع التصحيحات الخاصة بنظام Android، يجب أن تكون هناك مشكلة ويجب تقديم مبرّر). تتوفّر خطافات المورّدين في ACK فقط، لذا لا ترسِل هذه الحِزم إلى Linux الأساسي.
إضافة حقول المورّد إلى البُنى
يمكنك ربط بيانات المورّد ببُنى البيانات الرئيسية عن طريق إضافة حقول android_vendor_data
باستخدام وحدات ماكرو ANDROID_VENDOR_DATA()
. على سبيل المثال، لدعم الميزات ذات القيمة المضافة، ألحِق الحقول بالبُنى كما هو موضّح في نموذج الرمز التالي.
لتجنُّب التعارضات المحتملة بين الحقول التي يحتاجها المورّدون والحقول التي يحتاجها المصنّعون الأصليون للأجهزة، يجب ألا يستخدم المصنّعون الأصليون للأجهزة الحقول التي تم تعريفها باستخدام وحدات ماكرو ANDROID_VENDOR_DATA()
. بدلاً من ذلك، يجب أن يستخدم المصنّعون الأصليون للأجهزة 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()
، ثم أضِفها إلى الرمز كنقطة تتبُّع. على سبيل المثال، لإضافة trace_android_vh_sched_exit()
إلى دالة النواة do_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()
، سيتم استدعاء الدالة المسجَّلة. يجب أن يكون المعالج على دراية بالسياق المتعلق بعمليات الإغلاق المعلقة وحالة RCS وعوامل أخرى. يجب تحديد الخطاف في ملف رأس ضمن الدليل include/trace/hooks
.
على سبيل المثال، تقدّم التعليمة البرمجية التالية تعريفًا محتملاً لـ trace_android_vh_sched_exit()
في الملف include/trace/hooks/exit.h
.
/* 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);
ملاحظة: يجب تحديد بنى البيانات المستخدَمة في تعريف الخطاف بشكل كامل لضمان ثبات واجهة التطبيق الثنائية (ABI). وفي ما عدا ذلك، لا يمكن إلغاء الإشارة إلى المؤشرات غير الشفافة أو استخدام البنية في سياقات ذات حجم محدد. يجب أن يكون ملف include الذي يقدّم التعريف الكامل لبُنى البيانات هذه ضِمن القسم #ifndef __GENKSYMS__
من drivers/android/vendor_hooks.c
. يجب ألا تتضمّن ملفات العناوين في include/trace/hooks
ملف عنوان النواة الذي يتضمّن تعريفات الأنواع لتجنُّب تغييرات CRC التي تؤدي إلى تعطيل واجهة KMI. بدلاً من ذلك، عليك تعريف الأنواع مسبقًا.
الربط بخطافات البائع
لاستخدام خطافات المورّد، يجب أن يسجّل وحدة المورّد معالجًا للخطاف
(يتم ذلك عادةً أثناء تهيئة الوحدة). على سبيل المثال، يعرض الرمز التالي معالج الوحدة foo.ko
لـ trace_android_vh_sched_exit()
.
#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);
...
}
استخدام خطافات المورِّد من ملفات العناوين
لاستخدام خطافات المورّد من ملفات العناوين، قد تحتاج إلى تعديل ملف عنوان خطاف المورّد لإلغاء تعريف TRACE_INCLUDE_PATH
لتجنُّب أخطاء الإنشاء التي تشير إلى تعذُّر العثور على ملف عنوان نقطة التتبُّع. على سبيل المثال:
In file included from .../common/init/main.c:111:
In file included from .../common/include/trace/events/initcall.h:74:
.../common/include/trace/define_trace.h:95:10: fatal error: 'trace/hooks/initcall.h' file not found
95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:90:32: note: expanded from macro 'TRACE_INCLUDE'
90 | # define TRACE_INCLUDE(system) __TRACE_INCLUDE(system)
| ^~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:87:34: note: expanded from macro '__TRACE_INCLUDE'
87 | # define __TRACE_INCLUDE(system) __stringify(TRACE_INCLUDE_PATH/system.h)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:10:27: note: expanded from macro '__stringify'
10 | #define __stringify(x...) __stringify_1(x)
| ^~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:9:29: note: expanded from macro '__stringify_1'
9 | #define __stringify_1(x...) #x
| ^~
<scratch space>:14:1: note: expanded from here
14 | "trace/hooks/initcall.h"
| ^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
لإصلاح هذا النوع من أخطاء الإنشاء، طبِّق الحلّ المكافئ على ملف عنوان vendor hook الذي يتضمّنه التطبيق. لمزيد من المعلومات، يُرجى الرجوع إلى https://r.android.com/3066703.
diff --git a/include/trace/hooks/mm.h b/include/trace/hooks/mm.h
index bc6de7e53d66..039926f7701d 100644
--- a/include/trace/hooks/mm.h
+++ b/include/trace/hooks/mm.h
@@ -2,7 +2,10 @@
#undef TRACE_SYSTEM
#define TRACE_SYSTEM mm
+#ifdef CREATE_TRACE_POINTS
#define TRACE_INCLUDE_PATH trace/hooks
+#define UNDEF_TRACE_INCLUDE_PATH
+#endif
يؤدي تحديد UNDEF_TRACE_INCLUDE_PATH
إلى توجيه include/trace/define_trace.h
لإلغاء تعريف TRACE_INCLUDE_PATH
بعد إنشاء نقاط التتبُّع.
ميزات النواة الأساسية
إذا لم تتمكّن من تنفيذ ميزة من وحدة باستخدام أي من الأساليب السابقة، عليك إضافة الميزة كتعديل خاص بنظام Android إلى النواة الأساسية. أنشئ مشكلة في أداة تتبُّع المشاكل (IT) لبدء المحادثة.
واجهة برمجة تطبيقات المستخدم (UAPI)
- ملفات عناوين UAPI يجب إجراء التغييرات على ملفات عناوين UAPI في المصدر الرئيسي إلا إذا كانت التغييرات على واجهات خاصة بنظام Android. استخدِم ملفات العناوين الخاصة بالمورّد لتحديد الواجهات بين وحدات المورّد ورمز مساحة المستخدم الخاص بالمورّد.
- عُقد sysfs: لا تُضِف عُقد sysfs جديدة إلى نواة GKI (لا تكون هذه الإضافات صالحة إلا في وحدات المورّد). ولا يمكن تغيير عُقد sysfs التي تستخدمها المكتبات ورموز Java البرمجية التي لا تعتمد على النظام على الشريحة (SoC) والجهاز والتي تشكّل إطار عمل Android إلا بطرق متوافقة، ويجب تغييرها في المصدر إذا لم تكن عُقد sysfs خاصة بنظام Android. يمكنك إنشاء عُقد sysfs خاصة بالمورّد ليستخدمها مساحة المستخدم الخاصة بالمورّد. يتم تلقائيًا رفض وصول مساحة المستخدم إلى عقد sysfs باستخدام SELinux. ويعود إلى المورّد إضافة تصنيفات SELinux المناسبة للسماح بالوصول إلى برامج المورّد المصرّح بها.
- عُقد DebugFS: يمكن لوحدات المورّد تحديد العُقد في
debugfs
لأغراض تصحيح الأخطاء فقط (لأنّه لا يتم تحميلdebugfs
أثناء التشغيل العادي للجهاز).