يصف هذا القسم كيفية إنشاء تمثيلات Android kernel ABI وتشغيل مراقبة ABI. ينطبق على نظام Android 14 والإصدارات الأحدث. بالنسبة للإصدارات الأقدم، يرجى الرجوع إلى إصدارات النواة الأقدم .
راجع أيضًا الوثائق المرجعية لـ Kleaf: دعم مراقبة ABI (GKI) ودعم مراقبة ABI (الجهاز) .
بناء النواة وتمثيل ABI الخاص بها
بعد تنزيل مصادر GKI، قم بتشغيل الأمر التالي لإنشاء نواة GKI وعناصر ABI:
tools/bazel run //common:kernel_aarch64_abi_dist
ينشئ هذا الأمر تمثيل ABI الحالي وينسخه إلى out_abi/kernel_aarch64/dist/abi.stg مع النواة والوحدات النمطية المضمنة.
يمكنك تحديد وسيطات إضافية لأدوات ABI في نهاية الأمر بعد -- . على سبيل المثال، لتغيير وجهة ABI وإنشاء عناصر، يمكنك استخدام خيار --dist_dir :
tools/bazel run //common:kernel_aarch64_abi_dist -- --dist_dir=out/dist
تحليل اختلافات ABI بين البناء والتمثيل المرجعي
يقوم الهدف //common:kernel_aarch64_abi_dist ، الذي تم تنفيذه في الأمر أعلاه، بتحليل أي اختلافات في ABI تم العثور عليها بين الإصدار والتمثيل المرجعي الموجود في common/android/abi_gki_aarch64.stg (المحدد في BUILD.bazel ). سيتم طباعة هذه الاختلافات في نهاية البناء، كما هو موضح في المثال التالي:
INFO: From [stg] Comparing Kernel ABI @//common:kernel_aarch64_abi_diff:
INFO: ABI DIFFERENCES HAVE BEEN DETECTED!
يأتي التقرير المطبوع من قطعة البناء الموجودة في out_abi/kernel_aarch64/dist/abi_stgdiff/abi.report.short بالإضافة إلى التقارير بتنسيقات أخرى.
يجب أن تستخدم الأتمتة رمز الخروج الخاص بأمر الإنشاء، والذي سيكون غير صفر إذا تم العثور على اختلافات.
يرجى ملاحظة أن فروع مرحلة التطوير ، بما في ذلك android-mainline ، ليس لها تمثيل مرجعي لـ ABI. وبدون ذلك، لن يتمكن //common:kernel_aarch64_abi_dist من اكتشاف أي اختلافات.
قم بتحديث تمثيل ABI المرجعي
أي تغيير يؤثر على واجهة برمجة تطبيقات kernel، مثل تحديث قائمة الرموز ، يجب أن ينعكس في تمثيل واجهة برمجة التطبيقات المرجعية ( common/android/abi_gki_aarch64.stg ، المحدد في BUILD.bazel ). للقيام بذلك تحتاج إلى تشغيل الأمر التالي:
tools/bazel run //common:kernel_aarch64_abi_update
ينفذ هذا الأمر كل شيء في خطوة تحليل اختلافات واجهة برمجة التطبيقات (ABI) بالإضافة إلى تحديث التمثيل المرجعي في المصادر. يمكن بعد ذلك تحميل ABI المحدث في نفس الالتزام مثل التغيير. يرجى تضمين اختلافات ABI عن التقرير في $DIST_DIR/abi.report.short في رسالة الالتزام.
مراقبة ABI وأهداف الجهاز
تحتاج مراقبة ABI فقط إلى التهيئة لأهداف بناء kernel الأساسية. تكوينات البناء المختلطة (تلك التي تحدد base_kernel ) التي يتم تجميعها مباشرة مع نواة GKI تحتاج فقط إلى إضافة دعم لتتبع قائمة رموز الجهاز . يجب تحديث تعريف ABI باستخدام بنية GKI.
راجع أيضًا الوثائق المرجعية لـ Kleaf: دعم مراقبة ABI (الجهاز) .
إصدارات النواة الأقدم
أندرويد 13
تعليمات البناء هي في الغالب نفس تعليمات Android 14 باستثناء أن تنسيق ABI هو XML وتمثيل ABI المرجعي common/android/abi_gki_aarch64.xml .
أندرويد 12 والإصدارات الأقدم
كما هو الحال في Android 13، تنسيق ABI هو XML.
تستخدم النوى الأقدم build.sh بدلاً من Kleaf. لمراقبة واجهة برمجة التطبيقات (ABI)، يجب عليك استخدام build_abi.sh ، الذي يقبل نفس متغيرات البيئة لتخصيص البنية كـ build.sh . على سبيل المثال:
BUILD_CONFIG=common/build.config.gki.aarch64 build/build_abi.sh
يؤدي هذا إلى إنشاء النواة واستخراج تمثيل ABI في الدليل الفرعي OUT_DIR (الذي يكون out_abi افتراضيًا) ويعادل الهدف //common:kernel_aarch64_abi_dist الخاص بـ Kleaf (راجع إنشاء kernel وABI artifacts ).
يتم تخزين تمثيل ABI المرجعي في android/abi_gki_aarch64.xml كما هو محدد بواسطة متغير ABI_DEFINITION في common/build.config.gki.aarch64 .
إذا كنت بحاجة إلى تحديث تمثيل kernel ABI، فإن الطريقة الأكثر ملاءمة هي استخدام خيارات --update و --print-report :
BUILD_CONFIG=common/build.config.gki.aarch64 build/build_abi.sh --update --print-report
يقوم --print-report بطباعة اختلافات ABI بين الملف كما هو وABI الذي تم إنشاؤه حديثًا.
يقوم خيار --update بالكتابة فوق تمثيل ABI المرجعي. كما يقوم أيضًا بتحديث قائمة الرموز عند استخدام BUILD_CONFIG لجهاز تم تكوين KMI_SYMBOL_LIST عليه.