دعم بُنى 64 بت

يجب أن تتوافق التطبيقات المنشورة على Google Play مع بُنى 64 بت. تؤدي إضافة إصدار 64 بت من تطبيقك إلى تحسين الأداء وإعداده للأجهزة التي تعمل بأجهزة 64 بت فقط.

تضمن الخطوات التالية توافق تطبيقك بنظام 32 بت مع الأجهزة التي تعمل بنظام 64 بت.

تقييم تطبيقك

إذا كان تطبيقك يستخدم فقط رمزًا برمجيًا مكتوبًا بلغة برمجة Java أو بلغة Kotlin، بما في ذلك جميع المكتبات أو حِزم SDK، يعني ذلك أنّ تطبيقك يتوافق مع الأجهزة بالإصدار 64 بت. إذا كان تطبيقك يستخدم أي رمز أصلي أو لم تكن متأكدًا من ذلك، عليك تقييم تطبيقك.

فحص سريع للحالة

انتقِل إلى Play Console واطّلِع على الإصدارات الحالية لمعرفة ما إذا كانت متوافقة.

تعرض أداة Play Console أيضًا تحذيرات تنطبق على مسودات الإصدارات في حال كانت هناك أي مشاكل متعلقة بمتطلبات الإصدار 64 بت. في ما يلي مثال على ذلك.

في حال ظهور تنبيه، راجِع الخطوات التالية لجعل تطبيقك متوافقًا مع الأجهزة التي تعمل بالإصدار 64 بت.

هل يستخدم تطبيقك رمزًا أصليًا؟

يستخدم تطبيقك رمزًا أصليًا في الحالات التالية:

• استخدام أي رمز برمجي C/C++ (أصلي) في تطبيقك
• الروابط التي تتضمن أي مكتبات أصلية تابعة لجهات خارجية
• تم إنشاؤه بواسطة منشئ تطبيقات تابع لجهة خارجية يستخدم مكتبات تطبيقات أصلية.

هل يتضمّن تطبيقك مكتبات 64 بت؟

فحص بنية ملف APK عند إنشاء حزمة APK، يتم حزمها مع أي مكتبات مجمّعة من رموز برمجية أصلية يحتاجها التطبيق. ويتم تخزين المكتبات المجمّعة من رموز برمجية أصلية في مجلدات مختلفة استنادًا إلى ABI. ليس من المطلوب أن يكون تطبيقك متوافقًا مع كل بنية أساسية بإصدار 64 بت، ولكن يجب تضمين بنية أساسية بإصدار 64 بت مع كل بنية أساسية أصلية بإصدار 32 بت توفّرها.

بالنسبة إلى بنية ARM، يمكن الوصول إلى مكتبات إصدار 32 بت من خلال armeabi-v7a. وفي المقابل، يمكن الوصول إلى إصدار 64 بت من خلال arm64-v8a.

بالنسبة إلى بنية x86، ابحث عن x86 لنظام التشغيل 32 بت وx86_64 لنظام التشغيل 64 بت.

تأكَّد من توفّر مكتبات أصلية في كلا المجلدَين. باختصار:

لاحظ أنه استنادًا إلى تطبيقك، قد تكون هناك أو لا توجد مجموعة المكتبات نفسها في كل مجلد. والهدف من ذلك هو ضمان تشغيل تطبيقك بشكل صحيح في بيئة 64 بت فقط.

في الحالات العادية، تحتوي حزمة APK أو الحِزمة التي تم إنشاؤها لكل من البنيتَين المتوافقتَين مع 32 بت و64 بت على مجلدات لكل من معيارَي ABI، وكل منهما يحتوي على مجموعة مقابلة من المكتبات المضمّنة. إذا لم يكن هناك توافق مع الإصدار 64 بت، قد يظهر لك مجلد ABI لنظام التشغيل 32 بت وليس مجلدًا لنظام التشغيل 64 بت.

البحث عن المكتبات المجمّعة من رموز برمجية أصلية باستخدام أداة تحليل ملفات APK

أداة تحليل حِزم APK هي أداة تتيح لك تقييم مختلف الجوانب لحزمة APK تم إنشاؤها. استخدِم هذا الإجراء للعثور على أي مكتبات أصلية والتأكّد من توفّر مكتبات 64 بت.

1. افتح استوديو Android وافتح أي مشروع.

2. من القائمة، اختَر الإنشاء > تحليل حزمة APK.

   

3. اختَر حزمة APK التي تريد تقييمها.

4. ابحث في مجلد lib الذي يستضيف ملفات ‎.so إن توفّرت. إذا لم يكن هناك أي منها، يعني ذلك أنّ تطبيقك متوافق مع الأجهزة التي تعمل بنظام التشغيل 64 بت، وليس عليك اتّخاذ أي إجراء إضافي. إذا ظهر لك armeabi-v7a أو x86، هذا يعني أنّ لديك مكتبات 32 بت.

5. تحقَّق ممّا إذا كانت لديك ملفات ‎.so مشابهة في مجلد arm64-v8a أو x86_64.

   

6. إذا لم يكن لديك أي مكتبات arm64-v8a أو x86_64، عليك تعديل عملية الإنشاء لبدء إنشاء هذه العناصر ووضعها في حزمة APK.

7. إذا كنت ترى أنّه يتم حاليًا تجميع كلتا المكتبتَين، يمكنك التخطّي إلى مرحلة اختبار تطبيقك على أجهزة تعمل بإصدار 64 بت.

يمكنك البحث عن المكتبات المجمّعة من خلال فك ضغط حِزم APK.

يتم تنظيم ملفات APK مثل ملفات zip. استخرِج ملف APK باستخدام سطر الأوامر أو أي أداة دتثبيت أخرى. استنادًا إلى أداة الاستخراج، قد يكون عليك إعادة تسمية الملف إلى ‎ .zip.

تصفَّح الملفات التي تم استخراجها باتّباع الإرشادات أعلاه لتحديد ما إذا كان تطبيقك متوافقًا مع الأجهزة التي تعمل بإصدار 64 بت. يمكنك تنفيذ مثال الأمر التالي من سطر الأوامر:

:: Command Line
> zipinfo -1 YOUR_APK_FILE.apk | grep \.so$
lib/armeabi-v7a/libmain.so
lib/armeabi-v7a/libmono.so
lib/armeabi-v7a/libunity.so
lib/arm64-v8a/libmain.so
lib/arm64-v8a/libmono.so
lib/arm64-v8a/libunity.so

يُرجى ملاحظة توفّر مكتبتَي armeabi-v7a وarm64-v8a في هذا المثال، ما يعني أنّ التطبيق متوافق مع البنى الأساسية بإصدار 64 بت.

إنشاء تطبيقك باستخدام مكتبات 64 بت

توضِّح التعليمات التالية كيفية إنشاء مكتبات 64 بت. يُرجى العِلم أنّه لا تتناول هذه الخطوات سوى إنشاء الرموز البرمجية والمكتبات التي يمكنك إنشاؤها من المصدر.

الإنشاء باستخدام "استوديو Android" أو Gradle

تستخدم معظم مشاريع "استوديو Android" نظام Gradle كنظام التصميم الأساسي، لذا ينطبق هذا القسم على كلتا الحالتَين. ولتفعيل إصدارات الرموز البرمجية الأصلية، أضِف arm64-v8a و/أو x86_64 إلى الإعداد ndk.abiFilters في ملف "build.gradle" الخاص بتطبيقك، وذلك استنادًا إلى البِنى التي تريد دعمها:

// Your app's build.gradle
plugins {
  id 'com.android.app'
}

android {
   compileSdkVersion 27
   defaultConfig {
       appId "com.google.example.64bit"
       minSdkVersion 15
       targetSdkVersion 28
       versionCode 1
       versionName "1.0"
       ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
// ...

// Your app's build.gradle
plugins {
    id("com.android.app")
}

android {
    compileSdkVersion(27)
    defaultConfig {
        appId = "com.google.example.64bit"
        minSdkVersion(15)
        targetSdkVersion(28)
        versionCode = 1
        versionName = "1.0"
        ndk {
            abiFilters += listOf("armeabi-v7a","arm64-v8a","x86","x86_64")
        }
// ...

الإنشاء باستخدام CMake

إذا كان تطبيقك مصمَّمًا باستخدام CMake، يمكنك إنشاء تطبيقات لمجال ABI بحجم 64 بت من خلال إدخال arm64-v8a في المَعلمة "DANDROID_ABI":

:: Command Line
> cmake -DANDROID_ABI=arm64-v8a … or
> cmake -DANDROID_ABI=x86_64 …

البناء باستخدام لعبة ndk-build

إذا تم إنشاء تطبيقك باستخدام ndk-build، يمكنك إنشاء ملف APK لنظام التشغيل ABI‏ 64 بت من خلال تعديل ملف Application.mk باستخدامvariabileAPP_ABI:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

منفذ رمز مصدر 32 بت إلى 64 بت

إذا كان الرمز البرمجي يعمل على أجهزة الكمبيوتر المكتبي أو iOS، لن تحتاج إلى إجراء أي عمل إضافي على Android. إذا كانت هذه هي المرة الأولى التي يتم فيها إنشاء الرمز البرمجي لنظام بسعة 64 بت، فإنّ المشكلة الرئيسية التي يجب معالجتها هي أنّ المؤشرات لم تعُد تناسب أنواع الأعداد الصحيحة بسعة 32 بت مثل int.

عدِّل الرمز الذي يخزّن المؤشرات في أنواع مثل int أو unsigned أو uint32_t. في أنظمة التشغيل Unix، يتطابق الرمز long مع حجم المؤشر، ولكن هذا ليس هو الحال في Windows. بدلاً من ذلك، استخدِم النوعَين uintptr_t أو intptr_t اللذين يظهران بالهدف. لتخزين الفرق بين مؤشرين، استخدِم النوع ptrdiff_t.

يجب دائمًا تفضيل أنواع الأعداد الصحيحة المحدّدة ذات العرض الثابت والمُعرَّفة في <stdint.h> بدلاً من الأنواع غير ذات العرض الثابت، مثل int أو long، حتى بالنسبة إلى الأنواع غير المؤشر.

استخدِم علامات المُجمِّع التالية لرصد الحالات التي يُجري فيها الرمز البرمجي عملية تحويل بشكلٍ غير صحيح بين المؤشرات والأرقام الصحيحة:

-Werror=pointer-to-int-cast
-Werror=int-to-pointer-cast
-Werror=shorten-64-to-32

تواجه فئات Java التي تحتوي على حقول int تحتوي على مؤشرات إلى عناصر C/C++ المشكلة نفسها. ابحث عن jint في مصدر JNI وتأكَّد من التبديل إلى long على جانب Java وjlong على جانب C++.

إنّ تعريفات الدوال الضمنية أكثر خطورة بكثير على التعليمات البرمجية 64 بت. يفترض C/C++ أنّ نوع الإرجاع لدالة تمّت صياغتها ضمنيًا (أي دالة لم يصادف المُجمِّع تعريفًا لها) هو int. إذا كان نوع الإرجاع الفعلي لدالة معيّنة هو مؤشر، يعمل ذلك بشكل جيد على نظام 32 بت حيث يتلاءم المؤشر مع int. ومع ذلك، على نظام 64 بت، يسقط المُجمِّع النصف العلوي من المؤشر. مثلاً:

// This function returns a pointer:
// extern char* foo();

// If you don't include a header that declares it,
// when the compiler sees this:
char* result = foo();

// Instead of compiling that to:
result = foo();

// It compiles to something equivalent to:
result = foo() & 0xffffffff;

// Which will then cause a SIGSEGV if you try to dereference `result`.

يحوّل رمز المُجمِّع التالي تحذيرات تعريف الدالة الضمنية إلى أخطاء حتى تتمكّن من العثور على هذه المشكلة وإصلاحها بسهولة أكبر:

-Werror=implicit-function-declaration

إذا كان لديك برنامج تجميع مضمّن، أعِد كتابته أو استخدِم تنفيذ C/C++ عاديًا.

إذا كانت لديك أحجام أنواع مضمّنة في الرمز (8 أو 16 بايت مثلاً)، استبدِلها بتعبير sizeof(T) المكافئ، مثل sizeof(void*).

إذا كنت بحاجة إلى تجميع رمز برمجي مختلف بشكل مشروط لنظام التشغيل 32 بت عن نظام التشغيل 64 بت، يمكنك استخدام #if defined(__LP64__) للاختلافات العامة بين 32/64 بت، أو __arm__، __aarch64__ (arm64)، و__i386__ (x86)، و__x86_64__ للمعماريات المحددة المتوافقة مع Android.

يمكنك تعديل سلاسل التنسيق للدوال الشبيهة بـ printf أو scanf، لأنّ محددات التنسيق التقليدية لا تسمح لك بتحديد أنواع 64 بت بطريقة صحيحة لكل من الأجهزة التي تعمل بالإصدار 32 بت و64 بت. تحل وحدات ماكرو PRI وSCN في <inttypes.h> هذه المشكلة، PRIxPTR وSCNxPTR لكتابة المؤشرات السداسية العشرية وقراءتها، وPRId64 وSCNd64 لكتابة وقراءة قيم 64 بت بشكل متنقل.

عند التحويل، قد تحتاج إلى استخدام 1ULL للحصول على ثابت 64 بت للتغيير بدلاً من استخدام 1، الذي يبلغ 32 بت فقط.

الحد من زيادة حجم التطبيق باستخدام "مجموعة حزمات تطبيق Android"

يمكن أن تؤدي إضافة بنية أساسية بإصدار 64 بت إلى تطبيقك إلى زيادة حجم حزمة APK. ننصح بشدة بالاستفادة من ميزة مجموعة حزمات تطبيق Android للحدّ من تأثير الحجم الناتج عن تضمين رموز برمجية أصلية بنظام 32 بت و64 بت في حزمة APK نفسها.

مطوّرو الألعاب

تتوفّر الإصدارات 64 بت من المحرّكات الثلاثة الأكثر استخدامًا:

• مستخدم Unreal منذ 2015
• مشروع Cocos2d منذ عام 2015
• Unity منذ عام 2018

مطوّرو ألعاب Unity

الترقية إلى الإصدارات المتوافقة

توفّر Unity إصدارًا متوافقًا مع الإصدار 64 بت من خلال الإصدارَين 2018.2 و 2017.4.16.

إذا كنت تستخدم إصدارًا من Unity لا يتوافق مع الإصدار 64 بت، حدِّد الإصدار الذي تريد الترقية إليه واتّبِع الأدلة التي يوفّرها IDE لنقل بيئتك، ما يضمن ترقية تطبيقك إلى إصدار يمكنه إنشاء مكتبات 64 بت. تنصح Unity بالوصول إلى أحدث الميزات والتحديثات من خلال الترقية إلى أحدث إصدار من الإصدار الطويل المدى (LTS) للمحرِّر.

في ما يلي رسم بياني يوضّح إصدارات Unity المختلفة والإجراءات التي يجب اتّخاذها:

تغيير إعدادات الإنشاء لإخراج مكتبات 64 بت

إذا كنت تستخدم إصدارًا من Unity متوافقًا مع مكتبات Android 64 بت، يمكنك إنشاء إصدار 64 بت من تطبيقك من خلال تعديل إعدادات الإصدار. استخدِم الخلفية IL2CPP كخلفية للنص البرمجي. لإعداد مشروع Unity لإنشاء بنية 64 بت، يجب إجراء ما يلي:

1. انتقِل إلى إعدادات الإنشاء وتأكَّد من أنّك بصدد إنشاء تطبيق لنظام التشغيل Android من خلال verifying that the Unity symbol is next to Android under Platform. 1. إذا لم يكن رمز Unity بجانب نظام Android الأساسي، اختَر Android وانقر على تبديل النظام الأساسي.

2. انقر على إعدادات المشغّل.

   

3. انتقل إلى لوحة إعدادات المشغّل > إعدادات Android > إعدادات أخرى > الإعداد

4. اضبط Scripting Backend على IL2CPP.

5. ضَع علامة في مربّع الاختيار البنية المستهدَفة > ARM64.

   

6. يمكنك إنشاء الإصدارات كالمعتاد.

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

التوافق مع حِزم APK المتعدّدة وإصدار 64 بت

إذا كنت تستخدم دعم حِزم APK المتعدّدة من Google Play لنشر تطبيقك، يُرجى العِلم أنّه يتم تقييم الامتثال لمتطلبات الإصدار 64 بت على مستوى الإصدار. ومع ذلك، لا ينطبق شرط استخدام نظام التشغيل 64 بت على حِزم APK أو حِزم التطبيقات التي لا يتم توزيعها على الأجهزة التي تعمل بنظام التشغيل Android 9 Pie أو الإصدارات الأحدث.

إذا تم وضع علامة على أحد حِزم APK على أنّها غير متوافقة، ولكنّها إصدار سابق ولا يمكن جعلها متوافقة، يمكنك اتّباع استراتيجية واحدة وهي إضافة سمة maxSdkVersion="27" في عنصر uses-sdk في ملف بيان حزمة APK هذه. لا يتم إرسال حزمة APK هذه إلى الأجهزة التي تعمل بنظام التشغيل Android 9 Pie أو الإصدارات الأحدث، ولم تعُد تمنع الامتثال.

التوافق مع RenderScript و64 بت

إذا كان تطبيقك يستخدم RenderScript وتم إنشاؤه باستخدام إصدار سابق من أدوات Android، قد تلاحظ مشاكل في توافق التطبيق مع إصدار 64 بت. ومع أدوات الإصدار الأقدم من 21.0.0، قد ينشئ برنامج التحويل البرمجي رمز بت في ملف .bc خارجي. لم تعُد ملفات .bc القديمة متوافقة مع المعماريات التي تعمل بنظام 64 بت، لذا يؤدي وجود الملف في حزمة APK إلى حدوث مشكلة عدم الامتثال.

لحلّ هذه المشكلة، عليك إزالة أي ملفات.bc في مشروعك وترقية البيئة إلى build-tools-21.0.0 أو إصدار أحدث، وضبط renderscriptTargetApi في Android Studio على الإصدار 21 أو إصدار أحدث، لطلب من المُجمِّع عدم إنشاء ملفات.bc. بعد ذلك، يجب إعادة إنشاء تطبيقك وفحص .bc من الملفات وتحميلها إلى Play Console.

اختبار تطبيقك على أجهزة تعمل بنظام 64 بت

يجب أن يقدّم إصدار تطبيقك بنظام 64 بت الجودة ومجموعة الميزات نفسها التي يقدّمها الإصدار بنظام 32 بت. اختبِر تطبيقك للتأكّد من أنّ المستخدمين الذين يستخدمون أحدث الأجهزة التي تعمل بالإصدار 64 بت يحصلون على تجربة رائعة في تطبيقك.

الأجهزة التي تعمل بنظام 64 بت فقط

ننصح باختبار تطبيقك في بيئة 64 بت فقط بقدر الإمكان باستخدام أحد الخيارَين التاليَين:

• Google Pixel مزوَّد بنظام 64 بت فقط
• محاكي Android

هاتف Google Pixel مزوّد بنظام 64 بت فقط

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

الحصول على صورة متوافقة مع 64 بت فقط

كما هو الحال في صور النظام المصنع، يمكنك تثبيت صورة 64 بت فقط على جهازك باستخدام أداة Android Flash أو من خلال وميض جهازك يدويًا كما هو موضح في الأقسام التالية.

فلاش جهازك باستخدام أداة Android Flash Tool

تتيح لك أداة Android Flash تثبيت صورة نظام بشكل آمن على جهاز Pixel المتوافق. وتعمل أداة Android Flash Tool مع أي متصفح ويب متوافق مع WebUSB، مثل Chrome أو Edge 79 أو الإصدارات الأحدث.

ترشدك أداة Android Flash Tool خطوة بخطوة خلال عملية تثبيت جهازك، بدون الحاجة إلى تثبيت أدوات، ولكن عليك فتح قفل الجهاز وتفعيل ميزة "تصحيح الأخطاء عبر USB" في خيارات المطوّرين. للحصول على التوجيهات الكاملة، يُرجى الاطّلاع على مستندات أداة فلاش Android.

بعد ذلك، عليك توصيل جهازك عبر USB، ثم الانتقال إلى أداة Android Flash باستخدام أحد الروابط التالية واتّباع الإرشادات التي تظهر على الشاشة، وذلك حسب نوع صورة النظام التي تريد تثبيت ذاكرة التخزين المؤقت لها:

• صور نظام التشغيل Android 14 (الإصدار التجريبي 5.2) بنظام 64 بت فقط

  اختَر الجهاز الذي تحاول فلاشه:

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • Pixel 6 Pro

• صور نظام التشغيل Android 13 (الإصدار التجريبي 3.2 من QPR3) بنظام 64 بت فقط

  اختَر الجهاز الذي تحاول فلاشه:

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • Pixel 6 Pro

وميض جهازك يدويًا

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

بعد الاحتفاظ بنسخة احتياطية من بيانات جهازك وتنزيل صورة النظام المطابقة، يمكنك فلاشة الصورة على جهازك.

يمكنك اختيار الرجوع إلى أحدث إصدار علني في أي وقت.

صور المصنع لنظام التشغيل Android 14 (الإصدار التجريبي 5.3) بنظام 64 بت فقط

توفّر هذه الصور بيئة صارمة تعمل بنظام 64 بت فقط لاختبار توافق التطبيقات المتوافقة مع هذا النظام. هذه الإعدادات المخصّصة لإصدار 64 بت فقط مخصّصة للمطوّرين فقط.

صور من المصنع بنظام 64 بت فقط لنظام Android 13 (الإصدار التجريبي 3.2 من QPR3)

توفّر هذه الصور بيئة صارمة تعمل بنظام 64 بت فقط لاختبار توافق التطبيقات المتوافقة مع هذا النظام. هذه الإعدادات المخصّصة لإصدار 64 بت فقط مخصّصة للمطوّرين فقط.

الرجوع إلى إصدار علني

يمكنك استخدام أداة فلاش Android لتثبيت نسخة البرامج الأصلية، أو الحصول على نسخة من نظام التشغيل المتوافقة مع مواصفات الشركة المصنّعة من صفحة نسخة البرامج الأصلية لأجهزة Nexus وPixel ثم تثبيتها يدويًا على الجهاز.

محاكي Android

بدءًا من الإصدار 12 من نظام التشغيل Android (المستوى 31 لواجهة برمجة التطبيقات)، أصبحت صور نظام Android Emulator متاحة فقط بنظام 64 بت. يمكنك إنشاء جهاز Android افتراضي (AVD) باستخدام صورة نظام تعمل بالإصدار 12 من Android (المستوى 31 من واجهة برمجة التطبيقات) أو الإصدارات الأحدث للحصول على بيئة صارمة تستخدم تكنولوجيا 64 بت فقط لاختبار التطبيقات.

خيارات الأجهزة الأخرى

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

تثبيت تطبيقك واختباره

أسهل طريقة لاختبار ملف APK هي تثبيت التطبيق باستخدام Android DebugBridge (adb). وفي معظم الحالات، يمكنك توفير --abi كمَعلمة للإشارة إلى المكتبات المطلوب تثبيتها على الجهاز. يؤدي هذا إلى تثبيت التطبيق بمكتبات 64 بت فقط على الجهاز.

:: Command Line
# A successful install:
> adb install --abi armeabi-v7a YOUR_APK_FILE.apk
Success

# If your APK does not have the 64-bit libraries:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
adb: failed to install YOUR_APK_FILE.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]

# If your device does not support 64-bit, an emulator, for example:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
ABI arm64-v8a not supported on this device

بعد إتمام عملية التثبيت بنجاح، اختبِر تطبيقك كالمعتاد لمحاولة التأكّد من أنّ الجودة هي نفسها في الإصدار 32 بت.

التحقّق من المشاكل المعروفة في التوافق

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

SoLoader

إذا كنت تستخدِم حزمة تطوير البرامج (SDK) لتحميل الرموز البرمجية الأصلية SoLoader، عليك التحديث إلى الإصدار 0.10.4 أو إصدار أحدث. إذا كان تطبيقك يستخدم حِزم تطوير برامج (SDK) تعتمد على SoLoader، احرص أيضًا على التحديث إلى أحدث إصدار ثابت من حِزم SDK المتأثرة.

يفترض الإصدار 0.9.0 من SoLoader والإصدارات الأقدم أنّ مكتبات النظام متوفّرة في ‎ /vendor/lib:/system/lib. لا يمكن ملاحظة هذا الخطأ في أجهزة مثل Pixel 7 التي يتوفّر فيها المسار، ولكن يؤدي هذا الافتراض إلى حدوث أعطال في الأجهزة التي تحتوي فقط على مكتبات النظام في /vendor/lib64:/system/lib64.

لمزيد من المعلومات عن حلّ هذه المشكلة والمشاكل الأخرى الناتجة عن SoLoader، اطّلِع على الإجابة المقابلة في مركز مساعدة Google.

OpenSSL

إذا كنت تستخدم مكتبة OpenSSL، عليك التحديث إلى الإصدار 1.1.1i من OpenSSL أو إصدار أحدث. إذا كان تطبيقك يستخدم حِزم تطوير برامج (SDK) توفّر إمكانية الاتصال باستخدام بروتوكول HTTPS أو حِزم تطوير برامج (SDK) أخرى تعتمد على مكتبة OpenSSL، احرص أيضًا على التحديث إلى أحدث إصدار من حزمة SDK التي تستخدم إصدارًا أحدث من مكتبة OpenSSL. تواصَل مع موفِّر حزمة SDK إذا لم يكن هناك حزمة متاحة.

تعمل ميزة ARMv8.3 PAC على تفعيل سلامة تدفق التحكّم بمساعدة الأجهزة من خلال مصادقة المؤشرات في وقت التشغيل. تستخدم الإصدارات السابقة من OpenSSL هذه الإمكانات بشكل غير صحيح، ما يتسبّب في حدوث أعطال في وقت التشغيل في جميع الأجهزة المزوّدة بمعالجات تستند إلى ARMv8.3a والإصدارات الأحدث.

لمزيد من المعلومات حول إصلاح هذه المشكلة والمشاكل الأخرى الناتجة عن OpenSSL، يمكنك الاطّلاع على الإجابة المقابلة في مركز مساعدة Google.

BTI

يستخدم الإصدار ARMv8.5 والإصدارات الأحدث تعليمات استهداف الفروع (BTI) للمساعدة في الحماية من هجمات JOP. إنّ الإصدارات الأقدم من حِزم SDK التي تستخدم تشويش الرمز المبرمَج والتي تتفرع إلى Offsets عشوائية من المكتبات التي تم إنشاؤها باستخدام BTI يمكن أن تؤدي إلى تعطُّل التطبيقات. وبما أنّ التعليمات يتم ترميزها على هيئة إشارات، لا يمكن ملاحظة هذا الخطأ في الأجهزة التي لا تتوافق مع BTI.

نشر

عندما ترى أنّ تطبيقك أصبح جاهزًا، يمكنك نشره كالمعتاد. كما هو الحال دائمًا، يُرجى مواصلة اتّباع أفضل الممارسات لنشر تطبيقك. ننصحك بالاستفادة من مسارات الاختبار المغلق لطرح التطبيق على عدد محدود من المستخدمين لضمان اتساق جودة تطبيقك.

وكما هو الحال عند طرح تحديث رئيسي، احرص على إجراء اختبار دقيق على الأجهزة التي تعمل بالإصدار 64 بت قبل نشر التحديث على نطاق أوسع من الجمهور.