پشتیبانی از معماری های 64 بیتی

با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

برنامه‌های منتشر شده در Google Play باید از معماری‌های 64 بیتی پشتیبانی کنند. افزودن یک نسخه 64 بیتی از برنامه شما باعث بهبود عملکرد می شود و شما را برای دستگاه هایی با سخت افزار فقط 64 بیتی آماده می کند.

مراحل زیر تضمین می کند که برنامه 32 بیتی شما از دستگاه های 64 بیتی پشتیبانی می کند.

برنامه خود را ارزیابی کنید

اگر برنامه شما فقط از کدهایی استفاده می کند که به زبان برنامه نویسی جاوا یا کاتلین نوشته شده است، از جمله تمام کتابخانه ها یا SDK ها، برنامه شما از دستگاه های 64 بیتی پشتیبانی می کند. اگر برنامه شما از کد بومی استفاده می‌کند یا مطمئن نیستید که از آن استفاده می‌کند، برنامه خود را ارزیابی کنید.

بررسی سریع وضعیت

به کنسول Play بروید و به نسخه‌های موجود نگاهی بیندازید تا ببینید آیا مطابقت دارند یا خیر.

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 Analyzer به دنبال کتابخانه های بومی باشید

APK Analyzer ابزاری است که به شما امکان می دهد جنبه های مختلف یک APK ساخته شده را ارزیابی کنید. از آن برای یافتن کتابخانه های بومی استفاده کنید و از وجود کتابخانه های 64 بیتی اطمینان حاصل کنید.

1. Android Studio را باز کنید و هر پروژه ای را باز کنید .

2. از منو، Build > Analyze APK را انتخاب کنید…

   

3. APK مورد نظر برای ارزیابی را انتخاب کنید.

4. به پوشه lib نگاه کنید، که در صورت وجود، میزبان فایل های '.so' است. اگر هیچ کدام وجود ندارد، برنامه شما از دستگاه های 64 بیتی پشتیبانی می کند و نیازی به اقدام دیگری نیست. اگر armeabi-v7a یا x86 را می بینید، کتابخانه های 32 بیتی دارید.

5. بررسی کنید که آیا فایل های مشابه '.so' در پوشه arm64-v8a یا x86_64 دارید یا خیر.

   

6. اگر هیچ کتابخانه arm64-v8a یا x86_64 ندارید، فرآیند ساخت خود را به‌روزرسانی کنید تا شروع به ساخت و بسته‌بندی آن مصنوعات در APK کنید.

7. اگر قبلاً می‌بینید که هر دو کتابخانه بسته‌بندی شده‌اند، می‌توانید از آزمایش برنامه خود روی سخت‌افزار ۶۴ بیتی رد شوید.

با باز کردن فایل‌های APK به دنبال کتابخانه‌های بومی بگردید

فایل های APK مانند فایل های فشرده ساختار یافته اند. با خط فرمان یا هر ابزار استخراج دیگری، فایل APK را استخراج کنید. بسته به ابزار استخراج خود، ممکن است مجبور شوید نام فایل را به .zip تغییر دهید.

فایل‌های استخراج‌شده را با دنبال کردن دستورالعمل‌های بالا مرور کنید تا مشخص کنید آیا برنامه شما از دستگاه‌های ۶۴ بیتی پشتیبانی می‌کند یا خیر. می توانید مثال دستور زیر را از خط فرمان اجرا کنید:

:: 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 Studio یا Gradle بسازید

اکثر پروژه های اندروید استودیو از 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 ساخته شده است، می توانید با تغییر فایل Application.mk با استفاده از متغیر APP_ABI ، برای ABI های 64 بیتی بسازید:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

پورت کد 32 بیتی به 64 بیت

اگر کد شما از قبل بر روی دسکتاپ یا iOS اجرا می شود، نیازی به انجام کار اضافی برای اندروید ندارید. اگر این اولین باری است که کد شما برای یک سیستم 64 بیتی ساخته می شود، مشکل اصلی که باید به آن توجه کنید این است که نشانگرها دیگر در انواع اعداد صحیح 32 بیتی مانند int جا نمی شوند.

کدی را به‌روزرسانی کنید که نشانگرها را در انواعی مانند int ، unsigned یا uint32_t ذخیره می‌کند. در سیستم‌های یونیکس، long با اندازه نشانگر مطابقت دارد، اما این در ویندوز صادق نیست. درعوض، از انواع افشاگر قصد 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

کلاس های جاوا با فیلدهای int که نشانگرهای اشیاء C/C++ را نگه می دارند، همین مشکل را دارند. jint در منبع JNI خود جستجو کنید و مطمئن شوید که در سمت جاوا به long و در سمت C++ jlong ​​تغییر دهید.

اعلان تابع ضمنی برای کدهای 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 مانند تنظیم کنید، زیرا مشخص‌کننده‌های قالب سنتی به شما اجازه نمی‌دهند تا انواع ۶۴ بیتی را به گونه‌ای مشخص کنید که برای دستگاه‌های ۳۲ بیتی و ۶۴ بیتی درست باشد. ماکروهای PRI و SCN در <inttypes.h> این مشکل را حل می کنند، PRIxPTR و SCNxPTR برای نوشتن و خواندن نشانگرهای هگز. و PRId64 و SCNd64 برای نوشتن و خواندن مقادیر 64 بیتی به صورت قابل حمل.

هنگام جابجایی، ممکن است لازم باشد از 1ULL برای دریافت یک ثابت 64 بیتی برای جابجایی به جای استفاده از 1 که فقط 32 بیت است استفاده کنید.

اندازه کاهش با Android App Bundle افزایش می‌یابد

افزودن پشتیبانی معماری 64 بیتی به برنامه شما می تواند باعث افزایش اندازه APK شما شود. ما قویاً توصیه می‌کنیم از ویژگی Android App Bundle استفاده کنید تا تأثیر اندازه گنجاندن کدهای 32 و 64 بیتی در یک APK را به حداقل برسانید.

توسعه دهندگان بازی

سه موتور پرکاربرد از 64 بیت پشتیبانی می کنند:

• غیر واقعی از سال 2015
• Cocos2d از سال 2015
• وحدت از سال 2018

توسعه دهندگان یونیتی

به نسخه های قابل ارتقا ارتقا دهید

یونیتی با نسخه های 2018.2 و 2017.4.16 پشتیبانی 64 بیتی را ارائه می دهد.

اگر از نسخه‌ای از یونیتی استفاده می‌کنید که از 64 بیت پشتیبانی نمی‌کند، نسخه‌ای را که می‌خواهید به آن ارتقا دهید تعیین کنید و از راهنماهایی که Unity برای انتقال محیط شما ارائه می‌کند پیروی کنید، مطمئن شوید که برنامه شما به نسخه‌ای ارتقا یافته است که می‌تواند کتابخانه‌های 64 بیتی بسازد. یونیتی توصیه می کند با ارتقاء به آخرین نسخه LTS ویرایشگر به آخرین ویژگی ها و به روز رسانی ها دسترسی داشته باشید.

در اینجا نموداری وجود دارد که نسخه های مختلف Unity و کارهایی که باید انجام دهید را نشان می دهد:

تنظیمات ساخت را به کتابخانه های 64 بیتی خروجی تغییر دهید

اگر از نسخه‌ای از Unity استفاده می‌کنید که از کتابخانه‌های اندروید ۶۴ بیتی پشتیبانی می‌کند، می‌توانید با تنظیم تنظیمات ساخت، نسخه ۶۴ بیتی برنامه خود را ایجاد کنید. از پشتیبان IL2CPP به عنوان باطن اسکریپت خود استفاده کنید. برای راه اندازی پروژه Unity خود برای ساخت معماری 64 بیتی، موارد زیر را انجام دهید:

1. به Build Settings بروید و با تأیید اینکه نماد Unity در کنار Android در پلتفرم قرار دارد، مطمئن شوید که برای Android می‌سازید. 1. اگر نماد Unity در کنار پلتفرم اندروید نیست، Android را انتخاب کرده و Switch Platform را کلیک کنید.

2. روی تنظیمات پخش کننده کلیک کنید.

   

3. به پنل تنظیمات پخش کننده > تنظیمات اندروید > تنظیمات دیگر > پیکربندی بروید

4. Scripting Backend را روی IL2CPP تنظیم کنید.

5. کادر Target Architecture > ARM64 را انتخاب کنید.

   

6. طبق معمول بسازید!

توجه داشته باشید که ساختن برای ARM64 نیاز دارد که تمام دارایی های شما به طور خاص برای آن پلتفرم ساخته شود. دستورالعمل‌های Unity را برای کاهش اندازه APK دنبال کنید و برای کمک به کاهش این افزایش اندازه، از ویژگی Android App Bundle استفاده کنید.

سازگاری چند 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 بیتی
• شبیه ساز اندروید

Google Pixel با تصویر سیستم فقط 64 بیتی

برای تسهیل توسعه و آزمایش برنامه، تصاویر سیستم خاصی را با یک محیط سخت 64 بیتی برای برخی از دستگاه‌های Pixel ارائه کرده‌ایم. این تصاویر فقط 64 بیتی در ابتدا همزمان با تصاویر سیستم کارخانه استاندارد برای نسخه‌های پیش‌نمایش اندروید 13 و 14 ارائه شده‌اند، اما می‌توانید همچنان که برنامه‌تان را برای سازگاری 64 بیتی آزمایش می‌کنید، از آنها استفاده کنید.

یک تصویر فقط 64 بیتی دریافت کنید

مشابه تصاویر سیستم کارخانه، می‌توانید با استفاده از Android Flash Tool یا با فلش دستی دستگاه خود ، همانطور که در بخش‌های زیر توضیح داده شده است، یک تصویر فقط 64 بیتی را روی دستگاه خود فلش بزنید.

دستگاه خود را با استفاده از ابزار فلش اندروید فلش کنید

Android Flash Tool به شما این امکان را می دهد که به طور ایمن یک تصویر سیستم را در دستگاه Pixel پشتیبانی شده خود فلش کنید. Android Flash Tool با هر مرورگر وب که از WebUSB پشتیبانی می کند، مانند Chrome یا Edge 79+ کار می کند.

Android Flash Tool شما را گام به گام در فرآیند فلش کردن دستگاهتان راهنمایی می کند—نیازی به نصب ابزار نیست—اما باید قفل دستگاه خود را باز کنید و USB Debugging را در گزینه های برنامه نویس فعال کنید . برای دستورالعمل‌های کامل، به مستندات Android Flash Tool مراجعه کنید.

دستگاه خود را از طریق USB وصل کنید، سپس، بسته به نوع تصویر سیستمی که می‌خواهید فلش شود، با استفاده از یکی از پیوندهای زیر به Android Flash Tool بروید و دستورالعمل‌های روی صفحه را دنبال کنید:

• تصاویر سیستمی فقط 64 بیتی اندروید 14 (بتا 5.2).

  دستگاهی را که می خواهید فلش کنید انتخاب کنید:

  • Pixel 4a (5G)
  • پیکسل 5
  • پیکسل 6
  • پیکسل 6 پرو

• Android 13 (QPR3 Beta 3.2) فقط تصاویر سیستمی 64 بیتی

  دستگاهی را که می خواهید فلش کنید انتخاب کنید:

  • Pixel 4a (5G)
  • پیکسل 5
  • پیکسل 6
  • پیکسل 6 پرو

دستگاه خود را به صورت دستی فلش کنید

همچنین می توانید آخرین تصویر سیستم را دانلود کرده و به صورت دستی در دستگاه خود فلش کنید. برای دانلود تصویر سیستم برای دستگاه تست خود به جدول زیر مراجعه کنید. چشمک زدن دستی دستگاه در صورتی مفید است که به کنترل دقیقی بر روی محیط آزمایشی نیاز دارید یا نیاز به نصب مجدد مکرر دارید، مانند هنگام انجام آزمایش خودکار.

بعد از اینکه از اطلاعات دستگاه خود نسخه پشتیبان تهیه کردید و تصویر سیستم منطبق را دانلود کردید، می توانید تصویر را روی دستگاه خود فلش کنید .

در هر زمان می توانید انتخاب کنید که به آخرین ساخت عمومی بازگردید .

تصاویر کارخانه ای 64 بیتی برای اندروید 14 (بتا 5.3)

این تصاویر یک محیط سخت 64 بیتی را برای آزمایش سازگاری برنامه های 64 بیتی ارائه می دهند. این تنظیمات 64 بیتی فقط برای استفاده توسعه دهندگان هستند.

تصاویر کارخانه فقط 64 بیت برای Android 13 (QPR3 Beta 3.2)

این تصاویر یک محیط سخت 64 بیتی را برای آزمایش سازگاری برنامه های 64 بیتی ارائه می دهند. این تنظیمات 64 بیتی فقط برای استفاده توسعه دهندگان هستند.

بازگشت به یک ساختمان عمومی

می‌توانید از Android Flash Tool برای فلش کردن تصویر کارخانه استفاده کنید، یا یک تصویر سیستم مشخصات کارخانه را از صفحه Factory Images for Nexus و Pixel Devices دریافت کنید و سپس به صورت دستی آن را در دستگاه فلش کنید.

شبیه ساز اندروید

از اندروید 12 (سطح API 31)، تصاویر سیستم شبیه ساز اندروید فقط 64 بیتی هستند. یک دستگاه مجازی Android (AVD) با استفاده از یک تصویر سیستم با Android 12 (سطح API 31) یا بالاتر ایجاد کنید تا یک محیط سختگیرانه فقط 64 بیتی برای آزمایش برنامه داشته باشید.

سایر گزینه های دستگاه

اگر یکی از این دستگاه‌ها را ندارید یا نمی‌توانید از شبیه‌ساز اندروید استفاده کنید، بهترین گزینه بعدی شما استفاده از دستگاهی است که قابلیت 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 های آسیب دیده نیز به روز رسانی کنید.

SoLoader نسخه 0.9.0 و پایین‌تر فرض می‌کنیم که کتابخانه‌های سیستم در /vendor/lib:/system/lib وجود دارند. این اشکال در دستگاه‌هایی مانند Pixel 7 که مسیر وجود دارد قابل مشاهده نیست، اما این فرض باعث خرابی دستگاه‌هایی می‌شود که فقط کتابخانه‌های سیستم در /vendor/lib64:/system/lib64 دارند.

برای اطلاعات بیشتر در مورد رفع این مشکل و سایر مشکلات ناشی از SoLoader، به پاسخ مربوطه در مرکز راهنمای Google مراجعه کنید.

OpenSSL

اگر از کتابخانه OpenSSL استفاده می کنید، به OpenSSL 1.1.1i یا بالاتر به روز کنید. اگر برنامه شما از SDKهایی استفاده می‌کند که با استفاده از HTTPS ارتباط برقرار می‌کنند، یا سایر SDK‌هایی که به OpenSSL وابسته هستند، حتماً به آخرین نسخه SDK که از نسخه OpenSSL جدیدتر استفاده می‌کند نیز به‌روزرسانی کنید. اگر ارائه‌دهنده SDK در دسترس نیست، تماس بگیرید.

ARMv8.3 PAC یکپارچگی جریان کنترل به کمک سخت افزار را با احراز هویت اشاره گرها در زمان اجرا فعال می کند. نسخه‌های قبلی OpenSSL از این قابلیت‌ها به‌درستی استفاده می‌کنند و باعث خرابی زمان اجرا در همه دستگاه‌های دارای پردازنده مبتنی بر ARMv8.3a و بالاتر می‌شود.

برای اطلاعات بیشتر در مورد رفع این مشکل و سایر مشکلات ناشی از OpenSSL، به پاسخ مربوطه در مرکز راهنمای Google مراجعه کنید.

BTI

ARMv8.5 و بالاتر از Branch Target Instructions (BTIs) برای کمک به محافظت در برابر حملات JOP استفاده می کنند. نسخه‌های قبلی کدهای توسعه نرم‌افزار مبهم‌سازی که به آفست‌های تصادفی کتابخانه‌های ساخته‌شده با BTI منشعب می‌شوند، می‌توانند باعث از کار افتادن برنامه‌ها شوند. از آنجایی که دستورالعمل ها به صورت HINT کدگذاری می شوند، این اشکال در دستگاه هایی که از BTI پشتیبانی نمی کنند قابل مشاهده نیست.

منتشر کنید

وقتی احساس کردید برنامه شما آماده است، به طور معمول منتشر کنید. مثل همیشه، به دنبال بهترین شیوه ها برای استقرار برنامه خود باشید. توصیه می‌کنیم از مسیرهای آزمایشی بسته برای عرضه به تعداد محدودی از کاربران استفاده کنید تا اطمینان حاصل شود که کیفیت برنامه شما ثابت است.

مانند زمانی که یک به‌روزرسانی بزرگ ارائه می‌کنید، مطمئن شوید که قبل از انتشار برای مخاطبان بزرگ‌تر، دستگاه‌های دارای قابلیت ۶۴ بیت را کاملاً آزمایش کرده‌اید.

برنامه‌های منتشر شده در Google Play باید از معماری‌های 64 بیتی پشتیبانی کنند. افزودن یک نسخه 64 بیتی از برنامه شما باعث بهبود عملکرد می شود و شما را برای دستگاه هایی با سخت افزار فقط 64 بیتی آماده می کند.

مراحل زیر تضمین می کند که برنامه 32 بیتی شما از دستگاه های 64 بیتی پشتیبانی می کند.

برنامه خود را ارزیابی کنید

اگر برنامه شما فقط از کدهایی استفاده می کند که به زبان برنامه نویسی جاوا یا کاتلین نوشته شده است، از جمله تمام کتابخانه ها یا SDK ها، برنامه شما از دستگاه های 64 بیتی پشتیبانی می کند. اگر برنامه شما از کد بومی استفاده می‌کند یا مطمئن نیستید که از آن استفاده می‌کند، برنامه خود را ارزیابی کنید.

بررسی سریع وضعیت

به کنسول Play بروید و به نسخه‌های موجود نگاهی بیندازید تا ببینید آیا مطابقت دارند یا خیر.

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 Analyzer به دنبال کتابخانه های بومی باشید

APK Analyzer ابزاری است که به شما امکان می دهد جنبه های مختلف یک APK ساخته شده را ارزیابی کنید. از آن برای یافتن کتابخانه های بومی استفاده کنید و از وجود کتابخانه های 64 بیتی اطمینان حاصل کنید.

1. Android Studio را باز کنید و هر پروژه ای را باز کنید .

2. از منو، Build > Analyze APK را انتخاب کنید…

   

3. APK مورد نظر برای ارزیابی را انتخاب کنید.

4. به پوشه lib نگاه کنید، که در صورت وجود، میزبان فایل های '.so' است. اگر هیچ کدام وجود ندارد، برنامه شما از دستگاه های 64 بیتی پشتیبانی می کند و نیازی به اقدام دیگری نیست. اگر armeabi-v7a یا x86 را می بینید، کتابخانه های 32 بیتی دارید.

5. بررسی کنید که آیا فایل های مشابه '.so' در پوشه arm64-v8a یا x86_64 دارید یا خیر.

   

6. اگر هیچ کتابخانه arm64-v8a یا x86_64 ندارید، فرآیند ساخت خود را به‌روزرسانی کنید تا شروع به ساخت و بسته‌بندی آن مصنوعات در APK کنید.

7. اگر قبلاً می‌بینید که هر دو کتابخانه بسته‌بندی شده‌اند، می‌توانید از آزمایش برنامه خود روی سخت‌افزار ۶۴ بیتی رد شوید.

با باز کردن فایل‌های APK به دنبال کتابخانه‌های بومی بگردید

فایل های APK مانند فایل های فشرده ساختار یافته اند. با خط فرمان یا هر ابزار استخراج دیگری، فایل APK را استخراج کنید. بسته به ابزار استخراج خود، ممکن است مجبور شوید نام فایل را به .zip تغییر دهید.

فایل‌های استخراج‌شده را با دنبال کردن دستورالعمل‌های بالا مرور کنید تا مشخص کنید آیا برنامه شما از دستگاه‌های ۶۴ بیتی پشتیبانی می‌کند یا خیر. می توانید مثال دستور زیر را از خط فرمان اجرا کنید:

:: 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 Studio یا Gradle بسازید

اکثر پروژه های اندروید استودیو از 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 ساخته شده است، می توانید با تغییر فایل Application.mk با استفاده از متغیر APP_ABI ، برای ABI های 64 بیتی بسازید:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

پورت کد 32 بیتی به 64 بیت

اگر کد شما از قبل بر روی دسکتاپ یا iOS اجرا می شود، نیازی به انجام کار اضافی برای اندروید ندارید. اگر این اولین باری است که کد شما برای یک سیستم 64 بیتی ساخته می شود، مشکل اصلی که باید به آن توجه کنید این است که نشانگرها دیگر در انواع اعداد صحیح 32 بیتی مانند int جا نمی شوند.

کدی را به‌روزرسانی کنید که نشانگرها را در انواعی مانند int ، unsigned یا uint32_t ذخیره می‌کند. در سیستم‌های یونیکس، long با اندازه نشانگر مطابقت دارد، اما این در ویندوز صادق نیست. درعوض، از انواع افشاگر قصد 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

کلاس های جاوا با فیلدهای int که نشانگرهای اشیاء C/C++ را نگه می دارند، همین مشکل را دارند. jint در منبع JNI خود جستجو کنید و مطمئن شوید که در سمت جاوا به long و در سمت C++ jlong ​​تغییر دهید.

اعلان تابع ضمنی برای کدهای 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 مانند تنظیم کنید، زیرا مشخص‌کننده‌های قالب سنتی به شما اجازه نمی‌دهند تا انواع ۶۴ بیتی را به گونه‌ای مشخص کنید که برای دستگاه‌های ۳۲ بیتی و ۶۴ بیتی درست باشد. ماکروهای PRI و SCN در <inttypes.h> این مشکل را حل می کنند، PRIxPTR و SCNxPTR برای نوشتن و خواندن نشانگرهای هگز. و PRId64 و SCNd64 برای نوشتن و خواندن مقادیر 64 بیتی به صورت قابل حمل.

هنگام جابجایی، ممکن است لازم باشد از 1ULL برای دریافت یک ثابت 64 بیتی برای جابجایی به جای استفاده از 1 که فقط 32 بیت است استفاده کنید.

اندازه کاهش با Android App Bundle افزایش می‌یابد

افزودن پشتیبانی معماری 64 بیتی به برنامه شما می تواند باعث افزایش اندازه APK شما شود. ما قویاً توصیه می‌کنیم از ویژگی Android App Bundle استفاده کنید تا تأثیر اندازه گنجاندن کدهای 32 و 64 بیتی در یک APK را به حداقل برسانید.

توسعه دهندگان بازی

سه موتور پرکاربرد از 64 بیت پشتیبانی می کنند:

• غیر واقعی از سال 2015
• Cocos2d از سال 2015
• وحدت از سال 2018

توسعه دهندگان یونیتی

به نسخه های قابل ارتقا ارتقا دهید

یونیتی با نسخه های 2018.2 و 2017.4.16 پشتیبانی 64 بیتی را ارائه می دهد.

اگر از نسخه‌ای از یونیتی استفاده می‌کنید که از 64 بیت پشتیبانی نمی‌کند، نسخه‌ای را که می‌خواهید به آن ارتقا دهید تعیین کنید و از راهنماهایی که Unity برای انتقال محیط شما ارائه می‌کند پیروی کنید، مطمئن شوید که برنامه شما به نسخه‌ای ارتقا یافته است که می‌تواند کتابخانه‌های 64 بیتی بسازد. یونیتی توصیه می کند با ارتقاء به آخرین نسخه LTS ویرایشگر به آخرین ویژگی ها و به روز رسانی ها دسترسی داشته باشید.

در اینجا نموداری وجود دارد که نسخه های مختلف Unity و کارهایی که باید انجام دهید را نشان می دهد:

تنظیمات ساخت را به کتابخانه های 64 بیتی خروجی تغییر دهید

اگر از نسخه‌ای از Unity استفاده می‌کنید که از کتابخانه‌های اندروید ۶۴ بیتی پشتیبانی می‌کند، می‌توانید با تنظیم تنظیمات ساخت، نسخه ۶۴ بیتی برنامه خود را ایجاد کنید. از پشتیبان IL2CPP به عنوان باطن اسکریپت خود استفاده کنید. برای راه اندازی پروژه Unity خود برای ساخت معماری 64 بیتی، موارد زیر را انجام دهید:

1. به Build Settings بروید و با تأیید اینکه نماد Unity در کنار Android در پلتفرم قرار دارد، مطمئن شوید که برای Android می‌سازید. 1. اگر نماد Unity در کنار پلتفرم اندروید نیست، Android را انتخاب کرده و Switch Platform را کلیک کنید.

2. روی تنظیمات پخش کننده کلیک کنید.

   

3. به پنل تنظیمات پخش کننده > تنظیمات اندروید > تنظیمات دیگر > پیکربندی بروید

4. Scripting Backend را روی IL2CPP تنظیم کنید.

5. کادر Target Architecture > ARM64 را انتخاب کنید.

   

6. طبق معمول بسازید!

توجه داشته باشید که ساختن برای ARM64 نیاز دارد که تمام دارایی های شما به طور خاص برای آن پلتفرم ساخته شود. دستورالعمل‌های Unity را برای کاهش اندازه APK دنبال کنید و برای کمک به کاهش این افزایش اندازه، از ویژگی Android App Bundle استفاده کنید.

سازگاری چند 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 خارجی تولید کند. این پرونده های Legacy .bc دیگر برای معماری های 64 بیتی پشتیبانی نمی شوند ، بنابراین حضور پرونده در APK شما باعث مشکل سازگاری می شود.

برای رفع مشکل ، هر پرونده .bc را در پروژه خود حذف کنید ، محیط خود را به build-tools-21.0.0 یا بعد از آن ارتقا دهید و renderscriptTargetApi را در استودیوی اندروید بر روی 21+ تنظیم کنید تا به کامپایلر بگویید که فایلهای .bc را منتشر نکند. سپس برنامه خود را بازسازی کنید ، برای پرونده های .bc بازرسی کنید و بارگذاری کنسول را بارگذاری کنید.

برنامه خود را روی سخت افزار 64 بیتی تست کنید

نسخه 64 بیتی برنامه شما باید همان کیفیت و ویژگی تنظیم شده به عنوان نسخه 32 بیتی را ارائه دهد. برنامه خود را آزمایش کنید تا مطمئن شوید که کاربران در آخرین دستگاه های 64 بیتی تجربه خوبی در برنامه شما دارند.

دستگاه های فقط 64 بیتی

هر زمان ممکن است ، توصیه می کنیم برنامه خود را در یک محیط سخت 64 بیتی با استفاده از یکی از گزینه های زیر آزمایش کنید:

• Google Pixel با تصویر سیستم فقط 64 بیتی
• شبیه ساز اندروید

Google Pixel با تصویر سیستم فقط 64 بیتی

برای تسهیل توسعه و آزمایش برنامه ، ما تصاویر سیستم ویژه ای را با یک محیط دقیق 64 بیتی برای برخی از دستگاه های پیکسل ارائه داده ایم. این تصاویر فقط 64 بیتی در ابتدا به طور همزمان با تصاویر سیستم استاندارد کارخانه برای نسخه های پیش نمایش Android 13 و 14 ارائه شده است ، اما می توانید هنگام تست برنامه خود برای سازگاری 64 بیتی ، از آنها استفاده کنید.

یک تصویر 64 بیتی دریافت کنید

مشابه تصاویر سیستم کارخانه ، می توانید با استفاده از ابزار Android Flash یا با چشمک زدن دستگاه خود به صورت دستی ، یک تصویر فقط 64 بیتی را به دستگاه خود بکشید ، همانطور که در بخش های بعدی توضیح داده شده است.

با استفاده از ابزار Android Flash ، دستگاه خود را فلش کنید

Android Flash Tool به شما امکان می دهد تا با اطمینان یک تصویر سیستم را به دستگاه پیکسل پشتیبانی شده خود فلش کنید. Android Flash Tool با هر مرورگر وب که از WebUSB پشتیبانی می کند ، مانند Chrome یا Edge 79+ کار می کند.

Android Flash Tool شما را از طریق فرایند چشمک زدن به دستگاه خود راهنمایی می کند-نیازی به نصب ابزار نیست-اما شما نیاز به باز کردن قفل دستگاه خود دارید و اشکال زدایی USB را در گزینه های توسعه دهنده فعال کنید . برای دستورالعمل های کامل ، به مستندات ابزار Android Flash مراجعه کنید.

دستگاه خود را از طریق USB وصل کنید ، سپس ، بسته به نوع تصویر سیستم مورد نظر برای فلش ، با استفاده از یکی از پیوندهای زیر به ابزار Android Flash بروید و راهنمای صفحه را دنبال کنید:

• Android 14 (بتا 5.2) تصاویر فقط 64 بیتی سیستم

  دستگاه مورد نظر خود را انتخاب کنید:

  • Pixel 4a (5G)
  • پیکسل 5
  • پیکسل 6
  • پیکسل 6 پرو

• Android 13 (QPR3 BETA 3.2) تصاویر فقط 64 بیتی سیستم

  دستگاه مورد نظر خود را انتخاب کنید:

  • Pixel 4a (5G)
  • پیکسل 5
  • پیکسل 6
  • پیکسل 6 پرو

دستگاه خود را به صورت دستی فلش کنید

همچنین می توانید آخرین تصویر سیستم را بارگیری کرده و به صورت دستی آن را به دستگاه خود فلش کنید. برای بارگیری تصویر سیستم برای دستگاه تست خود ، جدول زیر را مشاهده کنید. در صورت نیاز به کنترل دقیق بر محیط تست یا اگر نیاز به نصب مجدد مکرر دارید ، مانند هنگام انجام آزمایش خودکار ، یک دستگاه به صورت دستی یک دستگاه مفید است.

پس از تهیه نسخه پشتیبان از داده های دستگاه خود و بارگیری تصویر سیستم تطبیق ، می توانید تصویر را روی دستگاه خود فلش کنید .

می توانید در هر زمان به آخرین ساخت عمومی برگردید .

تصاویر کارخانه فقط 64 بیتی برای اندروید 14 (بتا 5.3)

این تصاویر یک محیط دقیق 64 بیتی برای آزمایش سازگاری برنامه 64 بیتی ارائه می دهند. این تنظیمات فقط 64 بیتی فقط برای استفاده از توسعه دهنده است.

تصاویر کارخانه فقط 64 بیتی برای Android 13 (QPR3 BETA 3.2)

این تصاویر یک محیط دقیق 64 بیتی برای آزمایش سازگاری برنامه 64 بیتی ارائه می دهند. این تنظیمات فقط 64 بیتی فقط برای استفاده از توسعه دهنده است.

بازگشت به یک ساختمان عمومی

شما می توانید از ابزار Android Flash برای چشمک زدن تصویر کارخانه استفاده کنید ، یا یک تصویر سیستم مشخصات کارخانه را از صفحه کارخانه برای صفحه Nexus و Pixel به دست آورید و سپس به صورت دستی آن را به دستگاه فلش کنید.

شبیه ساز اندروید

با شروع در Android 12 (سطح API سطح 31) ، تصاویر سیستم شبیه ساز اندرویدی فقط 64 بیتی هستند. با استفاده از یک تصویر سیستم با Android 12 (API سطح 31) یا بالاتر ، یک دستگاه مجازی Android (AVD) ایجاد کنید تا یک محیط دقیق 64 بیتی برای آزمایش برنامه بدست آورید.

سایر گزینه های دستگاه

اگر یکی از این دستگاه ها را ندارید یا نمی توانید از Android Emulator استفاده کنید ، بهترین گزینه بعدی شما استفاده از دستگاهی است که توانایی 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 در وابستگی های برنامه شما باشد.

سلیقه

اگر از کد بومی Loader SDK Soloader استفاده می کنید ، به V0.10.4 یا بالاتر بروزرسانی کنید. اگر برنامه شما از SDK هایی که به Soloader بستگی دارد ، استفاده می کند ، حتماً آخرین نسخه پایدار SDK های آسیب دیده را نیز به روز کنید.

Soloader v0.9.0 و پایین فرض کنید که کتابخانه های سیستم در /vendor/lib:/system/lib وجود دارند. این اشکال در دستگاه هایی مانند پیکسل 7 که در آن مسیر وجود دارد قابل مشاهده نیست ، اما این فرض باعث خرابی در دستگاه هایی می شود که فقط دارای کتابخانه های سیستم در /vendor/lib64:/system/lib64 هستند.

برای کسب اطلاعات بیشتر در مورد رفع این و سایر موارد ناشی از Soloader ، به پاسخ مربوطه در مرکز راهنمای Google مراجعه کنید.

OpenSSL

اگر از کتابخانه OpenSSL استفاده می کنید ، به OpenSSL 1.1.1i یا بالاتر بروزرسانی کنید. اگر برنامه شما از SDK هایی استفاده می کند که با استفاده از HTTPS یا SDK های دیگر که به OpenSSL بستگی دارند ، ارتباط برقرار می کنند ، حتماً آخرین نسخه SDK را که از نسخه جدیدتر OpenSSL استفاده می کند ، به روز کنید. اگر در دسترس نیست ، به ارائه دهنده SDK دسترسی پیدا کنید.

ARMV8.3 PAC با تأیید صحت نشانگرها در زمان اجرا ، یکپارچگی جریان کنترل سخت افزار را امکان پذیر می کند. نسخه های اولیه OpenSSL از این قابلیت ها به طور نادرست استفاده می کنند و باعث تصادفات زمان اجرا در کلیه دستگاه ها با پردازنده ها بر اساس ARMV8.3A و بالاتر می شوند.

برای کسب اطلاعات بیشتر در مورد رفع این و سایر موارد ناشی از OpenSSL ، به پاسخ مربوطه در مرکز راهنمای Google مراجعه کنید.

BTI

ARMV8.5 و دستورالعمل های هدف شاخه استفاده بالاتر (BTI) برای کمک به محافظت در برابر حملات JOP . نسخه های اولیه SDK های مبهم که به جبران خسارت های تصادفی از کتابخانه های ساخته شده با BTI می توانند باعث خراب شدن برنامه ها شوند. از آنجا که دستورالعمل ها به عنوان نکات رمزگذاری شده اند ، این اشکال در دستگاه هایی که از BTI پشتیبانی نمی کنند قابل مشاهده نیست.

منتشر کنید

وقتی احساس می کنید برنامه شما آماده است ، به صورت عادی منتشر کنید. مثل همیشه ، به دنبال بهترین شیوه ها برای استقرار برنامه خود باشید. ما توصیه می کنیم از آهنگ های آزمایش بسته استفاده کنید تا به تعداد محدودی از کاربران مراجعه کنید تا از کیفیت برنامه شما اطمینان حاصل کنید.

همانطور که هنگام بروزرسانی عمده ، حتماً قبل از انتشار برای مخاطبان بزرگتر ، روی دستگاه های 64 بیتی کاملاً آزمایش کرده اید.

برنامه های منتشر شده در Google Play نیاز به پشتیبانی از معماری های 64 بیتی دارند. اضافه کردن یک نسخه 64 بیتی از برنامه شما بهبود عملکرد را فراهم می کند و شما را برای دستگاه هایی با سخت افزار 64 بیتی تنظیم می کند.

مراحل زیر اطمینان حاصل می کند که برنامه 32 بیتی شما از دستگاه های 64 بیتی پشتیبانی می کند.

برنامه خود را ارزیابی کنید

اگر برنامه شما فقط از کد نوشته شده در زبان برنامه نویسی جاوا یا در کوتلین ، از جمله کلیه کتابخانه ها یا SDK ها استفاده می کند ، برنامه شما از دستگاه های 64 بیتی پشتیبانی می کند. اگر برنامه شما از هر کد بومی استفاده می کند ، یا مطمئن نیستید که این کار را انجام دهید ، برنامه خود را ارزیابی کنید.

بررسی سریع وضعیت

به کنسول نمایش بروید و به نسخه های موجود نگاهی بیندازید تا ببینید که آیا آنها سازگار هستند یا خیر.

کنسول بازی همچنین هشدارهایی را نشان می دهد که در صورت وجود هرگونه مشکل مربوط به نیاز 64 بیتی ، در مورد نسخه های پیش نویس شما اعمال می شود. تصویر زیر مثالی است.

اگر یک هشدار ظاهر شد ، مراحل زیر را مشاهده کنید تا برنامه شما با دستگاه های 64 بیتی سازگار باشد.

آیا برنامه شما از کد بومی استفاده می کند؟

برنامه شما در صورت استفاده از کد بومی استفاده می کند:

• از هر کد C/C ++ (بومی) در برنامه خود استفاده می کند.
• پیوندها با هر کتابخانه بومی شخص ثالث.
• توسط یک سازنده برنامه شخص ثالث ساخته شده است که از کتابخانه های بومی استفاده می کند.

آیا برنامه شما شامل کتابخانه های 64 بیتی است؟

ساختار پرونده APK خود را بازرسی کنید. هنگام ساخت ، APK با هر کتابخانه بومی مورد نیاز برنامه بسته بندی می شود. کتابخانه های بومی بر اساس ABI در پوشه های مختلف ذخیره می شوند. برای پشتیبانی از هر معماری 64 بیتی لازم نیست ، اما برای هر معماری بومی 32 بیتی که از شما پشتیبانی می کنید ، باید معماری 64 بیتی مربوطه را درج کنید.

برای معماری ARM ، کتابخانه های 32 بیتی در armeabi-v7a واقع شده اند. معادل 64 بیتی ARM64-V8A است.

برای معماری x86 ، برای 64 بیتی به دنبال x86 برای 32 بیتی و x86_64 باشید.

اطمینان حاصل کنید که در هر دو پوشه کتابخانه های بومی دارید. برای جمع بندی:

توجه داشته باشید که بسته به برنامه شما ، ممکن است دقیقاً همان مجموعه کتابخانه ها در هر پوشه باشد یا نباشد. هدف این است که اطمینان حاصل شود که برنامه شما به درستی در یک محیط 64 بیتی اجرا می شود.

در یک مورد معمولی ، یک APK یا بسته نرم افزاری که برای معماری 32 بیتی و 64 بیتی ساخته شده است دارای پوشه هایی برای هر دو ABI است که هر یک مجموعه مربوط به کتابخانه های بومی است. اگر هیچ حمایتی برای 64 بیتی وجود ندارد ، ممکن است یک پوشه 32 بیتی ABI را ببینید اما یک پوشه 64 بیتی نیست.

با استفاده از APK Analyzer به دنبال کتابخانه های بومی باشید

APK Analyzer ابزاری است که به شما امکان می دهد جنبه های مختلف یک APK ساخته شده را ارزیابی کنید. از آن برای یافتن هر کتابخانه بومی استفاده کنید و از حضور کتابخانه های 64 بیتی اطمینان حاصل کنید.

1. Android Studio را باز کنید و هر پروژه ای را باز کنید .

2. از منو ، Build> Analyze Apk را انتخاب کنید ...

   

3. APK را که می خواهید ارزیابی کنید انتخاب کنید.

4. در پوشه lib ، که در صورت وجود میزبان پرونده ها است ، نگاه کنید. اگر هیچ کدام وجود ندارد ، برنامه شما از دستگاه های 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 Studio یا Gradle بسازید

بیشتر پروژه های استودیوی اندرویدی از Gradle به عنوان سیستم ساخت اساسی استفاده می کنند ، بنابراین این بخش در مورد هر دو مورد اعمال می شود. برای فعال کردن ساخت برای کد بومی خود ، بسته به معماری که می خواهید از آنها پشتیبانی کنید ، به تنظیمات ndk.abifilters در پرونده "build.gradle" برنامه خود اضافه کنید: ARM64-V8A و/یا 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 '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 ساخته شده است ، می توانید با عبور از ARM64-V8A به پارامتر "-Dandroid_abi" برای ABI های 64 بیتی بسازید:

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

با NDK-Build بسازید

اگر برنامه شما با NDK-Build ساخته شده است ، می توانید با اصلاح پرونده "Application.mk" خود با استفاده از متغیر APP_ABI ، برای ABI های 64 بیتی بسازید:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

کد 32 بیتی بندر به 64 بیتی

اگر کد شما از قبل روی دسک تاپ یا iOS اجرا شده است ، نیازی به انجام کارهای اضافی برای Android نیست. اگر این اولین بار است که کد شما برای یک سیستم 64 بیتی ساخته شده است ، مسئله اصلی که باید به آن بپردازید این است که نشانگرها دیگر در انواع عدد صحیح 32 بیتی مانند int جای نمی گیرند.

کدی را که نشانگرها را در انواع مختلفی مانند int ، unsigned یا uint32_t ذخیره می کند ، به روز کنید. در سیستم های یونیکس ، long با اندازه اشاره گر مطابقت دارد ، اما این در ویندوز صادق نیست. درعوض ، از انواع قصد 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

کلاس های جاوا با زمینه های int که نشانگرها را به اشیاء C/C ++ نگه می دارند ، همین مشکل را دارند. jint در منبع JNI خود جستجو کنید و اطمینان حاصل کنید که در سمت long و 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) معادل (t) مانند sizeof(void*) جایگزین کنید.

اگر شما نیاز دارید که به طور مشروط کد های مختلفی را برای 32 بیتی از 64 بیتی کامپایل کنید ، می توانید #if defined(__LP64__) برای تفاوت های عمومی 32/64 استفاده کنید ، یا __arm__ ، __aarch64__ (ARM64) ، __i386__ (x86) ، و __x86_64__ برای معماری خاص پشتیبانی شده توسط و Architections.

رشته های قالب را برای توابع printf یا scanf تنظیم کنید ، زیرا مشخصات سنتی با فرمت سنتی به شما امکان نمی دهد انواع 64 بیتی را به گونه ای مشخص کنید که برای دستگاه های 32 بیتی و 64 بیتی صحیح باشد. ماکروهای PRI و SCN در <inttypes.h> این مشکل را حل کنید ، PRIxPTR و SCNxPTR برای نوشتن و خواندن نشانگرهای هگز. و PRId64 و SCNd64 برای نوشتن و خواندن مقادیر 64 بیتی به طور قابل توجهی.

در هنگام جابجایی ، ممکن است شما نیاز به استفاده از 1ULL داشته باشید تا به جای استفاده از 1 ، یک ثابت 64 بیتی برای جابجایی داشته باشید ، که فقط 32 بیت است.

افزایش اندازه با بسته نرم افزاری برنامه اندرویدی

اضافه کردن پشتیبانی معماری 64 بیتی به برنامه شما می تواند باعث رشد اندازه APK شما شود. ما به شدت توصیه می کنیم از ویژگی بسته نرم افزاری Android App استفاده کنید تا تأثیر اندازه آن شامل کد بومی 32 و 64 بیتی در همان APK باشد.

توسعه دهندگان بازی

سه موتور بیشترین استفاده از 64 بیتی پشتیبانی می کنند:

• غیر واقعی از سال 2015
• Cocos2d از سال 2015
• وحدت از سال 2018

توسعه دهندگان یونیتی

به نسخه های توانمند ارتقا دهید

وحدت پشتیبانی 64 بیتی با نسخه های 2018.2 و 2017.4.16 را ارائه می دهد.

اگر در نسخه ی وحدت هستید که از 64 بیتی پشتیبانی نمی کند ، نسخه ای را که می خواهید به آن ارتقا دهید تعیین کنید و راهنماهایی را که وحدت برای مهاجرت محیط شما فراهم می کند ، دنبال کنید ، اطمینان حاصل کنید که برنامه شما به نسخه ای که می تواند کتابخانه های 64 بیتی بسازد ، انجام دهید. Unity توصیه می کند با به روزرسانی به آخرین نسخه LTS ویرایشگر ، به آخرین ویژگی ها و به روزرسانی ها دسترسی داشته باشید.

در اینجا نمودار وجود دارد که نسخه های مختلف وحدت و آنچه را که باید انجام دهید را تشریح می کند:

تنظیمات ساخت را برای خروجی کتابخانه های 64 بیتی تغییر دهید

اگر از نسخه ی وحدت استفاده می کنید که از کتابخانه های اندرویدی 64 بیتی پشتیبانی می کند ، می توانید با تنظیم تنظیمات ساخت خود ، نسخه 64 بیتی از برنامه خود را تولید کنید. از Backend IL2CPP به عنوان پس زمینه اسکریپت خود استفاده کنید. برای تنظیم پروژه وحدت خود برای ساختن معماری 64 بیتی ، موارد زیر را انجام دهید:

1. با تأیید اینکه نماد وحدت در کنار Android در زیر سیستم عامل قرار دارد ، به ساخت تنظیمات بروید و اطمینان حاصل کنید که در حال ساخت Android هستید. 1. اگر نماد وحدت در کنار پلت فرم Android نیست ، Android را انتخاب کرده و روی پلت فرم سوئیچ کلیک کنید.

2. روی تنظیمات پخش کننده کلیک کنید.

   

3. به پانل تنظیمات پخش کننده> تنظیمات برای Android> تنظیمات دیگر> پیکربندی بروید

4. تنظیمات اسکریپت را به IL2CPP تنظیم کنید.

5. کادر هدف معماری Target> ARM64 را انتخاب کنید.

   

6. به صورت عادی بسازید!

توجه داشته باشید که ساختمان برای ARM64 به تمام دارایی های شما نیاز دارد که به طور خاص برای آن سکو ساخته شود. راهنمایی Unity را برای کاهش اندازه APK دنبال کنید و از ویژگی Bundle Android App استفاده کنید تا به کاهش این افزایش در اندازه کمک کنید.

انطباق چند APK و 64 بیتی

اگر از پشتیبانی چندگانه APK Google Play برای انتشار برنامه خود استفاده می کنید ، توجه داشته باشید که رعایت نیاز 64 بیتی در سطح انتشار ارزیابی می شود. با این حال ، نیاز 64 بیتی در مورد APKS یا بسته های برنامه ای که در دستگاه هایی که Android 9 Pie یا بعد از آن توزیع نمی شوند ، اعمال نمی شود.

اگر یکی از APK های شما به عنوان سازگار نیست ، اما یک نسخه قبلی است و نمی توان آن را به انطباق رساند ، یک استراتژی اضافه کردن یک ویژگی maxSdkVersion="27" در عنصر uses-sdk در آن آشکار APK است. این APK به دستگاه هایی که Android 9 Pie یا بعد از آن در حال اجرا هستند تحویل داده نمی شود و دیگر انطباق را مسدود نمی کند.

Renderscript و انطباق 64 بیتی

اگر برنامه شما از Renderscript استفاده می کند و با نسخه قبلی ابزارهای Android ساخته شده است ، ممکن است مشکلات مربوط به انطباق 64 بیتی را برای برنامه مشاهده کنید. با استفاده از ابزارهای ساخت زودتر از 21.0.0 ، کامپایلر ممکن است بیت کد را در یک پرونده .bc خارجی ایجاد کند. این پرونده های Legacy .bc دیگر برای معماری های 64 بیتی پشتیبانی نمی شوند ، بنابراین حضور پرونده در APK شما باعث مشکل سازگاری می شود.

برای رفع مشکل ، هر پرونده .bc را در پروژه خود حذف کنید ، محیط خود را به build-tools-21.0.0 یا بعد از آن ارتقا دهید و renderscriptTargetApi را در استودیوی اندروید بر روی 21+ تنظیم کنید تا به کامپایلر بگویید که فایلهای .bc را منتشر نکند. سپس برنامه خود را بازسازی کنید ، برای پرونده های .bc بازرسی کنید و بارگذاری کنسول را بارگذاری کنید.

برنامه خود را روی سخت افزار 64 بیتی تست کنید

نسخه 64 بیتی برنامه شما باید همان کیفیت و ویژگی تنظیم شده به عنوان نسخه 32 بیتی را ارائه دهد. برنامه خود را آزمایش کنید تا مطمئن شوید که کاربران در آخرین دستگاه های 64 بیتی تجربه خوبی در برنامه شما دارند.

دستگاه های فقط 64 بیتی

هر زمان ممکن است ، توصیه می کنیم برنامه خود را در یک محیط سخت 64 بیتی با استفاده از یکی از گزینه های زیر آزمایش کنید:

• Google Pixel با تصویر سیستم فقط 64 بیتی
• شبیه ساز اندروید

Google Pixel با تصویر سیستم فقط 64 بیتی

برای تسهیل توسعه و آزمایش برنامه ، ما تصاویر سیستم ویژه ای را با یک محیط دقیق 64 بیتی برای برخی از دستگاه های پیکسل ارائه داده ایم. این تصاویر فقط 64 بیتی در ابتدا به طور همزمان با تصاویر سیستم استاندارد کارخانه برای نسخه های پیش نمایش Android 13 و 14 ارائه شده است ، اما می توانید هنگام تست برنامه خود برای سازگاری 64 بیتی ، از آنها استفاده کنید.

یک تصویر 64 بیتی دریافت کنید

مشابه تصاویر سیستم کارخانه ، می توانید با استفاده از ابزار Android Flash یا با چشمک زدن دستگاه خود به صورت دستی ، یک تصویر فقط 64 بیتی را به دستگاه خود بکشید ، همانطور که در بخش های بعدی توضیح داده شده است.

با استفاده از ابزار Android Flash ، دستگاه خود را فلش کنید

Android Flash Tool به شما امکان می دهد تا با اطمینان یک تصویر سیستم را به دستگاه پیکسل پشتیبانی شده خود فلش کنید. Android Flash Tool با هر مرورگر وب که از WebUSB پشتیبانی می کند ، مانند Chrome یا Edge 79+ کار می کند.

Android Flash Tool شما را از طریق فرایند چشمک زدن به دستگاه خود راهنمایی می کند-نیازی به نصب ابزار نیست-اما شما نیاز به باز کردن قفل دستگاه خود دارید و اشکال زدایی USB را در گزینه های توسعه دهنده فعال کنید . برای دستورالعمل های کامل ، به مستندات ابزار Android Flash مراجعه کنید.

دستگاه خود را از طریق USB وصل کنید ، سپس ، بسته به نوع تصویر سیستم مورد نظر برای فلش ، با استفاده از یکی از پیوندهای زیر به ابزار Android Flash بروید و راهنمای صفحه را دنبال کنید:

• Android 14 (بتا 5.2) تصاویر فقط 64 بیتی سیستم

  دستگاه مورد نظر خود را انتخاب کنید:

  • Pixel 4a (5G)
  • پیکسل 5
  • پیکسل 6
  • پیکسل 6 پرو

• Android 13 (QPR3 BETA 3.2) تصاویر فقط 64 بیتی سیستم

  دستگاه مورد نظر خود را انتخاب کنید:

  • Pixel 4a (5G)
  • پیکسل 5
  • پیکسل 6
  • پیکسل 6 پرو

دستگاه خود را به صورت دستی فلش کنید

همچنین می توانید آخرین تصویر سیستم را بارگیری کرده و به صورت دستی آن را به دستگاه خود فلش کنید. برای بارگیری تصویر سیستم برای دستگاه تست خود ، جدول زیر را مشاهده کنید. در صورت نیاز به کنترل دقیق بر محیط تست یا اگر نیاز به نصب مجدد مکرر دارید ، مانند هنگام انجام آزمایش خودکار ، یک دستگاه به صورت دستی یک دستگاه مفید است.

پس از تهیه نسخه پشتیبان از داده های دستگاه خود و بارگیری تصویر سیستم تطبیق ، می توانید تصویر را روی دستگاه خود فلش کنید .

می توانید در هر زمان به آخرین ساخت عمومی برگردید .

تصاویر کارخانه فقط 64 بیتی برای اندروید 14 (بتا 5.3)

این تصاویر یک محیط دقیق 64 بیتی برای آزمایش سازگاری برنامه 64 بیتی ارائه می دهند. این تنظیمات فقط 64 بیتی فقط برای استفاده از توسعه دهنده است.

تصاویر کارخانه فقط 64 بیتی برای Android 13 (QPR3 BETA 3.2)

این تصاویر یک محیط دقیق 64 بیتی برای آزمایش سازگاری برنامه 64 بیتی ارائه می دهند. این تنظیمات فقط 64 بیتی فقط برای استفاده از توسعه دهنده است.

بازگشت به یک ساختمان عمومی

شما می توانید از ابزار Android Flash برای چشمک زدن تصویر کارخانه استفاده کنید ، یا یک تصویر سیستم مشخصات کارخانه را از صفحه کارخانه برای صفحه Nexus و Pixel به دست آورید و سپس به صورت دستی آن را به دستگاه فلش کنید.

شبیه ساز اندروید

با شروع در Android 12 (سطح API سطح 31) ، تصاویر سیستم شبیه ساز اندرویدی فقط 64 بیتی هستند. با استفاده از یک تصویر سیستم با Android 12 (API سطح 31) یا بالاتر ، یک دستگاه مجازی Android (AVD) ایجاد کنید تا یک محیط دقیق 64 بیتی برای آزمایش برنامه بدست آورید.

سایر گزینه های دستگاه

اگر یکی از این دستگاه ها را ندارید یا نمی توانید از Android Emulator استفاده کنید ، بهترین گزینه بعدی شما استفاده از دستگاهی است که توانایی 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 در وابستگی های برنامه شما باشد.

سلیقه

اگر از کد بومی Loader SDK Soloader استفاده می کنید ، به V0.10.4 یا بالاتر بروزرسانی کنید. اگر برنامه شما از SDK هایی که به Soloader بستگی دارد ، استفاده می کند ، حتماً آخرین نسخه پایدار SDK های آسیب دیده را نیز به روز کنید.

Soloader v0.9.0 و پایین فرض کنید که کتابخانه های سیستم در /vendor/lib:/system/lib وجود دارند. این اشکال در دستگاه هایی مانند پیکسل 7 که در آن مسیر وجود دارد قابل مشاهده نیست ، اما این فرض باعث خرابی در دستگاه هایی می شود که فقط دارای کتابخانه های سیستم در /vendor/lib64:/system/lib64 هستند.

برای کسب اطلاعات بیشتر در مورد رفع این و سایر موارد ناشی از Soloader ، به پاسخ مربوطه در مرکز راهنمای Google مراجعه کنید.

OpenSSL

اگر از کتابخانه OpenSSL استفاده می کنید ، به OpenSSL 1.1.1i یا بالاتر بروزرسانی کنید. اگر برنامه شما از SDK هایی استفاده می کند که با استفاده از HTTPS یا SDK های دیگر که به OpenSSL بستگی دارند ، ارتباط برقرار می کنند ، حتماً آخرین نسخه SDK را که از نسخه جدیدتر OpenSSL استفاده می کند ، به روز کنید. اگر در دسترس نیست ، به ارائه دهنده SDK دسترسی پیدا کنید.

ARMV8.3 PAC با تأیید صحت نشانگرها در زمان اجرا ، یکپارچگی جریان کنترل سخت افزار را امکان پذیر می کند. نسخه های اولیه OpenSSL از این قابلیت ها به طور نادرست استفاده می کنند و باعث تصادفات زمان اجرا در کلیه دستگاه ها با پردازنده ها بر اساس ARMV8.3A و بالاتر می شوند.

برای کسب اطلاعات بیشتر در مورد رفع این و سایر موارد ناشی از OpenSSL ، به پاسخ مربوطه در مرکز راهنمای Google مراجعه کنید.

BTI

ARMV8.5 و دستورالعمل های هدف شاخه استفاده بالاتر (BTI) برای کمک به محافظت در برابر حملات JOP . نسخه های اولیه SDK های مبهم که به جبران خسارت های تصادفی از کتابخانه های ساخته شده با BTI می توانند باعث خراب شدن برنامه ها شوند. از آنجا که دستورالعمل ها به عنوان نکات رمزگذاری شده اند ، این اشکال در دستگاه هایی که از BTI پشتیبانی نمی کنند قابل مشاهده نیست.

منتشر کنید

وقتی احساس می کنید برنامه شما آماده است ، به صورت عادی منتشر کنید. مثل همیشه ، به دنبال بهترین شیوه ها برای استقرار برنامه خود باشید. ما توصیه می کنیم از آهنگ های آزمایش بسته استفاده کنید تا به تعداد محدودی از کاربران مراجعه کنید تا از کیفیت برنامه شما اطمینان حاصل کنید.

همانطور که هنگام بروزرسانی عمده ، حتماً قبل از انتشار برای مخاطبان بزرگتر ، روی دستگاه های 64 بیتی کاملاً آزمایش کرده اید.

برنامه های منتشر شده در Google Play نیاز به پشتیبانی از معماری های 64 بیتی دارند. اضافه کردن یک نسخه 64 بیتی از برنامه شما بهبود عملکرد را فراهم می کند و شما را برای دستگاه هایی با سخت افزار 64 بیتی تنظیم می کند.

مراحل زیر اطمینان حاصل می کند که برنامه 32 بیتی شما از دستگاه های 64 بیتی پشتیبانی می کند.

برنامه خود را ارزیابی کنید

اگر برنامه شما فقط از کد نوشته شده در زبان برنامه نویسی جاوا یا در کوتلین ، از جمله کلیه کتابخانه ها یا SDK ها استفاده می کند ، برنامه شما از دستگاه های 64 بیتی پشتیبانی می کند. اگر برنامه شما از هر کد بومی استفاده می کند ، یا مطمئن نیستید که این کار را انجام دهید ، برنامه خود را ارزیابی کنید.

بررسی سریع وضعیت

به کنسول نمایش بروید و به نسخه های موجود نگاهی بیندازید تا ببینید که آیا آنها سازگار هستند یا خیر.

کنسول بازی همچنین هشدارهایی را نشان می دهد که در صورت وجود هرگونه مشکل مربوط به نیاز 64 بیتی ، در مورد نسخه های پیش نویس شما اعمال می شود. تصویر زیر مثالی است.

اگر یک هشدار ظاهر شد ، مراحل زیر را مشاهده کنید تا برنامه شما با دستگاه های 64 بیتی سازگار باشد.

آیا برنامه شما از کد بومی استفاده می کند؟

برنامه شما در صورت استفاده از کد بومی استفاده می کند:

• از هر کد C/C ++ (بومی) در برنامه خود استفاده می کند.
• پیوندها با هر کتابخانه بومی شخص ثالث.
• توسط یک سازنده برنامه شخص ثالث ساخته شده است که از کتابخانه های بومی استفاده می کند.

آیا برنامه شما شامل کتابخانه های 64 بیتی است؟

ساختار پرونده APK خود را بازرسی کنید. هنگام ساخت ، APK با هر کتابخانه بومی مورد نیاز برنامه بسته بندی می شود. کتابخانه های بومی بر اساس ABI در پوشه های مختلف ذخیره می شوند. برای پشتیبانی از هر معماری 64 بیتی لازم نیست ، اما برای هر معماری بومی 32 بیتی که از شما پشتیبانی می کنید ، باید معماری 64 بیتی مربوطه را درج کنید.

برای معماری ARM ، کتابخانه های 32 بیتی در armeabi-v7a واقع شده اند. معادل 64 بیتی ARM64-V8A است.

برای معماری x86 ، برای 64 بیتی به دنبال x86 برای 32 بیتی و x86_64 باشید.

اطمینان حاصل کنید که در هر دو پوشه کتابخانه های بومی دارید. برای جمع بندی:

توجه داشته باشید که بسته به برنامه شما ، ممکن است دقیقاً همان مجموعه کتابخانه ها در هر پوشه باشد یا نباشد. هدف این است که اطمینان حاصل شود که برنامه شما به درستی در یک محیط 64 بیتی اجرا می شود.

در یک مورد معمولی ، یک APK یا بسته نرم افزاری که برای معماری 32 بیتی و 64 بیتی ساخته شده است دارای پوشه هایی برای هر دو ABI است که هر یک مجموعه مربوط به کتابخانه های بومی است. اگر هیچ حمایتی برای 64 بیتی وجود ندارد ، ممکن است یک پوشه 32 بیتی ABI را ببینید اما یک پوشه 64 بیتی نیست.

با استفاده از APK Analyzer به دنبال کتابخانه های بومی باشید

APK Analyzer ابزاری است که به شما امکان می دهد جنبه های مختلف یک APK ساخته شده را ارزیابی کنید. از آن برای یافتن هر کتابخانه بومی استفاده کنید و از حضور کتابخانه های 64 بیتی اطمینان حاصل کنید.

1. Android Studio را باز کنید و هر پروژه ای را باز کنید .

2. از منو ، Build> Analyze Apk را انتخاب کنید ...

   

3. APK را که می خواهید ارزیابی کنید انتخاب کنید.

4. در پوشه lib ، که در صورت وجود میزبان پرونده ها است ، نگاه کنید. اگر هیچ کدام وجود ندارد ، برنامه شما از دستگاه های 64 بیتی پشتیبانی می کند و هیچ اقدام دیگری لازم نیست. اگر armeabi-v7a یا x86 را می بینید ، کتابخانه 32 بیتی دارید.

5. بررسی کنید که آیا پرونده های مشابه ".so" را در پوشه ARM64-V8A یا X86_64 مشابه دارید.

   

6. اگر هیچ کتابخانه ARM64-V8A یا X86_64 ندارید ، فرآیند ساخت خود را به روز کنید تا ساخت و بسته بندی آن مصنوعات موجود در APK خود را شروع کنید.

7. اگر می بینید که هر دو کتابخانه بسته بندی شده اند ، می توانید از آزمایش برنامه خود بر روی سخت افزار 64 بیتی استفاده کنید.

Look for native libraries by unzipping APKs

APK files are structured like zip files. With the command line or any other extraction tool, extract the APK file. Depending on your extraction tool, you might have to rename the file to .zip.

Browse the files that are extracted, following the guidance above to determine if your app supports 64-bit devices. You can run the following command example from the command line:

:: 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

Note in this example the presence of armeabi-v7a and arm64-v8a libraries, which means the app supports 64-bit architectures.

Build your app with 64-bit libraries

The following instructions outline how to build 64-bit libraries. Note that these steps only cover building code and libraries that you are able to build from source.

Build with Android Studio or Gradle

Most Android Studio projects use Gradle as the underlying build system, so this section applies to both cases. To enable builds for your native code, add arm64-v8a and/or x86_64 , depending on the architectures you want to support, to the ndk.abiFilters setting in your app's 'build.gradle' file:

// 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

If your app is built using CMake , you can build for 64-bit ABIs by passing the arm64-v8a into the '-DANDROID_ABI' parameter:

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

Build with ndk-build

If your app is built with ndk-build , you can build for 64-bit ABIs by modifying your 'Application.mk' file using the APP_ABI variable:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

Port 32-bit code to 64-bit

If your code already runs on the desktop or iOS, you shouldn't need to do any extra work for Android. If this is the first time your code has been built for a 64-bit system, the main issue you must address is that pointers no longer fit in 32-bit integer types like int .

Update code that stores pointers in types such as int , unsigned , or uint32_t . On Unix systems, long matches the pointer size, but this isn't true on Windows. Instead, use the intention-revealing types uintptr_t or intptr_t . To store the difference between two pointers, use the ptrdiff_t type.

You should always prefer the specific, fixed-width integer types defined in <stdint.h> rather than non fixed-width types such as int or long , even for non-pointers.

Use the following compiler flags to catch cases where your code is incorrectly converting between pointers and integers:

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

Java classes with int fields that hold pointers to C/C++ objects have the same problem. Search for jint in your JNI source and ensure that you switch to long on the Java side and jlong on the C++ side.

Implicit function declarations are a lot more dangerous for 64-bit code. C/C++ assume that the return type of an implicitly declared function (that is, a function that the compiler hasn't seen a declaration for) is int . If the actual return type of your function is a pointer, this works fine on a 32-bit system where your pointer fits into an int. However, on a 64-bit system, the compiler drops the top half of your pointer. به عنوان مثال:

// 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`.

The following compiler flag turns implicit function declaration warnings into errors so that you can find and fix this problem more easily:

-Werror=implicit-function-declaration

If you have inline assembler, rewrite it or use a plain C/C++ implementation.

If you have hard-coded sizes of types (8 or 16 bytes, for example), replace them with the equivalent sizeof(T) expression, such as sizeof(void*) .

If you need to conditionally compile different code for 32-bit than 64-bit, you can use the #if defined(__LP64__) for generic 32/64 differences, or __arm__ , __aarch64__ (arm64), __i386__ (x86), and __x86_64__ for the specific architectures supported by Android.

Adjust format strings for printf or scanf -like functions, as the traditional format specifiers don't allow you to specify 64-bit types in a way that's correct for both 32-bit and 64-bit devices. The PRI and SCN macros in <inttypes.h> solve this problem, PRIxPTR and SCNxPTR for writing and reading hex pointers; and PRId64 and SCNd64 for writing and reading 64-bit values portably.

When shifting, you may need to use 1ULL to get a 64-bit constant to shift rather than using 1 , which is only 32 bits.

Mitigate size increases with Android App Bundle

Adding 64-bit architecture support to your app can cause your APK size to grow. We strongly recommend taking advantage of the Android App Bundle feature to minimize the size impact of including both 32- and 64-bit native code in the same APK.

توسعه دهندگان بازی

The three most-used engines support 64-bit:

• Unreal since 2015
• Cocos2d since 2015
• Unity since 2018

توسعه دهندگان یونیتی

Upgrade to capable versions

Unity provides 64-bit support with versions 2018.2 and 2017.4.16 .

If you are on a version of Unity that does not support 64-bit, determine the version you want to upgrade to and follow the guides that Unity provides to migrate your environment, ensuring your app is upgraded to a version that can build 64-bit libraries. Unity recommends you have access to the latest features and updates by upgrading to the latest LTS version of the editor.

Here's a chart that outlines the various Unity versions and what you should do:

Change build settings to output 64-bit libraries

If you are using a version of Unity that supports 64-bit Android libraries, you can generate a 64-bit version of your app by adjusting your build settings. Use the IL2CPP backend as your Scripting Backend. To set up your Unity project to build 64-bit architecture, do the following:

1. Go to Build Settings and ensure you are building for Android by verifying that the Unity symbol is next to Android under Platform . 1. If the Unity symbol is not next to the Android platform, select Android and click Switch Platform.

2. Click Player settings.

   

3. Navigate to Player Settings Panel > Settings for Android > Other settings > Configuration

4. Set Scripting Backend to IL2CPP.

5. Select the Target Architecture > ARM64 checkbox.

   

6. Build as normal!

Note that building for ARM64 requires all your assets to be built specifically for that platform. Follow Unity's guidance for reducing APK size, and consider taking advantage of the Android App Bundle feature to help mitigate this increase in size.

Multi-APK and 64-bit compliance

If you are using Google Play's multiple-APK support to publish your app, note that compliance with the 64-bit requirement is evaluated at the release level. However, the 64-bit requirement does not apply to APKs or app bundles that are not distributed to devices running Android 9 Pie or later.

If one of your APKs is marked as not being compliant, but is an earlier version and it's not possible to bring it into compliance, one strategy is to add a maxSdkVersion="27" attribute in the uses-sdk element in that APK's manifest. This APK isn't delivered to devices running Android 9 Pie or later, and no longer blocks compliance.

RenderScript and 64-bit compliance

If your app uses RenderScript and was built with an earlier version of the Android tools, you might see 64-bit compliance issues for the app. With build tools earlier than 21.0.0, the compiler may generate bitcode into an external .bc file. These legacy .bc files are no longer supported for 64-bit architectures, so the presence of the file in your APK causes the compliance issue.

To fix the issue, remove any .bc files in your project, upgrade your environment to build-tools-21.0.0 or later, and set the renderscriptTargetApi in Android Studio to 21+, to tell the compiler to not emit .bc files. Then, rebuild your app, inspect for .bc files, and upload to Play Console.

Test your app on 64-bit hardware

The 64-bit version of your app should offer the same quality and feature set as the 32-bit version. Test your app to make sure that users on the latest 64-bit devices have a great experience in your app.

64-bit-only devices

Whenever possible, we recommend testing your app in a strict 64-bit-only environment using one of the following options:

• Google Pixel with a 64-bit-only system image
• شبیه ساز اندروید

Google Pixel with a 64-bit-only system image

To facilitate app development and testing, we've provided special system images with a strict 64-bit-only environment for some Pixel devices. These 64-bit-only images were originally provided concurrently with standard factory system images for the Android 13 and 14 preview releases, but you can continue to use them as you test your app for 64-bit compatibility.

Get a 64-bit-only image

Similar to factory system images, you can flash a 64-bit-only image to your device using the Android Flash Tool or by flashing your device manually , as described in the following sections.

Flash your device using Android Flash Tool

Android Flash Tool lets you securely flash a system image to your supported Pixel device. Android Flash Tool works with any Web browser that supports WebUSB, such as Chrome or Edge 79+.

Android Flash Tool guides you step-by-step through the process of flashing your device—there's no need to have tools installed—but you do need to unlock your device and enable USB Debugging in Developer options . For complete instructions, see the Android Flash Tool documentation .

Connect your device over USB, then, depending on the type of system image you want to flash, navigate to Android Flash Tool using one of the following links and follow the onscreen guidance:

• Android 14 (Beta 5.2) 64-bit-only system images

  Select the device you are trying to flash:

  • Pixel 4a (5G)
  • پیکسل 5
  • پیکسل 6
  • پیکسل 6 پرو

• Android 13 (QPR3 Beta 3.2) 64-bit-only system images

  Select the device you are trying to flash:

  • Pixel 4a (5G)
  • پیکسل 5
  • پیکسل 6
  • پیکسل 6 پرو

Flash your device manually

You can also download the latest system image and manually flash it to your device. See the following table to download the system image for your test device. Manually flashing a device is useful if you need precise control over the test environment or if you need to reinstall frequently, such as when performing automated testing.

After you back up your device data and download the matching system image, you can flash the image onto your device .

You can choose to return to the latest public build at any time.

64-bit-only factory images for Android 14 (Beta 5.3)

These images provide a strict 64-bit-only environment for testing 64-bit app compatibility. These 64-bit-only configurations are for developer use only.

64-bit-only factory images for Android 13 (QPR3 Beta 3.2)

These images provide a strict 64-bit-only environment for testing 64-bit app compatibility. These 64-bit-only configurations are for developer use only.

Return to a public build

You can either use the Android Flash Tool to flash the factory image , or obtain a factory spec system image from the Factory Images for Nexus and Pixel Devices page and then manually flash it to the device.

شبیه ساز اندروید

Starting in Android 12 (API level 31), Android Emulator system images are 64-bit only. Create an Android Virtual Device (AVD) using a system image with Android 12 (API level 31) or higher to get a strict 64-bit-only environment for app testing.

Other device options

If you don't have one of these devices or can't use the Android Emulator, your next best option is to use a device that is 64-bit capable, such as a Google Pixel or other recent flagship devices from other device manufacturers.

Install and test your app

The easiest way to test your APK is to install the app using Android Debug Bridge (adb). In most cases, you can supply --abi as a parameter to indicate which libraries to install to the device. This installs the app with only the 64-bit libraries on the device.

:: 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

Once you have installed successfully, test your app like you normally would to ensure the quality is the same as the 32-bit version.

Check for known compatibility issues

As you test, check your app for the following issues that affect apps when running on 64-bit devices. Even if your app doesn't depend on the affected libraries directly, third-party libraries and SDKs in your app's dependencies might.

SoLoader

If you are using the native code loader SDK SoLoader , update to v0.10.4 or higher. If your app uses SDKs that depend on SoLoader, make sure to also update to the latest stable version of the affected SDKs.

SoLoader v0.9.0 and lower assume that system libraries are present in /vendor/lib:/system/lib . This bug is not observable in devices like the Pixel 7 where the path exists, but this assumption causes crashes in devices that only have system libraries in /vendor/lib64:/system/lib64 .

For more information on fixing this and other issues caused by SoLoader, see the corresponding answer in the Google Help Center .

OpenSSL

If you are using the OpenSSL library, update to OpenSSL 1.1.1i or higher. If your app uses SDKs that provide communication using HTTPS, or other SDKs that depend on OpenSSL, make sure to also update to the latest version of the SDK that uses a newer OpenSSL version. Reach out to the SDK provider if one is not available.

ARMv8.3 PAC enables hardware-assisted control flow integrity by authenticating pointers at runtime. Earlier versions of OpenSSL use these capabilities incorrectly, causing runtime crashes in all devices with processors based on ARMv8.3a and above.

For more information on fixing this and other issues caused by OpenSSL, see the corresponding answer in the Google Help Center .

BTI

ARMv8.5 and higher use Branch Target Instructions (BTIs) to help protect against JOP attacks . Earlier versions of obfuscation SDKs that branch into random offsets of libraries built with BTI can cause apps to crash. Since the instructions are encoded as HINTs , this bug is not observable in devices that don't support BTI.

منتشر کنید

When you feel like your app is ready, publish as normal. As always, continue to follow the best practices for deploying your app. We recommend taking advantage of closed testing tracks to rollout to a limited number of users to ensure the quality of your app is consistent.

As when rolling out an major update, make sure you have thoroughly tested on 64-bit-capable devices before publishing to a larger audience.