تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

دعم بُنى 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 بت، لكن لكل بنية 32 بت أصلية تدعمها يجب تضمين بنية 64 بت المقابلة.

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

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

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

النظام الأساسي	مجلد مكتبات 32 بت	مجلد المكتبات 64 بت
تفعيل جهاز الإنذار	`lib/armeabi-v7a`	`lib/arm64-v8a`
×86	`lib/x86`	`lib/x86_64`

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

وفي الحالة المعتادة، تشتمل حزمة APK أو حزمة تم إنشاؤها لكلٍ من بُنى 32 بت و64 بت على مجلدات لكل من واجهات التطبيق الثنائية (ABI)، ولكل منها مجموعة مقابلة من المكتبات الأصلية. في حال عدم دعم الإصدار 64 بت، قد يظهر لك مجلد بتنسيق ABI 32 بت، ولكن ليس مجلدًا بحجم 64 بت.

البحث عن المكتبات الأصلية باستخدام أداة تحليل APK

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

افتح استوديو Android وافتح أي مشروع.
من القائمة، اختَر إنشاء > تحليل APK...
اختَر حِزمة APK التي تريد تقييمها.
ابحث داخل المجلد lib الذي يستضيف ملفات ".so" في حال توفُّرها. وفي حال عدم توفّرها، يعني ذلك أنّ تطبيقك يتوافق مع الأجهزة التي تعمل بالإصدار 64 بت وليس عليك اتّخاذ أي إجراء إضافي. في حال ظهور armeabi-v7a أو x86، هذا يعني أنّ لديك مكتبات بإصدار 32 بت.
تحقَّق لمعرفة ما إذا كان لديك ملفات ".so" مشابهة في المجلد arm64-v8a أو x86_64.
إذا لم يكن لديك أي مكتبات arm64-v8a أو x86_64، عليك تعديل عملية الإنشاء لبدء إنشاء هذه العناصر ووضعها في حزمة APK.
إذا رأيت أنّ كلتا المكتبتين قيد حزمتي، يمكنك التخطّي إلى اختبار تطبيقك على أجهزة 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'
// ...

Kotlin

// 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، يمكنك إنشاء واجهات تطبيقات ثنائية (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 مع حجم المؤشر، ولكن هذا لا ينطبق على 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 المختلفة والإجراءات التي عليك اتّخاذها:

إصدار Unity	يتوافق الإصدار مع نظام 64 بت؟	الإجراءات المقترَحة
2020.x	✔️	تأكَّد من أنّ إعدادات الإصدار تُخرج مكتبات 64 بت.
2019.x	✔️	تأكَّد من أنّ إعدادات الإصدار تُخرج مكتبات 64 بت.
2018.4 (LTS)	✔️	تأكَّد من أنّ إعدادات الإصدار تُخرج مكتبات 64 بت.
2018.3	✔️	تأكَّد من أنّ إعدادات الإصدار تُخرج مكتبات 64 بت.
2018.2	✔️	تأكَّد من أنّ إعدادات الإصدار تُخرج مكتبات 64 بت.
2018.1	➖	يتوافق مع إصدار 64 بت تجريبي.
2017.4 (LTS)	✔️	متاح اعتبارًا من 2017.4.16. تأكَّد من أنّ إعدادات الإصدار تُخرج مكتبات 64 بت.
2017.3	DUNS️	الترقية إلى الإصدار الذي يتوافق مع 64 بت.
2017.2	DUNS️	الترقية إلى الإصدار الذي يتوافق مع 64 بت.
2017.1	DUNS️	الترقية إلى الإصدار الذي يتوافق مع 64 بت.
<=5.6	DUNS️	الترقية إلى الإصدار الذي يتوافق مع 64 بت.

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

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

انتقِل إلى إعدادات التصميم وتأكَّد من إنشاء تطبيقات لنظام Android من خلال التأكّد من أنّ رمز Unity يظهر بجانب Android ضمن النظام الأساسي. 1. إذا لم يكن رمز Unity يظهر بجانب نظام Android الأساسي، اختَر Android وانقر على Switch Platform (تبديل النظام الأساسي).
انقر على إعدادات المشغّل.
انتقل إلى لوحة إعدادات المشغّل > إعدادات Android > إعدادات أخرى > الإعداد
اضبط خلفية البرمجة النصية على IL2CPP.
ضَع علامة في مربّع الاختيار بنية الاستهداف > ARM64.
ابنِ كالمعتاد!

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

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

في حال استخدام Google Play لإتاحة حِزم APK متعدّدة لنشر تطبيقك، يُرجى العِلم أنّه يتم تقييم الامتثال لمتطلّبات إصدار 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" على الإصدار 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

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

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

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

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

اختَر الجهاز الذي تحاول ومضغه:
صور النظام بالإصدار 64 بت فقط من نظام التشغيل Android 13 (الإصدار التجريبي 3.2 من QPR3)

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

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

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

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

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

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

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

الجهاز	رابط التنزيل	المجموع الاختباري لخوارزمية SHA-256
Pixel 4a (5G)		`7e6731fab811ae389f5ff882d5c5a2b8b942b8363b22bbcc038b39d7c539e60a`
Pixel 5		`c4da6a19086a02f2cd2fa7a4054e870916954b8e5a61e9a07ee942c537e4b45a`
Pixel 6		`98943384284cbc7323b8867d84c36151757f67ae7633012fb69cb5d6bec2b554`
Pixel 6 Pro		`67ec40be5bd05a40fa5dabc1ce6795aae75d1904193d52e2da00425ed7cb895b`

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

الجهاز	رابط التنزيل	المجموع الاختباري لخوارزمية SHA-256
Pixel 4a (5G)		`b4be40924f62c3c2b3ed20a9f7fa4303aa9c39649d778eb96f86c867fe3ae59a`
Pixel 5		`6e5e027a4f64f9f786db9bb69d50d1a551c3f6aad893ae450e1f8279ea1b761a`
Pixel 6		`becb9b81a5bddad67a4ac32d30a50dcb372b9d083cb7c046e5180510e479a0b8`
Pixel 6 Pro		`b0ef544ed2312ac44dc827f24999281b147c11d76356c2d06b2c57a191c60480`

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

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

محاكي Android

بدءًا من الإصدار Android 12 (المستوى 31 من واجهة برمجة التطبيقات)، ستكون صور نظام "محاكي Android" بنظام 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) الخاصة بالتشويش، وتتفرع إلى إزاحة عشوائية للمكتبات التي تم إنشاؤها باستخدام تقنية BTI يمكن أن تتسبب في تعطُّل التطبيقات. وبما أنّ التعليمات مرمّزة على أنّها تلميحات، لا يمكن رصد هذا الخطأ في الأجهزة غير المتوافقة مع ميزة BTI.

نشر

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

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

تنزيل Android 14 factory system image (64-bit-only)

قبل التنزيل، يجب الموافقة على الأحكام والشروط التالية.

الأحكام والشروط

By clicking to accept, you hereby agree to the following:

All use of this development version SDK will be governed by the Android Software Development Kit License Agreement (available at https://developer.android.com/studio/terms and such URL may be updated or changed by Google from time to time), which will terminate when Google issues a final release version.

Your testing and feedback are important part of the development process and by using the SDK, you acknowledge that (i) implementation of some features are still under development, (ii) you should not rely on the SDK having the full functionality of a stable release; (iii) you agree not to publicly distribute or ship any application using this SDK as this SDK will no longer be supported after the official Android SDK is released; and (iv) you agree that Google may deliver elements of the SDK to your devices via auto-update (OTA or otherwise, in each case as determined by Google).

WITHOUT LIMITING SECTION 10 OF THE ANDROID SOFTWARE DEVELOPMENT KIT LICENSE AGREEMENT, YOU UNDERSTAND THAT A DEVELOPMENT VERSION OF A SDK IS NOT A STABLE RELEASE AND MAY CONTAIN ERRORS, DEFECTS AND SECURITY VULNERABILITIES THAT CAN RESULT IN SIGNIFICANT DAMAGE, INCLUDING THE COMPLETE, IRRECOVERABLE LOSS OF USE OF YOUR COMPUTER SYSTEM OR OTHER DEVICE.