تتطور مكتبات Android المشتركة من وقت لآخر. يتطلب الحفاظ على تحديث الثنائيات المعدة مسبقًا جهدًا كبيرًا. في نظام التشغيل Android 9 أو الإصدارات الأقدم، تفشل الثنائيات المنشأة مسبقًا والتي تعتمد على المكتبات أو واجهات ABI المحذوفة في الارتباط في وقت التشغيل فقط. يتعين على المطورين تتبع السجلات للعثور على الثنائيات القديمة التي تم إنشاؤها مسبقًا. في Android 10، تم تقديم مدقق استخدامات ABI القائم على الرموز. يمكن للمدقق اكتشاف الثنائيات القديمة التي تم إنشاؤها مسبقًا في وقت الإنشاء، بحيث يمكن لمطوري المكتبات المشتركة معرفة الثنائيات التي تم إنشاؤها مسبقًا والتي قد يتم كسرها بسبب تغييرها وأي الثنائيات التي تم إنشاؤها مسبقًا يجب إعادة بنائها.
مدقق استخدامات ABI القائم على الرمز
يحاكي مدقق استخدامات ABI القائم على الرمز رابط Android الديناميكي على المضيف. يقوم المدقق بربط الملف الثنائي الذي تم إنشاؤه مسبقًا مع تبعيات الملف الثنائي الذي تم إنشاؤه مسبقًا ويتحقق مما إذا كان قد تم حل جميع الرموز غير المحددة.
أولاً، يقوم المدقق بفحص البنية المستهدفة للثنائي الذي تم إنشاؤه مسبقًا. إذا كان الملف الثنائي المُنشأ مسبقًا لا يستهدف بنية ARM أو AArch64 أو x86 أو x86-64، فسيتخطى المدقق الثنائي المُنشأ مسبقًا.
ثانيًا، يجب إدراج تبعيات الملف الثنائي المُنشأ مسبقًا في LOCAL_SHARED_LIBRARIES أو shared_libs . يقوم نظام البناء بتحليل أسماء الوحدات النمطية إلى المتغير المطابق (أي core مقابل vendor ) للمكتبات المشتركة.
ثالثًا، يقوم المدقق بمقارنة إدخالات DT_NEEDED بـ LOCAL_SHARED_LIBRARIES أو shared_libs . على وجه الخصوص، يقوم المدقق باستخراج إدخال DT_SONAME من كل مكتبات مشتركة ومقارنة DT_SONAME بإدخالات DT_NEEDED المسجلة في الملف الثنائي الذي تم إنشاؤه مسبقًا. إذا كان هناك عدم تطابق، يتم إصدار رسالة خطأ.
رابعًا، يقوم المدقق بتحليل الرموز غير المحددة في الملف الثنائي الذي تم إنشاؤه مسبقًا. يجب تعريف هذه الرموز غير المحددة في إحدى التبعيات ويجب أن يكون ربط الرمز إما GLOBAL أو WEAK . إذا تعذر حل رمز غير محدد، فسيتم إصدار رسالة خطأ.
خصائص الوحدة النمطية المبنية مسبقًا
يجب تحديد تبعيات الملف الثنائي الذي تم إنشاؤه مسبقًا في أحد الإجراءات التالية:
- Android.bp:
shared_libs: ["libc", "libdl", "libm"], - Android.mk:
LOCAL_SHARED_LIBRARIES := libc libdl libm
إذا تم تصميم الملف الثنائي الذي تم إنشاؤه مسبقًا ليحتوي على بعض الرموز غير المحددة غير القابلة للحل ، فحدد واحدًا مما يلي:
- Android.bp:
allow_undefined_symbols: true, - Android.mk:
LOCAL_ALLOW_UNDEFINED_SYMBOLS := true
لكي يتمكن الثنائي المُنشأ مسبقًا من تخطي فحص ملف ELF، حدد واحدًا مما يلي:
- Android.bp:
check_elf_files: false, - Android.mk:
LOCAL_CHECK_ELF_FILES := false
قم بتشغيل المدقق
يغطي المدقق جميع وحدات ELF المعدة مسبقًا أثناء عملية إنشاء Android.
لتشغيل المدقق وحده لتحقيق أوقات استجابة أسرع:
m check-elf-files
أداة إصلاح أخطاء ABI
يمكن أن يساعد المثبت التلقائي في حل أخطاء فحص ABI. ما عليك سوى تشغيل المثبت باستخدام Android.bp / Android.mk كمدخل، وسيقوم المثبت بطباعة الإصلاح المقترح إلى stdout. اختياريًا، قم بتشغيل المثبت باستخدام خيار --in-place لتحديث Android.bp / Android.mk مباشرة بالإصلاح المقترح.
لنظام Android.bp،
m fix_android_bp_prebuilt# Print the fixed Android.bp to stdout.fix_android_bp_prebuilt <path-to-Android.bp># Update the Android.bp in place.fix_android_bp_prebuilt --in-place <path-to-Android.bp>
بالنسبة إلى Android.mk،
m fix_android_mk_prebuilt# Print the fixed Android.mk to stdout.fix_android_mk_prebuilt <path-to-Android.mk># Update the Android.mk in place.fix_android_mk_prebuilt --in-place <path-to-Android.mk>