اعتبارًا من عام 2026، ولضمان توافقنا مع نموذج التطوير الثابت الرئيسي وضمان استقرار المنصة في المنظومة المتكاملة، سننشر الرمز المصدري في "مشروع Android مفتوح المصدر" (AOSP) في الربع الثاني والربع الرابع. لإنشاء AOSP والمساهمة فيه، ننصحك باستخدام android-latest-release بدلاً من aosp-main. سيشير فرع البيان android-latest-release دائمًا إلى أحدث إصدار تم إرساله إلى AOSP. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في مشروع Android المفتوح المصدر (AOSP).

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

تم إرسال رمز التصحيح إلى "القائمة البريدية لنواة Linux"، ولكن لم يتم قبوله في الوقت المناسب لإصدار منتج. للتعامل مع رمز التصحيح هذا:
- قدِّم دليلًا على أنّه تم إرسال رمز التصحيح إلى "القائمة البريدية لنواة Linux" والتعليقات التي تم تلقّيها بشأنه، أو وقتًا تقديريًا لإرسال رمز التصحيح إلى النواة الأساسية.
- حدِّد إجراءً لإضافة رمز التصحيح إلى "نواة Android الشائعة" والحصول على الموافقة عليه في النواة الأساسية، ثم إزالته من "نواة Android الشائعة" عند دمج الإصدار النهائي من النواة الأساسية في "نواة Android الشائعة".
يحدّد رمز التصحيح EXPORT_SYMBOLS_GPL() لوحدة مورّد، ولكن تعذّر إرساله إلى النواة الأساسية لأنّه لا توجد وحدات ضمن الشجرة تستخدم هذا الرمز. للتعامل مع رمز التصحيح هذا، قدِّم تفاصيل حول سبب عدم إمكانية إرسال وحدتك إلى النواة الأساسية والبدائل التي أخذتها في الاعتبار قبل تقديم هذا الطلب.
رمز التصحيح ليس عامًا بما يكفي للنواة الأساسية وليس هناك وقت لإعادة هيكلته قبل إصدار منتج. للتعامل مع رمز التصحيح هذا، قدِّم وقتًا تقديريًا لإرسال رمز تصحيح تمت إعادة هيكلته إلى النواة الأساسية (لن يتم قبول رمز التصحيح في "نواة Android الشائعة" بدون خطة لإرسال رمز تصحيح تمت إعادة هيكلته إلى النواة الأساسية للمراجعة).
لا يمكن للنواة الأساسية قبول رمز التصحيح بسبب... <أدخِل السبب هنا>. للتعامل مع رمز التصحيح هذا، تواصَل مع فريق نواة Android وتعاوَن معنا بشأن خيارات إعادة هيكلة رمز التصحيح لكي يمكن إرساله للمراجعة وقبوله في النواة الأساسية.

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

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

يجب أن تتوافق رموز التصحيح مع معايير ترميز نواة Linux الموضّحة في شجرة مصدر Linux، سواء تم إرسالها إلى النواة الأساسية أو إلى "نواة Android الشائعة". يتم تشغيل النص البرمجي scripts/checkpatch.pl كجزء من اختبارات الإرسال المسبق في Gerrit، لذا شغِّله مسبقًا للتأكّد من اجتيازه. لتشغيل النص البرمجي checkpatch بنفس الإعدادات المستخدَمة في اختبارات الإرسال المسبق، استخدِم //build/kernel/static_analysis:checkpatch_presubmit. لمزيد من التفاصيل، اطّلِع على build/kernel/kleaf/docs/checkpatch.md.

رموز التصحيح في "نواة Android الشائعة"

يجب أن تتوافق رموز التصحيح المُرسَلة إلى "نواة Android الشائعة" مع معايير ترميز نواة Linux و إرشادات المساهمة. يجب تضمين علامة Change-Id في رسالة الالتزام. إذا أرسلت رمز التصحيح إلى فروع متعددة (مثل android-mainline وandroid12-5.4)، يجب استخدام Change-Id نفسه لجميع مثيلات رمز التصحيح.

أرسِل رموز التصحيح إلى "القائمة البريدية لنواة Linux" أولاً لإجراء مراجعة في النواة الأساسية. إذا كان رمز التصحيح:

مقبولاً في النواة الأساسية، يتم دمجه تلقائيًا في android-mainline.
غير مقبول في النواة الأساسية، أرسِله إلى android-mainline مع الإشارة إلى الإرسال إلى النواة الأساسية أو تقديم تفسير لسبب عدم إرساله إلى "القائمة البريدية لنواة Linux".

بعد قبول رمز التصحيح في النواة الأساسية أو في android-mainline، يمكن نقله إلى الإصدارات السابقة من "نواة Android الشائعة" المستندة إلى الإصدارات الطويلة الأمد (مثل android12-5.4 وandroid11-5.4 لرموز التصحيح التي تُصلِح الرموز الخاصة بنظام Android). يؤدي الإرسال إلى android-mainline إلى إتاحة الاختبار باستخدام الإصدارات التجريبية الجديدة من النواة الأساسية ويضمن تضمين رمز التصحيح في الإصدار التالي من "نواة Android الشائعة" المستندة إلى الإصدارات الطويلة الأمد. تشمل الاستثناءات الحالات التي يتم فيها نقل رمز تصحيح من النواة الأساسية إلى الإصدارات السابقة من android12-5.4 (لأنّ رمز التصحيح من المحتمل أن يكون موجودًا في android-mainline).

رموز التصحيح في النواة الأساسية

كما هو موضّح في إرشادات المساهمة، تنقسم رموز التصحيح في النواة الأساسية المخصّصة لنواة "نواة Android الشائعة" إلى المجموعات التالية (مدرَجة حسب احتمالية قبولها).

UPSTREAM: - من المحتمل أن يتم قبول رموز التصحيح التي تم اختيارها من 'android-mainline` في "نواة Android الشائعة" إذا كانت هناك حالة استخدام منطقية.
BACKPORT: - من المحتمل أيضًا أن يتم قبول رموز التصحيح من النواة الأساسية التي لا يمكن اختيارها بشكل نظيف وتحتاج إلى تعديل إذا كانت هناك حالة استخدام منطقية.
FROMGIT: - قد يتم قبول رموز التصحيح التي تم اختيارها من فرع مسؤول الصيانة استعدادًا لإرسالها إلى النواة الأساسية في Linux إذا كان هناك موعد نهائي قادم. يجب تبرير هذه الرموز من حيث المحتوى والجدول الزمني.
FROMLIST: - من غير المحتمل أن يتم قبول رموز التصحيح التي تم إرسالها إلى "القائمة البريدية لنواة Linux" ولكن لم يتم قبولها في فرع مسؤول الصيانة بعد، ما لم يكن المبرّر مقنعًا بما يكفي لقبول رمز التصحيح سواء تم إدراجه في النواة الأساسية في Linux أم لا (نفترض أنّه لن يتم إدراجه). يجب أن تكون هناك مشكلة مرتبطة برموز التصحيح FROMLIST لتسهيل المناقشة مع فريق نواة Android.

رموز التصحيح الخاصة بنظام Android

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

التغييرات في gki_defconfig

يجب تطبيق جميع تغييرات CONFIG على gki_defconfig على كلٍّ من إصدارَي arm64 وx86 ما لم يكن CONFIG خاصًا ببنية معيّنة. لطلب تغيير في إعداد CONFIG، أنشئ مشكلة في نظام تتبُّع المشاكل لمناقشة التغيير. سيتم رفض أي تغيير في CONFIG يؤثّر في واجهة وحدة النواة (KMI) بعد تجميدها. في الحالات التي يطلب فيها الشركاء إعدادات متعارضة لإعداد واحد، نحلّ النزاعات من خلال المناقشة بشأن الأخطاء ذات الصلة.

الرموز غير المتوفّرة في النواة الأساسية

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

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

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

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

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

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

تختار بعض الوحدات ضمن الشجرة تلقائيًا إعدادات مخفية لا يمكن تحديدها في gki_defconfig. على سبيل المثال، يتم اختيار CONFIG_SND_SOC_TOPOLOGY تلقائيًا عند ضبط CONFIG_SND_SOC_SOF=y. لاستيعاب إنشاء الوحدات خارج الشجرة، تتضمّن "صورة النواة العامة" آلية لتفعيل الإعدادات المخفية.

لتفعيل إعداد مخفي، أضِف عبارة select في init/Kconfig.gki ليتم اختيارها تلقائيًا استنادًا إلى إعداد النواة CONFIG_GKI_HACKS_TO_FIX، الذي يتم تفعيله في gki_defconfig. استخدِم هذه الآلية للإعدادات المخفية فقط. إذا لم يكن الإعداد مخفيًا، يجب تحديده في gki_defconfig بشكل صريح أو كإعداد تابع.

المحافِظون القابلون للتحميل

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

سنتعاون معك ومع مسؤولي صيانة النواة الأساسية لإضافة الدعم اللازم.

الروابط الخاصة بالمورّد

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

تتوفّر الروابط الخاصة بالمورّد في إصدارَين (عادي ومقيّد) يستندان إلى نقاط التتبُّع (وليس أحداث التتبُّع) التي يمكن لوحدات المورّد إرفاقها. على سبيل المثال، بدلاً من إضافة دالة sched_exit() جديدة لإجراء عملية محاسبة عند الخروج من المهمة، يمكن للمورّدين إضافة رابط في do_exit() يمكن لوحدة مورّد إرفاقه للمعالجة. يتضمّن مثال التنفيذ الروابط الخاصة بالمورّد التالية.

تستخدم الروابط الخاصة بالمورّد العادية DECLARE_HOOK() لإنشاء دالة نقطة تتبُّع بالاسم trace_name حيث name هو المعرّف الفريد للـ تتبُّع. وفقًا للاتفاقية، تبدأ أسماء الروابط الخاصة بالمورّد العادية بـ android_vh، لذا سيكون اسم رابط sched_exit() هو android_vh_sched_exit.
تكون الروابط الخاصة بالمورّد المقيّدة ضرورية في حالات مثل روابط برنامج الجدولة حيث يجب استدعاء الدالة المرفقة حتى إذا كانت وحدة المعالجة المركزية غير متصلة بالإنترنت أو تتطلّب سياقًا غير ذري. لا يمكن فصل الروابط الخاصة بالمورّد المقيّدة، لذا لا يمكن أبدًا إلغاء تحميل الوحدات التي يتم إرفاقها برابط مقيّد. تبدأ أسماء الروابط الخاصة بالمورّد المقيّدة بـ android_rvh.

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

الإرفاق بالروابط الخاصة بالمورّد

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

واجهة برمجة التطبيقات للمستخدم (UAPI)

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

تطوير رمز النواة لبرنامج GKI تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.