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

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

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

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

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

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

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

ב-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 ביט.

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

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

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

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

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

5. מסמנים את תיבת הסימון Target Architecture > ARM64 (ארכיטקטורת יעד > 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 או באמצעות הפעלה ידנית של המכשיר, כמו שמתואר בקטעים הבאים.

הפעלת 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-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

הפעלה ידנית של Flash במכשיר

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

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

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

תמונות מהמפעל ל-Android 14 (בטא 5.3) ל-64 ביט בלבד

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

תמונות מהמפעל ל-Android 13 (QPR3 Beta 3.2) ל-64 ביט בלבד

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

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

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

אמולטור Android

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

פרסום

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

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