‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

תמיכה בארכיטקטורות של 64 ביט

אפליקציות שמתפרסמות ב-Google Play צריכות לתמוך בארכיטקטורות של 64 ביט. הוספת גרסת 64 ביט של האפליקציה משפרת את הביצועים ומאפשרת לכם להגדיר את האפליקציה למכשירים עם חומרה של 64 ביט בלבד.

השלבים הבאים מבטיחים שהאפליקציה שלכם בגרסת 32 ביט תומכת במכשירי 64 ביט.

בדיקת האפליקציה

אם האפליקציה שלכם משתמשת רק בקוד שנכתב בשפת התכנות Java או ב-Kotlin, כולל כל הספריות או ערכות ה-SDK, האפליקציה תומכת במכשירי 64 ביט. אם האפליקציה משתמשת בקוד Native, או אם אתם לא בטוחים אם היא משתמשת בו, אתם צריכים לבדוק את האפליקציה.

בדיקת סטטוס מהירה

עוברים אל Play Console ובודקים אם הגרסאות הקיימות עומדות בדרישות.

ב-Play Console מוצגות גם אזהרות שרלוונטיות לגרסאות הטיוטה שלכם, אם יש בעיות שקשורות לדרישה ל-64 ביט. התמונה הבאה היא דוגמה.

אם מופיעה התראה, צריך לפעול לפי השלבים הבאים כדי שהאפליקציה תהיה תואמת למכשירי 64 ביט.

האם באפליקציה שלך נעשה שימוש בקוד Native?

האפליקציה משתמשת בקוד Native אם היא:

משתמשת בקוד C/C++‎ (מקורי) באפליקציה.
קישורים לספריות Native של צד שלישי.
האפליקציה נוצרה על ידי כלי של צד שלישי לפיתוח אפליקציות שמשתמש בספריות Native.

האם האפליקציה כוללת ספריות של 64 ביט?

בודקים את המבנה של קובץ ה-APK. כשיוצרים את ה-APK, הוא נארז עם כל ספריות ה-Native שהאפליקציה צריכה. ספריות ה-Native מאוחסנות בתיקיות שונות בהתאם ל-ABI. לא צריך לתמוך בכל ארכיטקטורת 64 ביט, אבל לכל ארכיטקטורת 32 ביט מקורית שאתם תומכים בה, אתם צריכים לכלול את ארכיטקטורת 64 הביט התואמת.

בארכיטקטורת ARM, הספריות של 32 ביט נמצאות ב-armeabi-v7a. הגרסה המקבילה של 64 ביט היא arm64-v8a.

לארכיטקטורת x86, מחפשים את x86 ל-32 ביט ואת x86_64 ל-64 ביט.

חשוב לוודא שיש ספריות Native בשתי התיקיות האלה. לסיכום:

פלטפורמה	תיקיית ספריות של 32 ביט	תיקיית ספריות של 64 ביט
דריכה	`lib/armeabi-v7a`	`lib/arm64-v8a`
x86	`lib/x86`	`lib/x86_64`

שימו לב: בהתאם לאפליקציה, יכול להיות שבכל תיקייה תהיה קבוצה זהה של ספריות, ויכול להיות שלא. המטרה היא לוודא שהאפליקציה פועלת כמו שצריך בסביבה של 64 ביט בלבד.

במקרה רגיל, חבילת APK או חבילת App Bundle שמיועדת לארכיטקטורות של 32 ביט ו-64 ביט כוללת תיקיות לשני ממשקי ה-ABI, ולכל אחד מהם יש קבוצה תואמת של ספריות Native. אם אין תמיכה ב-64 ביט, יכול להיות שתראו תיקיית ABI של 32 ביט אבל לא תיקייה של 64 ביט.

חיפוש ספריות Native באמצעות הכלי לניתוח APK

הכלי לניתוח APK מאפשר להעריך היבטים שונים של קובץ APK שנוצר. משתמשים בו כדי למצוא ספריות Native ולוודא שקיימות ספריות של 64 ביט.

פותחים את Android Studio ופותחים פרויקט כלשהו.
בתפריט, בוחרים באפשרות Build > Analyze APK…
בוחרים את ה-APK שרוצים לבדוק.
מחפשים בתיקייה lib, שמכילה קובצי ‎.so אם יש כאלה. אם אין כאלה, האפליקציה תומכת במכשירים עם 64 ביט ואין צורך בפעולה נוספת. אם מופיע armeabi-v7a או x86, יש לכם ספריות של 32 ביט.
בודקים אם יש קובצי ‎.so דומים בתיקייה arm64-v8a או בתיקייה x86_64.
אם אין לכם ספריות arm64-v8a או x86_64, צריך לעדכן את תהליך ה-build כדי להתחיל ליצור את פריטי המידע האלה שנוצרו בתהליך הפיתוח (Artifact) ולכלול אותם בחבילה של ה-APK.
אם שתי הספריות כבר נארזות, אתם יכולים לדלג קדימה אל בדיקת האפליקציה בחומרת 64 ביט.

חיפוש ספריות Native על ידי פתיחת קובצי 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 ביט. שימו לב שהשלבים האלה כוללים רק קוד וספריות של build שאפשר ליצור מהמקור.

פיתוח באמצעות Android Studio או Gradle

רוב הפרויקטים ב-Android Studio משתמשים ב-Gradle כמערכת ה-build הבסיסית, ולכן הקטע הזה רלוונטי לשני המקרים. כדי להפעיל גרסאות build של קוד Native, מוסיפים את arm64-v8a ו/או את x86_64, בהתאם לארכיטקטורות שרוצים לתמוך בהן, להגדרה ndk.abiFilters בקובץ build.gradle של האפליקציה:

מגניב

// Your app's build.gradle
plugins {
  id 'com.android.app'
}

android {
   compileSdkVersion 27
   defaultConfig {
       appId "com.google.example.64bit"
       minSdkVersion 15
       targetSdkVersion 28
       versionCode 1
       versionName "1.0"
       ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
// ...

Kotlin

// Your app's build.gradle
plugins {
    id("com.android.app")
}

android {
    compileSdkVersion(27)
    defaultConfig {
        appId = "com.google.example.64bit"
        minSdkVersion(15)
        targetSdkVersion(28)
        versionCode = 1
        versionName = "1.0"
        ndk {
            abiFilters += listOf("armeabi-v7a","arm64-v8a","x86","x86_64")
        }
// ...

פיתוח באמצעות CMake

אם האפליקציה שלכם נוצרה באמצעות CMake, אתם יכולים ליצור גרסה לממשקי ABI של 64 ביט על ידי העברת arm64-v8a לפרמטר '-DANDROID_ABI':

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

פיתוח באמצעות ndk-build

אם האפליקציה שלכם נוצרה באמצעות ndk-build, אתם יכולים ליצור אותה לממשקי ABI של 64 ביט על ידי שינוי הקובץ Application.mk באמצעות המשתנה APP_ABI:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

העברת קוד של 32 ביט ל-64 ביט

אם הקוד שלכם כבר פועל במחשב או ב-iOS, לא תצטרכו לעשות שום דבר נוסף בשביל Android. אם זו הפעם הראשונה שאתם בונים את הקוד למערכת של 64 ביט, הבעיה העיקרית שצריך לטפל בה היא שהמצביעים כבר לא מתאימים לסוגים של מספרים שלמים של 32 ביט, כמו int.

עדכון קוד שמאחסן מצביעים בסוגים כמו int,‏ unsigned או uint32_t. במערכות Unix, ‏long תואם לגודל המצביע, אבל זה לא נכון ב-Windows. במקום זאת, השתמשו בסוגים uintptr_t או intptr_t שחושפים את הכוונה. כדי לאחסן את ההבדל בין שני מצביעים, משתמשים בסוג ptrdiff_t.

תמיד עדיף להשתמש בסוגים ספציפיים של מספרים שלמים ברוחב קבוע שמוגדרים ב-<stdint.h>, ולא בסוגים ברוחב לא קבוע כמו int או long, גם אם לא מדובר במצביעים.

כדי לזהות מקרים שבהם הקוד ממיר באופן שגוי בין מצביעים למספרים שלמים, אפשר להשתמש בדגלי המהדר הבאים:

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

בעיה דומה קיימת במחלקות Java עם שדות int שמכילים מצביעים לאובייקטים של C/C++‎. מחפשים את jint במקור ה-JNI ומוודאים שעוברים אל long בצד של Java ואל jlong בצד של ++C.

הצהרות פונקציה מרומזות מסוכנות הרבה יותר לקוד של 64 ביט. ‫C/C++‎ מניחים שסוג ההחזרה של פונקציה שהוצהרה באופן משתמע (כלומר, פונקציה שהקומפיילר לא ראה הצהרה לגביה) הוא int. אם סוג ההחזרה בפועל של הפונקציה הוא מצביע, זה עובד מצוין במערכת של 32 ביט שבה המצביע מתאים ל-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

אם יש לכם inline assembler, צריך לשכתב אותו או להשתמש בהטמעה רגילה של C/C++‎.

אם יש לכם גדלים של סוגים בתוך הקוד (לדוגמה, 8 או 16 בייטים), החליפו אותם בביטוי sizeof(T) המקביל, כמו sizeof(void*).

אם אתם צריכים לקמפל קוד שונה ל-32 ביט ול-64 ביט, אתם יכולים להשתמש ב-#if defined(__LP64__) להבדלים כלליים בין 32 ל-64, או ב-__arm__, ב-__aarch64__ (arm64), ב-__i386__ (x86) וב-__x86_64__ לארכיטקטורות הספציפיות שנתמכות ב-Android.

צריך להתאים את מחרוזות הפורמט לפונקציות כמו printf או scanf, כי מפרטי הפורמט המסורתיים לא מאפשרים לציין סוגי 64 ביט באופן שמתאים גם למכשירי 32 ביט וגם למכשירי 64 ביט. פקודות המאקרו PRI ו-SCN ב-<inttypes.h> פותרות את הבעיה הזו, PRIxPTR ו-SCNxPTR לכתיבה ולקריאה של מצביעים הקסדצימליים, ו-PRId64 ו-SCNd64 לכתיבה ולקריאה של ערכי 64 ביט באופן נייד.

כשמבצעים הזזה, יכול להיות שתצטרכו להשתמש ב-1ULL כדי לקבל קבוע של 64 ביט להזזה, במקום להשתמש ב-1, שהוא רק 32 ביט.

איך לצמצם את הגידול בגודל הקובץ באמצעות קובץ Android App Bundle

הוספת תמיכה בארכיטקטורת 64 ביט לאפליקציה יכולה להגדיל את קובץ ה-APK. מומלץ מאוד להשתמש בתכונה קובץ Android App Bundle כדי לצמצם את ההשפעה על הגודל של הכללת קוד Native של 32 סיביות ו-64 סיביות באותו APK.

מפתחי משחקים

שלושת המנועים הנפוצים ביותר תומכים ב-64 ביט:

לא אמיתי מאז 2015
‫Cocos2d מאז 2015
Unity מאז 2018

מפתחים ב-Unity

שדרוג לגרסאות מתאימות

ב-Unity יש תמיכה ב-64 ביט בגרסאות 2018.2 ו-2017.4.16.

אם אתם משתמשים בגרסה של Unity שלא תומכת ב-64 ביט, אתם צריכים לבחור את הגרסה שאליה אתם רוצים לשדרג ולפעול לפי המדריכים של Unity כדי להעביר את הסביבה שלכם, ולוודא שהאפליקציה משודרגת לגרסה שמאפשרת ליצור ספריות של 64 ביט. כדי לקבל גישה לתכונות ולעדכונים האחרונים, מומלץ לשדרג לגרסת ה-LTS האחרונה של העורך.

בטבלה הבאה מפורטות הגרסאות השונות של Unity ומה צריך לעשות:

גרסת Unity	הגרסה תומכת ב-64 ביט?	מהלך הפעולה המומלץ
‎2020.x	✔️	מוודאים שהגדרות ה-build מפיקות ספריות של 64 ביט.
2019.x	✔️	מוודאים שהגדרות ה-build מפיקות ספריות של 64 ביט.
‫2018.4‏ (LTS)	✔️	מוודאים שהגדרות ה-build מפיקות ספריות של 64 ביט.
2018.3	✔️	מוודאים שהגדרות ה-build מוציאות ספריות של 64 ביט.
2018.2	✔️	מוודאים שהגדרות ה-build מוציאות ספריות של 64 ביט.
2018.1	➖	תמיכה ניסיונית ב-64 ביט.
2017.4 (LTS)‎	✔️	נתמך החל מגרסה 2017.4.16. מוודאים שהגדרות ה-build מפיקות ספריות של 64 ביט.
2017.3	✖️	צריך לשדרג לגרסה שתומכת ב-64 ביט.
2017.2	✖️	צריך לשדרג לגרסה שתומכת ב-64 ביט.
2017.1	✖️	צריך לשדרג לגרסה שתומכת ב-64 ביט.
<=5.6	✖️	צריך לשדרג לגרסה שתומכת ב-64 ביט.

שינוי הגדרות ה-build כדי להפיק ספריות של 64 ביט

אם אתם משתמשים בגרסה של Unity שתומכת בספריות Android ב-64 ביט, אתם יכולים ליצור גרסת 64 ביט של האפליקציה על ידי שינוי הגדרות ה-build. משתמשים בקצה העורפי של IL2CPP כקצה העורפי של הסקריפטים. כדי להגדיר את פרויקט Unity כך שיבנה ארכיטקטורת 64 ביט, פועלים לפי השלבים הבאים:

עוברים אל Build Settings ומוודאים שה-build מיועד ל-Android. לשם כך, בודקים אם הסמל של Unity מופיע לצד Android בקטע Platform. 1. אם הסמל של Unity לא מופיע לצד פלטפורמת Android, בוחרים באפשרות Android ולוחצים על Switch Platform (החלפת פלטפורמה).
לוחצים על הגדרות הנגן.
עוברים אל חלונית הגדרות הנגן > הגדרות ל-Android > הגדרות אחרות > הגדרות אישיות.
מגדירים את Scripting Backend (קצה עורפי של סקריפטים) ל-IL2CPP.
מסמנים את התיבה Target Architecture > ARM64.
ממשיכים ליצור כרגיל.

חשוב לזכור שכדי לפתח ל-ARM64, צריך לפתח את כל הנכסים במיוחד לפלטפורמה הזו. כדי להקטין את קובץ ה-APK, כדאי לפעול לפי ההנחיות של Unity ולהשתמש בתכונה קובץ Android App Bundle.

תאימות ל-Multi-APK ול-64 ביט

אם אתם משתמשים בתמיכה של Google Play בכמה חבילות APK כדי לפרסם את האפליקציה, שימו לב שהתאימות לדרישה של 64 ביט נבדקת ברמת הגרסה. עם זאת, הדרישה ל-64 ביט לא חלה על קובצי APK או על קובצי App Bundle שלא מופצים למכשירים עם 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 ביט בלבד
אמולטור Android

‫Google Pixel עם קובץ אימג' של מערכת 64 ביט בלבד

כדי להקל על הפיתוח והבדיקה של האפליקציות, סיפקנו קובצי אימג' מיוחדים של המערכת עם סביבה קפדנית של 64 ביט בלבד לחלק ממכשירי Pixel. התמונות האלה, שמיועדות למכשירי 64 ביט בלבד, סופקו במקור במקביל לקובצי אימג' של המערכת רגילים של המכשיר בגרסאות בטא של Android 13 ו-Android 14, אבל אתם יכולים להמשיך להשתמש בהן כדי לבדוק את התאימות של האפליקציה למכשירי 64 ביט.

איך מורידים קובץ אימג' של 64 ביט בלבד

בדומה לקובצי אימג' של מערכת המפעל, אתם יכולים לצרוב קובץ אימג' של 64 ביט בלבד במכשיר באמצעות Android Flash Tool או באופן ידני, כפי שמתואר בקטעים הבאים.

צריבת ROM‏ (flash) במכשיר באמצעות Android Flash Tool

‫Android Flash Tool מאפשר לצרוב באופן מאובטח קבצי אימג' של המערכת במכשירי Pixel נתמכים. הכלי פועל בכל דפדפן אינטרנט שתומך ב-WebUSB, כמו Chrome או Edge מגרסה 79 ואילך.

הכלי Android Flash Tool מנחה אתכם בתהליך צריבת ה-ROM במכשיר שלכם שלב אחר שלב. לא צריך להתקין כלים – אבל כן צריך לבטל את הנעילה של המכשיר ולהפעיל את ניפוי הבאגים ב-USB באפשרויות למפתחים. הוראות מלאות זמינות במאמרי העזרה של Android Flash Tool.

מחברים את המכשיר באמצעות USB, ואז, בהתאם לסוג קובץ האימג' של המערכת שרוצים לצרוב, עוברים אל Android Flash Tool באמצעות אחד מהקישורים הבאים ופועלים לפי ההוראות במסך:

תמונות מערכת של Android 14 (בטא 5.2) ב-64 ביט בלבד

בוחרים את המכשיר שרוצים לצרוב:
תמונות מערכת של Android 13 (QPR3 Beta 3.2)‎ ב-64 ביט בלבד

בוחרים את המכשיר שרוצים לצרוב:

צריבת ROM ידנית במכשיר

אפשר גם להוריד את קובץ האימג' העדכני ביותר של המערכת ולצרוב אותו במכשיר באופן ידני. בטבלה הבאה אפשר להוריד את קובץ האימג' של המערכת למכשיר הבדיקה. צריבת ROM ידנית במכשיר שימושית אם אתם צריכים שליטה מדויקת על סביבת הבדיקה. היא גם מועילה אם צריך להתקין מחדש לעיתים קרובות, למשל כשמבצעים בדיקות אוטומטיות.

אחרי שמגבים את נתוני המכשיר ומורידים את קובץ האימג' התואם של המערכת, אפשר לצרוב את קובץ האימג' למכשיר.

תמיד אפשר לחזור לגרסת ה-build הציבורית העדכנית ביותר.

קובצי אימג' של מערכת מפרט המפעל בגרסת 64 ביט בלבד ל-Android 14 (גרסת בטא 5.3)

התמונות האלה מספקות סביבה קפדנית של 64 ביט בלבד לבדיקת התאימות של אפליקציות 64 ביט. ההגדרות האלה, שמיועדות ל-64 ביט בלבד, מיועדות לשימוש של מפתחים בלבד.

מכשיר	קישור להורדה	סיכום ביקורת (checksum) של SHA-256
Pixel 4a‎ (5G)		`7e6731fab811ae389f5ff882d5c5a2b8b942b8363b22bbcc038b39d7c539e60a`
Pixel 5		`c4da6a19086a02f2cd2fa7a4054e870916954b8e5a61e9a07ee942c537e4b45a`
Pixel 6		`98943384284cbc7323b8867d84c36151757f67ae7633012fb69cb5d6bec2b554`
Pixel 6 Pro		`67ec40be5bd05a40fa5dabc1ce6795aae75d1904193d52e2da00425ed7cb895b`

גיבויי קושחה של 64 ביט בלבד ל-Android 13 ‏ (QPR3 Beta 3.2)

מכשיר	קישור להורדה	סיכום ביקורת (checksum) של SHA-256
Pixel 4a‎ (5G)		`b4be40924f62c3c2b3ed20a9f7fa4303aa9c39649d778eb96f86c867fe3ae59a`
Pixel 5		`6e5e027a4f64f9f786db9bb69d50d1a551c3f6aad893ae450e1f8279ea1b761a`
Pixel 6		`becb9b81a5bddad67a4ac32d30a50dcb372b9d083cb7c046e5180510e479a0b8`
Pixel 6 Pro		`b0ef544ed2312ac44dc827f24999281b147c11d76356c2d06b2c57a191c60480`

חזרה לגרסת build ציבורית

אפשר להשתמש ב-Android Flash Tool כדי לשחזר את קושחת המכשיר, או להשיג קובץ אימג' של מערכת מפרט המפעל מהדף Factory Images for Nexus and Pixel Devices (גיבוי קושחה למכשירי Nexus ו-Pixel) ואז לשחזר אותה במכשיר באופן ידני.

אמולטור Android

החל מ-Android 12 (רמת API‏ 31), קובצי האימג' של המערכת באמולטור Android הם ב-64 ביט בלבד. יוצרים מכשיר וירטואלי של Android‏ (AVD) באמצעות קובץ אימג' של המערכת עם Android 12 (רמת API‏ 31) ומעלה, כדי לקבל סביבה קפדנית של 64 ביט בלבד לבדיקת האפליקציה.

אפשרויות נוספות למכשיר

אם אין לכם מכשיר כזה או שאתם לא יכולים להשתמש באמולטור Android, האפשרות הבאה הכי טובה היא להשתמש במכשיר עם יכולת של 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 לטעינת קוד Native,‏ SoLoader, צריך לעדכן לגרסה 0.10.4 ואילך. אם באפליקציה שלכם נעשה שימוש בערכות SDK שתלויות ב-SoLoader, הקפידו לעדכן גם לגרסה היציבה האחרונה של ערכות ה-SDK המושפעות.

בגרסה 0.9.0 ומטה של SoLoader, ההנחה היא שספריות המערכת נמצאות ב-/vendor/lib:/system/lib. הבאג הזה לא מופיע במכשירים כמו Pixel 7 שבהם הנתיב קיים, אבל ההנחה הזו גורמת לקריסות במכשירים שבהם יש רק ספריות מערכת ב-/vendor/lib64:/system/lib64.

מידע נוסף על פתרון הבעיה הזו ובעיות אחרות שנגרמות על ידי SoLoader זמין בתשובה המתאימה במרכז העזרה של Google.

OpenSSL

אם אתם משתמשים בספריית OpenSSL, עדכנו לגרסה OpenSSL 1.1.1i ואילך. אם באפליקציה שלכם נעשה שימוש בערכות SDK שמספקות תקשורת באמצעות HTTPS, או בערכות SDK אחרות שתלויות ב-OpenSSL, חשוב לעדכן גם לגרסה העדכנית של ה-SDK שמשתמשת בגרסה חדשה יותר של OpenSSL. אם אין גרסה כזו, פנו לספק ה-SDK.

‫ARMv8.3 PAC מאפשר הפעלה של Control Flow Integrity בסיוע חומרה על ידי אימות של מצביעים בזמן הריצה. בגרסאות קודמות של OpenSSL, היכולות האלה לא פועלות כמו שצריך, וגורמות לקריסות בזמן הריצה בכל המכשירים עם מעבדים שמבוססים על ARMv8.3a ומעלה.

מידע נוסף על פתרון הבעיה הזו ובעיות אחרות שנגרמות על ידי OpenSSL זמין בתשובה המתאימה במרכז העזרה של Google.

BTI

ב-ARMv8.5 ואילך, נעשה שימוש ב-Branch Target Instructions‏ (BTI) כדי להגן מפני מתקפות JOP. גרסאות קודמות של ערכות SDK לערפול קוד, שמסתעפות להיסטים אקראיים של ספריות שנוצרו באמצעות BTI, עלולות לגרום לקריסת האפליקציות. מכיוון שההוראות מקודדות כ-HINTs, אי אפשר לראות את הבאג הזה במכשירים שלא תומכים ב-BTI.

פרסום

כשהאפליקציה מוכנה, מפרסמים אותה כרגיל. כמו תמיד, חשוב להמשיך לפעול לפי השיטות המומלצות לפריסת האפליקציה. מומלץ להשתמש במסלולים לבדיקה בקבוצה מוגדרת כדי להשיק את האפליקציה למספר מוגבל של משתמשים, וכך לוודא שהאיכות של האפליקציה עקבית.

כמו בכל השקה של עדכון משמעותי, חשוב לבדוק את האפליקציה ביסודיות במכשירים שתומכים ב-64 ביט לפני שמפרסמים אותה לקהל רחב יותר.

הורדה Android 14 factory system image (64-bit-only)

לפני ההורדה, עליכם לאשר את התנאים וההגבלות הבאים.

תנאים והגבלות

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

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

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

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