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

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

مراحل زیر تضمین می‌کند که برنامه ۳۲ بیتی شما از دستگاه‌های ۶۴ بیتی پشتیبانی می‌کند.

اپلیکیشن خود را ارزیابی کنید

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

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

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

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

اگر هشداری ظاهر شد، مراحل زیر را برای سازگاری برنامه خود با دستگاه‌های ۶۴ بیتی دنبال کنید.

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

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

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

آیا برنامه شما شامل کتابخانه‌های ۶۴ بیتی است؟

ساختار فایل APK خود را بررسی کنید. پس از ساخت، APK با هر کتابخانه بومی مورد نیاز برنامه بسته‌بندی می‌شود. کتابخانه‌های بومی بر اساس ABI در پوشه‌های مختلف ذخیره می‌شوند. لازم نیست از هر معماری ۶۴ بیتی پشتیبانی کند، اما برای هر معماری ۳۲ بیتی بومی که پشتیبانی می‌کنید، باید معماری ۶۴ بیتی مربوطه را نیز درج کنید.

برای معماری ARM ، کتابخانه‌های ۳۲ بیتی در armeabi-v7a قرار دارند. معادل ۶۴ بیتی آن arm64-v8a است.

برای معماری x86 ، برای نسخه ۳۲ بیتی به دنبال x86 و برای نسخه ۶۴ بیتی به دنبال x86_64 باشید.

مطمئن شوید که کتابخانه‌های بومی را در هر دوی این پوشه‌ها دارید. برای خلاصه:

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

در یک مورد معمول، یک APK یا بسته نرم‌افزاری که برای معماری‌های ۳۲ بیتی و ۶۴ بیتی ساخته شده است، پوشه‌هایی برای هر دو ABI دارد که هر کدام مجموعه‌ای از کتابخانه‌های بومی مربوطه را دارند. اگر پشتیبانی از ۶۴ بیتی وجود نداشته باشد، ممکن است یک پوشه ABI 32 بیتی را ببینید اما یک پوشه ۶۴ بیتی را نبینید.

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

تحلیلگر APK ابزاری است که به شما امکان می‌دهد جنبه‌های مختلف یک APK ساخته شده را ارزیابی کنید. از آن برای یافتن هرگونه کتابخانه بومی و اطمینان از وجود کتابخانه‌های ۶۴ بیتی استفاده کنید.

1. اندروید استودیو را باز کنید و هر پروژه‌ای را که می‌خواهید باز کنید .

2. از منو، گزینه ساخت > تجزیه و تحلیل APK را انتخاب کنید…

   

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

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

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 توجه کنید، که به این معنی است که برنامه از معماری‌های ۶۴ بیتی پشتیبانی می‌کند.

برنامه خود را با کتابخانه‌های ۶۴ بیتی بسازید

دستورالعمل‌های زیر نحوه ساخت کتابخانه‌های ۶۴ بیتی را شرح می‌دهند. توجه داشته باشید که این مراحل فقط شامل ساخت کد و کتابخانه‌هایی می‌شود که می‌توانید از منبع بسازید.

ساخت با اندروید استودیو یا گریدل

اکثر پروژه‌های اندروید استودیو از 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 ساخته شده است، می‌توانید با ارسال 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 های ۶۴ بیتی بسازید:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

تبدیل کد ۳۲ بیتی به ۶۴ بیتی

اگر کد شما از قبل روی دسکتاپ یا iOS اجرا می‌شود، نیازی به انجام کار اضافی برای اندروید ندارید. اگر این اولین باری است که کد شما برای یک سیستم ۶۴ بیتی ساخته می‌شود، مشکل اصلی که باید به آن رسیدگی کنید این است که اشاره‌گرها دیگر در انواع صحیح ۳۲ بیتی مانند 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++ را در خود نگه می‌دارند، همین مشکل را دارند. در منبع JNI خود به دنبال jint بگردید و مطمئن شوید که در سمت جاوا به long و در سمت C++ jlong ​​تغییر می‌دهید.

اعلان‌های ضمنی تابع برای کد ۶۴ بیتی بسیار خطرناک‌تر هستند. زبان‌های برنامه‌نویسی C/C++ فرض می‌کنند که نوع بازگشتی یک تابع اعلان ضمنی (یعنی تابعی که کامپایلر اعلانی برای آن ندیده است) int ) است. اگر نوع بازگشتی واقعی تابع شما یک اشاره‌گر باشد، این روش در یک سیستم ۳۲ بیتی که اشاره‌گر شما در یک عدد صحیح قرار می‌گیرد، به خوبی کار می‌کند. با این حال، در یک سیستم ۶۴ بیتی، کامپایلر نیمه بالایی اشاره‌گر شما را حذف می‌کند. به عنوان مثال:

// 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++ استفاده کنید.

اگر اندازه‌های نوع‌ها (مثلاً ۸ یا ۱۶ بایت) به صورت پیش‌فرض در کد شما وجود دارد، آن‌ها را با عبارت معادل sizeof(T) مانند sizeof(void*) جایگزین کنید.

اگر نیاز دارید که به صورت مشروط کد متفاوتی را برای معماری ۳۲ بیتی نسبت به ۶۴ بیتی کامپایل کنید، می‌توانید از #if defined(__LP64__) برای تفاوت‌های عمومی ۳۲/۶۴ بیتی، یا __arm__ ، __aarch64__ (arm64)، __i386__ (x86) و __x86_64__ برای معماری‌های خاص پشتیبانی شده توسط اندروید استفاده کنید.

رشته‌های قالب‌بندی را برای توابع printf یا scanf -like تنظیم کنید، زیرا مشخص‌کننده‌های قالب‌بندی سنتی به شما اجازه نمی‌دهند انواع ۶۴ بیتی را به روشی که برای دستگاه‌های ۳۲ بیتی و ۶۴ بیتی صحیح باشد، مشخص کنید. ماکروهای PRI و SCN در <inttypes.h> این مشکل را حل می‌کنند، PRIxPTR و SCNxPTR برای نوشتن و خواندن اشاره‌گرهای هگز؛ و PRId64 و SCNd64 برای نوشتن و خواندن مقادیر ۶۴ بیتی به صورت قابل حمل.

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

با استفاده از Android App Bundle از افزایش حجم جلوگیری کنید

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

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

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

• غیرواقعی از سال ۲۰۱۵
• Cocos2d از سال ۲۰۱۵
• یونیتی از سال ۲۰۱۸

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

ارتقا به نسخه‌های سازگار

یونیتی با نسخه‌های ۲۰۱۸.۲ و ۲۰۱۷.۴.۱۶ از پردازنده‌های ۶۴ بیتی پشتیبانی می‌کند.

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

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

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

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

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

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

   

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

4. بخش اسکریپت‌نویسی (Scripting Backend) را روی IL2CPP تنظیم کنید.

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

   

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

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

سازگاری با فایل‌های APK چندگانه و ۶۴ بیتی

اگر از پشتیبانی چند-APK گوگل پلی برای انتشار برنامه خود استفاده می‌کنید، توجه داشته باشید که رعایت الزامات ۶۴ بیتی در سطح انتشار ارزیابی می‌شود. با این حال، الزامات ۶۴ بیتی برای APKها یا بسته‌های برنامه‌ای که برای دستگاه‌های دارای اندروید ۹ پای یا بالاتر توزیع نشده‌اند، اعمال نمی‌شود.

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

RenderScript و سازگاری با معماری ۶۴ بیتی

اگر برنامه شما از RenderScript استفاده می‌کند و با نسخه‌های قدیمی‌تر ابزارهای اندروید ساخته شده است، ممکن است با مشکلات انطباق با معماری ۶۴ بیتی برای برنامه مواجه شوید. با ابزارهای ساخت قدیمی‌تر از ۲۱.۰.۰، کامپایلر ممکن است بیت‌کد را در یک فایل خارجی .bc تولید کند. این فایل‌های .bc قدیمی دیگر برای معماری‌های ۶۴ بیتی پشتیبانی نمی‌شوند، بنابراین وجود این فایل در APK شما باعث مشکل انطباق می‌شود.

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

برنامه خود را روی سخت‌افزار ۶۴ بیتی آزمایش کنید

نسخه ۶۴ بیتی برنامه شما باید همان کیفیت و ویژگی‌های نسخه ۳۲ بیتی را ارائه دهد. برنامه خود را آزمایش کنید تا مطمئن شوید که کاربران در جدیدترین دستگاه‌های ۶۴ بیتی تجربه خوبی در برنامه شما دارند.

دستگاه‌های فقط ۶۴ بیتی

هر زمان که ممکن باشد، توصیه می‌کنیم برنامه خود را در یک محیط کاملاً ۶۴ بیتی با استفاده از یکی از گزینه‌های زیر آزمایش کنید:

• گوگل پیکسل با یک ایمیج سیستمی فقط ۶۴ بیتی
• شبیه‌ساز اندروید

گوگل پیکسل با یک ایمیج سیستمی فقط ۶۴ بیتی

برای تسهیل توسعه و آزمایش برنامه، ما تصاویر سیستمی ویژه‌ای را با محیطی کاملاً ۶۴ بیتی برای برخی از دستگاه‌های پیکسل ارائه کرده‌ایم. این تصاویر ۶۴ بیتی در ابتدا همزمان با تصاویر سیستمی استاندارد کارخانه‌ای برای نسخه‌های پیش‌نمایش اندروید ۱۳ و ۱۴ ارائه می‌شدند، اما می‌توانید هنگام آزمایش برنامه خود برای سازگاری با ۶۴ بیتی، به استفاده از آنها ادامه دهید.

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

مشابه ایمیج‌های سیستم عامل کارخانه، می‌توانید یک ایمیج فقط ۶۴ بیتی را با استفاده از ابزار فلش اندروید یا با فلش کردن دستی دستگاه خود ، همانطور که در بخش‌های بعدی توضیح داده شده است، روی دستگاه خود فلش کنید.

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

ابزار فلش اندروید به شما امکان می‌دهد تا یک فایل ایمیج سیستم را به صورت ایمن روی دستگاه پیکسل پشتیبانی‌شده خود فلش کنید. ابزار فلش اندروید با هر مرورگر وبی که از WebUSB پشتیبانی می‌کند، مانند کروم یا اج ۷۹+، کار می‌کند.

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

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

• ایمیج‌های سیستمی فقط ۶۴ بیتی اندروید ۱۴ (بتا ۵.۲)

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

  • پیکسل ۴a (5G)
  • پیکسل ۵
  • پیکسل ۶
  • پیکسل ۶ پرو

• ایمیج‌های سیستمی فقط ۶۴ بیتی اندروید ۱۳ (QPR3 بتا ۳.۲)

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

  • پیکسل ۴a (5G)
  • پیکسل ۵
  • پیکسل ۶
  • پیکسل ۶ پرو

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

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

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

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

ایمیج‌های کارخانه‌ای فقط ۶۴ بیتی برای اندروید ۱۴ (بتا ۵.۳)

این ایمیج‌ها یک محیط کاملاً ۶۴ بیتی را برای آزمایش سازگاری برنامه‌های ۶۴ بیتی فراهم می‌کنند. این پیکربندی‌های ۶۴ بیتی فقط برای استفاده توسعه‌دهندگان است.

ایمیج‌های کارخانه‌ای فقط ۶۴ بیتی برای اندروید ۱۳ (QPR3 Beta 3.2)

این ایمیج‌ها یک محیط کاملاً ۶۴ بیتی را برای آزمایش سازگاری برنامه‌های ۶۴ بیتی فراهم می‌کنند. این پیکربندی‌های ۶۴ بیتی فقط برای استفاده توسعه‌دهندگان است.

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

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

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

از اندروید ۱۲ (سطح API ۳۱)، ایمیج‌های سیستمی شبیه‌ساز اندروید فقط ۶۴ بیتی هستند. با استفاده از ایمیج سیستمی اندروید ۱۲ (سطح API ۳۱) یا بالاتر ، یک دستگاه مجازی اندروید (AVD) ایجاد کنید تا یک محیط کاملاً ۶۴ بیتی برای آزمایش برنامه داشته باشید.

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

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

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

ساده‌ترین راه برای آزمایش APK شما، نصب برنامه با استفاده از Android Debug Bridge (adb) است. در بیشتر موارد، می‌توانید --abi به عنوان پارامتری برای مشخص کردن کتابخانه‌هایی که باید روی دستگاه نصب شوند، ارائه دهید. این کار برنامه را فقط با کتابخانه‌های ۶۴ بیتی روی دستگاه نصب می‌کند.

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

پس از نصب موفقیت‌آمیز، برنامه خود را مانند همیشه آزمایش کنید تا مطمئن شوید کیفیت آن مشابه نسخه ۳۲ بیتی است.

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

هنگام آزمایش، برنامه خود را از نظر مشکلات زیر که هنگام اجرا روی دستگاه‌های ۶۴ بیتی بر برنامه‌ها تأثیر می‌گذارند، بررسی کنید. حتی اگر برنامه شما مستقیماً به کتابخانه‌های آسیب‌دیده وابسته نباشد، کتابخانه‌های شخص ثالث و SDKهای موجود در وابستگی‌های برنامه شما ممکن است این مشکلات را ایجاد کنند.

سولودر

اگر از SDK SoLoader برای بارگذاری کد بومی استفاده می‌کنید، آن را به نسخه ۰.۱۰.۴ یا بالاتر به‌روزرسانی کنید. اگر برنامه شما از SDKهایی استفاده می‌کند که به SoLoader وابسته هستند، حتماً آن را به آخرین نسخه پایدار SDKهای آسیب‌دیده نیز به‌روزرسانی کنید.

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

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

اوپن‌اس‌اس‌ال

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

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

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

بی تی آی

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

منتشر کردن

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

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