تطوير رمز النواة لبرنامج GKI

تعمل "صورة النواة العامة" (GKI) على تقليل تجزئة النواة من خلال المواءمة بشكل وثيق مع نواة Linux الأساسية. ومع ذلك، هناك أسباب وجيهة وراء حيث لا يمكن قبول بعض التصحيحات الأولية، وهناك جداول زمنية للمنتجات حتى يتم الاحتفاظ ببعض التصحيحات في النواة المشتركة لنظام التشغيل Android (ACK). المصادر التي تم إنشاء GKI منها.

على المطوّرين إرسال تغييرات الرموز البرمجية قبل بدء العملية باستخدام Linux Kernel Mailing إدراج (LKML) كالخيار الأول، وإرسال تغييرات الرمز إلى ACK يتفرع android-mainline فقط عندما يكون هناك سبب وجيه لعدم تلبية الإعلان الرئيسي. قابلة للتطبيق. في ما يلي أمثلة على الأسباب الصالحة وكيفية التعامل معها.

  • تم إرسال الإصلاح إلى LKML، ولكن لم يتم قبوله في الوقت المناسب لطرح المنتج . لمعالجة رمز التصحيح هذا:

    • قدِّم دليلاً على إرسال رمز التصحيح إلى LKML والتعليقات. المستلمة لكل لاصقة، أو الوقت المقدر الذي يتم فيه وضع اللاصقة تم إرساله قبل تحميله.
    • عليك تحديد مسار العمل لطرح التصحيح في ACK والحصول على الموافقة عليه في قناة الإصدار العلني، ثمّ إزالته من ACK عند دمج الإصدار النهائي من قناة الإصدار العلني في ACK.

  • تحدّد رمز التصحيح EXPORT_SYMBOLS_GPL() لوحدة المورّد، ولكن تعذَّر عليه قبل إطلاقها؛ نظرًا لعدم وجود وحدات شجرة تستخدم الرمز. للتعامل مع رمز التصحيح هذا، يُرجى تقديم تفاصيل عن سبب تعذّر تضمين الوحدة. التي تم إرسالها مسبقًا والبدائل التي فكرت فيها قبل اتخاذ هذا طلبك.

  • لا يكون التصحيح عامًا بما يكفي للاستخدام في الإصدارات السابقة، ولا يتوفّر الوقت لإعادة تحليله قبل إصدار المنتج. لمعالجة هذا التصحيح، يُرجى تقديم وقت مقدَّر لإرسال تصحيح مُعاد تنظيمه إلى الإصدار العلني (لن يتم قبول التصحيح في ACK بدون خطة لإرسال تصحيح مُعاد تنظيمه إلى الإصدار العلني للمراجعة).

  • لا يمكن قبول رمز التصحيح من خلال استلام الطلب بسبب... <إدراج السبب هنا>. لمعالجة رمز التصحيح هذا، يُرجى التواصل مع فريق نواة Android تعاون معنا بشأن خيارات إعادة ضبط التصحيح حتى يمكن إرساله. للمراجعة وقبول التنفيذ.

هناك الكثير من المبررات المحتملة الأخرى. عند إرسال الخطأ أو فقم بتضمين مبرر صالح وتوقع بعض التكرار والمناقشة. ندرك أنّ ACK يتضمّن بعض التعديلات، خاصةً في المراحل المبكرة من GKI عندما يتعلم الجميع كيفية العمل على الإصدارات العلنية، ولكن لا يمكنهم تخفيف جداول المنتجات لإجراء ذلك. نتوقع أن تصبح متطلبات الإصدارات العلنية أكثر صرامة بمرور الوقت.

متطلبات رمز التصحيح

يجب أن تتوافق رموز التصحيح مع معايير ترميز نواة Linux الموضحة في شجرة مصدر Linux، سواء تم إرسالها قبل الإرسال أو إلى ACK. scripts/checkpatch.pl تنفيذ النص البرمجي كجزء من اختبار الإرسال المسبق لـ Gerrit، لذا قم بتشغيله مسبقًا التأكد من اجتيازه. لتشغيل البرنامج النصي checkpatch بالإعدادات نفسها المستخدَمة في اختبار presubmit، استخدِم //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 المستنِد إلى الإصدار الثابت طويل الأمد. تشمل الاستثناءات الحالات التي يتم فيها نقل تصحيح في الإصدار الأحدث إلى الإصدار 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 على كل من مجموعة التجربة 64. الإصدارات x86 ما لم تكن CONFIG خاصة بالبنية. لطلب إجراء تغيير في إعدادات CONFIG، أنشئ مشكلة في قسم تكنولوجيا المعلومات لمناقشة التغيير. يتم رفض أي CONFIG تغيير يؤثر في واجهة وحدة المعالجة الأساسية (KMI) بعد تجميدها. في الحالات التي يطلب فيها الشركاء التعارض لإعداد واحد، يمكننا حل التعارضات من خلال المناقشة على الأخطاء ذات الصلة.

رمز برمجي غير متوفّر للتحميل

لا يمكن إرسال التعديلات على الرمز البرمجي المخصّص لنظام التشغيل Android إلى المصدر. على سبيل المثال، على الرغم من أنّ برنامج تشغيل أداة الربط يتم الاحتفاظ به في المصدر، لا يمكن إرسال التعديلات على ميزات اكتساب الأولوية في برنامج تشغيل أداة الربط إلى المصدر لأنّها خاصة بنظام Android. يجب أن يكون وصف الخطأ والإصلاح واضحًا بشأن سبب عدم إمكانية إرسال الرمز البرمجي إلى فريق التطوير. إذا أمكن، قسِّم التصحيحات إلى أجزاء يمكن إرساله قبل بدء البث وأجزاء معيّنة خاصة بنظام التشغيل Android لا يمكن إرسالها قبل التنفيذ لتقليل مقدار الرموز خارج الشجرة التي تم الاحتفاظ بها في ACK.

تشمل التغييرات الأخرى في هذه الفئة تعديلات على ملفات تمثيل KMI، وKMI. قوائم الرموز أو gki_defconfig أو إنشاء نصوص برمجية أو إعدادات أو نصوص برمجية أخرى غير الموجودة مسبقًا.

الوحدات خارج الشجرة

لا ينصح فريق Linux Upstream بدعم إنشاء وحدات خارج الشجرة. هذا موقفًا معقولاً لأنّ مسؤولي إدارة نظام Linux لا يقدّمون أي ضمانات المصدر داخل النواة أو التوافق الثنائي ولا يريدون دعم التعليمات البرمجية غير الموجودة في الشجرة. ومع ذلك، يقدّم GKI ضمانات ABI ل وحدات المورّدين، ما يضمن ثبات واجهات KMI خلال مدة استخدام النواة المتوافقة. لذلك، هناك فئة من التغييرات لتوفير وحدات المورّدين المقبولة في ACK ولكنّها غير مقبولة في المصدر.

على سبيل المثال، نأخذ تصحيحًا يضيف وحدات ماكرو EXPORT_SYMBOL_GPL() حيث تكون الوحدات التي تستخدِم التصدير غير مضمّنة في شجرة المصدر. بينما يجب أن تحاول لطلب تحميل "EXPORT_SYMBOL_GPL()" وتوفير وحدة تستخدم تم تصديره حديثًا، إذا كان هناك مبرر صالح لسبب ما لا يتم إرساله قبل بدء عملية النقل، يمكنك إرسال رمز التصحيح إلى ACK بدلاً منه. إِنْتَ تحتاج إلى تضمين مبررات سبب عدم إمكانية بث الوحدة في المشكلة. (لا تطلب إصدار EXPORT_SYMBOL() غير المتوافق مع GPL.)

الإعدادات المخفية

تختار بعض الوحدات النمطية تلقائيًا الإعدادات المخفية التي لا يمكن تحديدها في 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، يجب ألا يتضمن ملف رأس النواة kernel مع ونكتب التعريفات لتجنب تغييرات 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.

لإصلاح هذا النوع من أخطاء الإنشاء، طبِّق الإصلاح المكافئ على ملف header الذي يتضمّن رمز الربط الخاص بالمورّد. لمزيد من المعلومات، يُرجى الرجوع إلى 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: يجب إجراء التغييرات على ملفات رؤوس واجهة برمجة التطبيقات لنظام التشغيل Android في المصدر، ما لم تكن التغييرات على واجهات خاصة بنظام التشغيل Android. استخدام ملفات رؤوس خاصة بالمورّد لتحديد الواجهات بين وحدات المورد ورمز مساحة المستخدم للبائع.
  • عقد sysfs لا تُضِف عقد sysfs جديدة إلى نواة GKI (لا تكون هذه الإضافات válida إلا في وحدات المورّدين). لا يمكن تغيير عقد sysfs التي تستخدمها المكتبات التي لا تعتمد على وحدة المعالجة المركزية والأجهزة ورمز Java الذي يشكّل إطار عمل Android إلا بطرق متوافقة، ويجب تغييرها في المصدر إذا كانت ليست عقد sysfs خاصة بنظام Android. يمكنك إنشاء عُقد sysfs الخاصة بالبائع لاستخدامها بواسطة مساحة المستخدم للمورّد. بشكل افتراضي، تم رفض الوصول إلى عُقد sysfs من خلال مساحة المستخدم باستخدام SELinux. على العميل إضافة تصنيفات SELinux المناسبة للسماح بالوصول من خلال برامج العميل المعتمَدة.
  • عُقد DebugFS يمكن أن تحدِّد وحدات المورّدين العقد في debugfs ل debugging فقط (لأنّ debugfs لا يتم تثبيته أثناء التشغيل العادي ل الجهاز).