תמיכה בארכיטקטורות של 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-ביט.

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

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

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

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

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

1. פותחים את Android Studio ופותחים פרויקט כלשהו.

2. בתפריט, לוחצים על Build > (פיתוח >) ניתוח APK...

   

3. בוחרים את ה-APK שרוצים לבדוק.

4. מחפשים בתיקייה lib, שמארחת את הסיומת ' .so' קבצים, אם יש כאלה. אם יש אין, האפליקציה תומכת במכשירים עם 64 ביט ולא נדרשת כל פעולה נוספת נדרש. אם מופיע הכיתוב armeabi-v7a או x86, סימן שיש לכם 32 ביט של הספריות.

5. צריך לבדוק אם יש לכם שם דומה לסיומת 'so.' קבצים בפורמט arm64-v8a או תיקייה x86_64.

   

6. אם אין לך ספריות arm64-v8a או x86_64, עליך לעדכן את תהליך build כדי להתחיל ליצור ולאסוף את הפריטים האלה ב-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' file:

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

במקרה של שינוי, ייתכן שיהיה צורך להשתמש ב-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 ומה צריך לעשות:

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

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

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

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

   

3. מנווטים אל חלונית ההגדרות של הנגן > הגדרות ל-Android > המלצות אחרות הגדרות > הגדרה

4. מגדירים את Scripting Backend כ-IL2CPP.

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

   

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

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

חבילות APK מרובות ותאימות ל-64 ביט

אם אתם משתמשים בתמיכה של Google Play בחבילות APK מרובות כדי לפרסם את האפליקציה. שימו לב שאנחנו בודקים את התאימות לדרישה של גרסת 64 סיביות ברמת הגרסה. עם זאת, הדרישה של 64 ביט לא חלה על חבילות APK או קובצי App Bundle שלא מופצים למכשירים עם Android 9pie ואילך.

אם אחת מחבילות ה-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

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

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

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

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

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

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

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

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

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

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

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

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

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

תמונות יצרן ב-64 ביט בלבד ל-Android 14 (בטא 5.3)

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

תמונות יצרן של 64 ביט בלבד ל-Android 13 (QPR3 Beta 3.2)

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

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

פרסום

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

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