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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הכלי לניתוח APK הוא כלי שמאפשר להעריך היבטים שונים של קובץ APK בנוי. אפשר להשתמש בו כדי למצוא ספריות Native ולוודא שקיימות ספריות 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, תצטרכו לעדכן את תהליך build כדי להתחיל לבנות ולארוז את פריטי המידע שנוצרו בתהליך פיתוח (Artifact) האלה ב-APK.

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

פיתוח באמצעות 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'
// ...

// 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 ביט שבה המצביע מתאים למספר שלם. עם זאת, במערכת 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

אם יש לכם קוד 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 ביט:

• ‫Unreal מאז 2015
• ‫Cocos2d מאז 2015
• ‫Unity מאז 2018

מפתחים ב-Unity

שדרוג לגרסאות עם יכולות

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

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

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

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

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

1. עוברים אל Build Settings ומוודאים שאתם מבצעים build ל-Android. כדי לוודא זאת, בודקים שסמל Unity מופיע לצד Android בקטע Platform. 1. אם סמל Unity לא מופיע לצד פלטפורמת Android, בוחרים באפשרות Android ולוחצים על Switch Platform (החלפת פלטפורמה).

2. לוחצים על הגדרות הנגן.

   

3. עוברים אל Player Settings Panel > Settings for Android > Other settings > Configuration

4. מגדירים את Scripting Backend (קצה עורפי של סקריפטים) ל-IL2CPP.

5. מסמנים את התיבה ארכיטקטורת יעד > ARM64.

   

6. בונים כרגיל!

חשוב לזכור: כדי ליצור גרסה ל-ARM64, צריך ליצור את כל הנכסים במיוחד עבור הפלטפורמה הזו. כדי להקטין את נפח קובץ ה-APK, כדאי לפעול לפי ההנחיות של Unity ולשקול להשתמש בתכונה קובץ 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 ביט בלבד
• אמולטור Android

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

כדי להקל על פיתוח ובדיקה של אפליקציות, סיפקנו תמונות מערכת מיוחדות עם סביבה של 64 ביט בלבד לחלק ממכשירי Pixel. התמונות האלה, שזמינות רק ב-64 ביט, סופקו במקור במקביל לתמונות מערכת סטנדרטיות של יצרן עבור גרסאות התצוגה המקדימה של Android 13 ו-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-bit-only

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

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • ‫Pixel 6 Pro

• תמונות מערכת של Android 13‏ (QPR3 Beta 3.2) ל-64 ביט בלבד

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

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • ‫Pixel 6 Pro

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

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

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

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

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

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

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

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

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

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

Android Emulator

החל מ-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 המושפעות.

גרסה 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 מאפשרת הפעלה של Control Flow Integrity בסיוע חומרה על ידי אימות של מצביעים בזמן הריצה. גרסאות קודמות של OpenSSL משתמשות ביכולות האלה בצורה שגויה, שגורמת לקריסות בזמן הריצה בכל המכשירים עם מעבדים שמבוססים על ARMv8.3a ומעלה.

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

BTI

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

פרסום

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

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