دعم بُنى 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، يمكنك إنشاء ملف APK لنظام التشغيل 64 بت ABI من خلال إدخال القيمة 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 App Bundle لتقليل تأثير حجم تضمين الرمز البرمجي الأصلي بنظامَي 32 و64 بت في حزمة APK نفسها.

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

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

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

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

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

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

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

في ما يلي رسم بياني يوضّح إصدارات 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 أو من خلال فلاشه الجهاز يدويًا، كما هو موضّح في الأقسام التالية.

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

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

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

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

• صور نظام التشغيل 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 بت. أنشئ جهازًا افتراضيًا (AVD) باستخدام ملف تصوُّر نظام يعمل بالإصدار 12 من نظام التشغيل Android (المستوى 31 لواجهة برمجة التطبيقات) أو إصدار أحدث للحصول على بيئة اختبار صارمة تعمل بالإصدار 64 بت فقط لاختبار التطبيقات.

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

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

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

أسهل طريقة لاختبار حزمة APK هي تثبيت التطبيق باستخدام أداة Android Debug Bridge (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 بت قبل نشر التطبيق لجمهور أكبر.