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

פיתוח גרסאות באמצעות 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 ביט, המהדר (compiler) משחרר את החלק העליון של הסמן. לדוגמה:

// 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`.

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

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

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

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

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

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

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

   

3. עוברים אל חלונית ההגדרות של הנגן > הגדרות ל-Android > הגדרות אחרות > הגדרה.

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

5. מסמנים את התיבה Target Architecture > ARM64

   

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

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

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

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

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

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

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

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

BTI

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

פרסום

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

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