دعم بُنى 64 بت

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

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

تقييم تطبيقك

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

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

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

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

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

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

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

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

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

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

بالنسبة إلى بنية 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، يمكنك استخراج ملف 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، يمكنك إنشاء إصدار لنظام 64 بت. واجهات التطبيق الثنائية (ABI) عن طريق تمرير arm64-v8a في "DANDROID_ABI" :

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

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

إذا تم إنشاء تطبيقك باستخدام ndk-build، يمكنك تصميمه من أجل واجهات التطبيق الثنائية (ABI) 64 بت عن طريق تعديل ملف "Application.mk" باستخدام المتغير APP_ABI:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

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

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

تحديث الرمز الذي يخزِّن المؤشرات بأنواع مثل int أو unsigned أو uint32_t في أنظمة التشغيل Unix، تتطابق السمة long مع حجم المؤشر، ولكن هذا العدد ليس صحيحًا. true على 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 بت الذي يتناسب فيه المؤشر مع عدد صحيح. ومع ذلك، في نظام 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 بت:

• لعبة استثنائية منذ عام 2015
• مشروع Cocos2d منذ عام 2015
• الانسجام منذ 2018

مطوّرو Unity

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

توفِّر Unity توافقًا للإصدار 64 بت مع الإصدار 2018.2 2017.4.16:

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

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

تغيير إعدادات الإصدار إلى مكتبات 64 بت

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

1. انتقِل إلى إعدادات الإصدار وتأكَّد من أنّك تريد إنشاء نظام Android من خلال والتحقق من أنّ رمز Unity يقع بجانب Android ضمن Platform (النظام الأساسي). 1. إذا لم يكن رمز Unity بجوار نظام Android الأساسي، اختَر Android وانقر على تبديل النظام الأساسي.

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

   

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

4. اضبط خلفية البرمجة النصية على IL2CPP.

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

   

6. ابنِ كالمعتاد!

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

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

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

في حال تم وضع علامة على أحد حِزم 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" للمستخدمين الذين تزيد أعمارهم عن 21 عامًا، لإخبارهم برنامج التجميع حتى لا يصدر ملفات .bc. بعد ذلك، يجب إعادة إنشاء التطبيق وفحص .bc. والملفات وتحميلها إلى Play Console.

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

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

الأجهزة التي تعمل بالإصدار 64 بت فقط

نقترح، كلما أمكن ذلك، اختبار تطبيقك مع نظام تشغيل 64 بت فقط. بيئة التشغيل باستخدام أحد الخيارات التالية:

• هاتف Google Pixel مع صورة لنظام 64 بت فقط
• محاكي Android

هاتف Google Pixel مع صورة بنظام 64 بت فقط

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

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

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

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

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

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

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

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

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

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

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

  اختَر الجهاز الذي تحاول ومضغه:

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

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

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

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

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

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

توفر هذه الصور بيئة صارمة لها 64 بت فقط لاختبار تطبيق 64 بت التوافق. تجدر الإشارة إلى أنّ عمليات ضبط الإصدار 64 بت فقط مخصَّصة لمطوّري البرامج فقط.

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

توفر هذه الصور بيئة صارمة لها 64 بت فقط لاختبار تطبيق 64 بت التوافق. تجدر الإشارة إلى أنّ عمليات ضبط الإصدار 64 بت فقط مخصَّصة لمطوّري البرامج فقط.

الرجوع إلى إصدار متاح للجميع

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

محاكي Android

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

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

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

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

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

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

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

مؤشر BTI

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

نشر

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

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