پشتیبانی از معماری های 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__ استفاده کنید. معماری های خاص پشتیبانی شده توسط اندروید

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

منتشر کنید

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

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