تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

تطوير رمز النواة (kernel) لـ 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، لذا قم بتشغيله مسبقًا التأكد من اجتيازه. لتشغيل النص البرمجي لتصحيح الأخطاء بنفس إعدادات اختبار الإرسال المسبق، استخدِم //build/kernel/static_analysis:checkpatch_presubmit. للحصول على التفاصيل، يُرجى مراجعة build/kernel/kleaf/docs/checkpatch.md.

قبول التصحيحات

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

رمز برمجي غير متوفّر قبل بيع المنتج

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

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

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

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

على سبيل المثال، ضع في الاعتبار رمز تصحيح يضيف EXPORT_SYMBOL_GPL() من وحدات ماكرو حيث وتكون الوحدات التي تستخدِم عملية التصدير غير مدرَجة في شجرة المصدر. بينما يجب أن تحاول لطلب تحميل "EXPORT_SYMBOL_GPL()" وتوفير وحدة تستخدم تم تصديره حديثًا، إذا كان هناك مبرر صالح لسبب ما لا يتم إرساله قبل بدء عملية النقل، يمكنك إرسال رمز التصحيح إلى ACK بدلاً منه. إِنْتَ تحتاج إلى تضمين مبررات سبب عدم إمكانية بث الوحدة في المشكلة. (لا تطلب صيغة غير متوافقة مع "قائمة المورّدين العالميين"، 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.
يجب استخدام عناصر الجذب المفروض عليها قيود من قِبل المورِّدين في حالات مثل عناصر الجدولة التي يكون فيها ينبغي استدعاء الدالة المرفقة حتى إذا كانت وحدة المعالجة المركزية (CPU) غير متصلة بالإنترنت أو تتطلب سياق غير ذري. لا يمكن فصل عناصر الجذب المفروض عليها قيود من المورِّدين، وبالتالي الوحدات التي تعلّق بعنصر جذب مقيّد لا يمكن إلغاء تحميلها مطلقًا. محدود تبدأ أسماء عناصر الجذب للمورّدين بـ 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). وبخلاف ذلك، يكون غير آمن أو تحديد المؤشرات غير الواضحة أو استخدام البنية في السياقات ذات الحجم. تشمل والذي يوفر التعريف الكامل لهياكل البيانات هذه يجب أن يدخل داخل القسم #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.

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