דף זה תורגם על ידי Cloud Translation API.

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

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

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

הערכת האפליקציה

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

בדיקת מצב מהירה

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

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

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

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

האפליקציה שלך משתמשת בקוד נייטיב אם היא:

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

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

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

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

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

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

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

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

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

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

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

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

אפשר לחפש ספריות נייטיב על ידי פריסת חבילות APK

קובצי APK בנויים כמו קובצי zip. באמצעות שורת הפקודה או כל תוכנה אחרת בכלי החילוץ, מחלצים את קובץ ה-APK. בהתאם לכלי החילוץ, יכול להיות שתצטרכו לשנות את שם הקובץ ל-zip.

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

:: Command Line
> zipinfo -1 YOUR_APK_FILE.apk | grep \.so$
lib/armeabi-v7a/libmain.so
lib/armeabi-v7a/libmono.so
lib/armeabi-v7a/libunity.so
lib/arm64-v8a/libmain.so
lib/arm64-v8a/libmono.so
lib/arm64-v8a/libunity.so

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

פיתוח אפליקציות עם ספריות של 64 ביט

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

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

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

GroovyKotlin

// 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")
        }
// ...

פיתוח גרסאות build באמצעות CMake

אם האפליקציה שלכם נוצרה באמצעות CMake, אפשר ליצור גרסת 64 סיביות של ABI על ידי העברת 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, גם למי שלא מצביע.

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

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

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

הצהרות פונקציה מרומזות מסוכנות הרבה יותר בקוד של 64 ביט. C/C++ מניחים שסוג הערך המוחזר של פונקציה מוצהרת במרומז (כלומר, שהמהדר לא ראה הצהרה לגביה) היא int. אם סוג ההחזרה בפועל של הפונקציה הוא מצביע, הוא פועל בצורה תקינה בגרסת 32 סיביות שהמערכת שבה הסמן נכנס לקלט. עם זאת, במערכת של 64 סיביות, מהדר משמט את החלק העליון של הסמן. לדוגמה:

// This function returns a pointer:
// extern char* foo();

// If you don't include a header that declares it,
// when the compiler sees this:
char* result = foo();

// Instead of compiling that to:
result = foo();

// It compiles to something equivalent to:
result = foo() & 0xffffffff;

// Which will then cause a SIGSEGV if you try to dereference `result`.

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

-Werror=implicit-function-declaration

אם יש לכם מערך אסמבלר מוטמע, צריך לכתוב אותו מחדש או להשתמש בהטמעה פשוטה של C/C++.

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

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

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

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

צמצום הגדלת הגודל באמצעות Android App Bundle

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

מפתחי משחקים

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

לא מציאותי מאז 2015
Cocos2d מאז 2015
Unity מאז 2018

מפתחי Unity

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

Unity מספקת תמיכה ב-64 ביט עם גרסאות 2018.2 16.4.2017.

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

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

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

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

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

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

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

Google Pixel עם תמונת מערכת של 64 ביט בלבד

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

קבלת תמונה בגרסת 64 ביט בלבד

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

הפעלת Flash במכשיר באמצעות Android Flash Tool

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

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

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

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

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

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

איך מבצעים איפוס תוכנה למכשיר באופן ידני

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

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

תמיד תוכלו לחזור לגרסה הציבורית האחרונה.

קובצי אימג' מקוריים של 64 ביט בלבד ל-Android 14 (בטא 5.3)

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

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

קובצי אימג' מקוריים של 64 ביט בלבד ל-Android 13‏ (גרסת בטא 3.2 של QPR3)

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

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

חזרה ל-build ציבורי

אפשר להשתמש בכלי ה-Flash של Android כדי להבהב את תמונת היצרן, או השגת מערכת מפרטת היצרן תמונה מתמונות היצרן למכשירי Nexus ו-Pixel ולהחזיר אותו למכשיר באופן ידני.

אמולטור Android

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

אפשרויות מכשיר אחרות

אם אין לך אחד מהמכשירים האלה או שאין לך אפשרות להשתמש באמולטור Android, אל האפשרות הטובה ביותר הבאה היא להשתמש במכשיר שתומך ב-64 ביט, כמו למשל מכשירי 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 v0.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 ואילך נעשה שימוש בהוראות יעד להסתעפות (BTI) כדי להגן מפני התקפות JOP. גרסאות קודמות של ערכות SDK להסתרה שמתפצלות להיסטים אקראיים של ספריות שנוצרו באמצעות BTI עלולות לגרום לקריסה של אפליקציות. מכיוון שההוראות מקודדות רמזים, הבאג הזה לא גלוי במכשירים שלא תומכים ב-BTI.

פרסום

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

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

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

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

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

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

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

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

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