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

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

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

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

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

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

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

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

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

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

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

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

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

בודקים את המבנה של קובץ ה-APK. בזמן ה-build, קובץ ה-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 ביט אבל לא תיקיית ABI ל-64 ביט.

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

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

ברוב הפרויקטים ב-Android Studio נעשה שימוש ב-Gradle כמערכת build בסיסית, ולכן הקטע הזה רלוונטי לשני המקרים. כדי להפעיל גרסאות 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")
        }
// ...

פיתוח גרסאות build באמצעות 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

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

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

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

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

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

   

6. ממשיכים בתהליך ה-build כרגיל.

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

תאימות ל-Multi-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בגרסאות SoLoader 0.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 זמינה, פנו לספק ה-SDK.

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

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

BTI

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

פרסום

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

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