תמיכה בגודלי דפים של 16KB

דרישת התאימות של Google Play לדפים בגודל 16KB

החל מ-1 בנובמבר 2025, כל האפליקציות החדשות והעדכונים לאפליקציות קיימות שיישלחו ל-Google Play ויטרגטו מכשירים עם Android 15 ומעלה, יצטרכו לתמוך בגודלי דפים של 16KB במכשירי 64 ביט.

מידע נוסף ←

בעבר, מערכת Android תמכה רק בדפים עם זיכרון בגודל 4KB, מה שאפשר למערכת לייעל את הביצועים של הזיכרון הכולל במכשירים עם נפח זיכרון ממוצע. החל מ-Android 15, ‏ AOSP תומך במכשירים שמגדירים בהם גודל דף של 16KB (מכשירים עם 16KB). אם האפליקציה שלך משתמשת בספריות NDK, באופן ישיר או בעקיפין דרך SDK, תצטרכו לבנות מחדש את האפליקציה כדי שהיא תפעל במכשירים האלה עם 16 KB.

יצרני המכשירים ממשיכים לפתח מכשירים עם נפחים גדולים יותר של זיכרון פיזי (RAM). במכשירים רבים כאלה יוטמעו דפים בגודל 16KB (ובסופו של דבר בגודל גדול יותר) כדי לשפר את הביצועים של המכשיר. הוספת תמיכה במכשירים עם גודל דף של 16KB מאפשרת לאפליקציה לפעול במכשירים האלה, וליהנות משיפורי הביצועים שקשורים לכך. בלי קומפילציה מחדש, האפליקציות לא יפעלו במכשירים עם 16 KB בגרסאות עתידיות של Android.

כדי לעזור לכם להוסיף תמיכה לאפליקציה, סיפקנו הנחיות בנושא בדיקה אם יש השפעה על האפליקציה, בנייה מחדש של האפליקציה (אם רלוונטי) ובדיקת האפליקציה בסביבה של 16KB באמצעות אמולטורים (כולל תמונות מערכת של Android 15 לאמולטור של Android).

היתרונות ושיפורי הביצועים

במכשירים שמוגדרים בהם דפים בגודל 16KB, נעשה שימוש במעט יותר זיכרון בממוצע, אבל יש גם שיפורים שונים בביצועים של המערכת ושל האפליקציות:

• זמני השקה קצרים יותר של אפליקציות בזמן שהמערכת נמצאת בלחץ על הזיכרון: נמוך ב-3.16% בממוצע, עם שיפורים משמעותיים יותר (עד 30%) בחלק מהאפליקציות שבדקנו
• צריכת חשמל מופחתת במהלך השקת האפליקציה: הפחתה של 4.56% בממוצע
• הפעלה מהירה יותר של המצלמה: הפעלה מתוך הזיכרון (hot start) מהירה יותר ב-4.48% בממוצע, והפעלה מחדש (cold start) מהירה יותר ב-6.60% בממוצע
• זמן הפעלה משופר של המערכת: שיפור של 8% (כ-950 אלפיות השנייה) בממוצע

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

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

אם האפליקציה שלך משתמשת בקוד Native, עליך לבנות מחדש את האפליקציה עם תמיכה במכשירים עם דפי זיכרון בגודל 16 KB. אם אתם לא בטוחים אם האפליקציה שלכם משתמשת בקוד Native, אתם יכולים להשתמש בכלי APK Analyzer כדי לזהות אם יש קוד Native, ואז לבדוק את ההתאמה של פלחי ELF לכל הספריות המשותפות שמצאתם. ב-Android Studio יש גם תכונות שעוזרות לכם לזהות באופן אוטומטי בעיות שקשורות ליישור.

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

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

האפליקציה שלך משתמשת בקוד מקורי אם אחד מהתנאים הבאים מתקיים:

• האפליקציה שלך משתמשת בקוד C/C++ (מקורי). אם האפליקציה שלכם משתמשת ב-Android NDK, היא משתמשת בקוד מקורי.
• האפליקציה שלך מקשרת לספריות או לתלות של צד שלישי (כמו ערכות SDK) שמשתמשות בהן.
• האפליקציה שלך נוצרה על ידי כלי לפיתוח אפליקציות של צד שלישי שמשתמש בספריות Native במכשיר.

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

APK Analyzer הוא כלי שמאפשר להעריך היבטים שונים של קובץ APK בנוי. כדי לבדוק אם האפליקציה משתמשת בקוד Native (גם אם היא תואמת ל-16 KB):

1. פותחים את Android Studio, לוחצים על File > Open (קובץ > פתיחה) ובוחרים פרויקט כלשהו.

2. בסרגל התפריטים, לוחצים על Build > Analyze APK...‎

   

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

4. בודקים בתיקייה lib אם יש קבצים של אובייקטים משותפים (.so). אם יש קבצי אובייקט משותפים, האפליקציה משתמשת בקוד מקורי. בעמודה התאמה מוצגות הודעות אזהרה לגבי קבצים שבהם יש בעיות בהתאמה. אם אין קבצים של אובייקטים משותפים או שאין תיקייה בשם lib, סימן שהאפליקציה לא משתמשת בקוד מקורי.

   

זיהוי בעיות התאמה באמצעות בדיקות אוטומטיות

אם הספריות או קובצי ה-APK שנוצרו מראש לא עומדים בדרישות של 16 KB, מוצגת אזהרה ב-Android Studio. משתמשים בכלי APK Analyzer כדי לבדוק אילו ספריות צריך לעדכן או אם נדרשים שינויים בקוד.

‫Lint ב-Android Studio גם מדגיש ספריות Native שלא מיושרות ל-16 KB.

בדיקת ההתאמה של פלחי ELF לספריות משותפות

בספריות משותפות, צריך לוודא שפלח ה-ELF של הספריות המשותפות מיושר בצורה נכונה באמצעות יישור ELF של 16KB. אם אתם מפתחים ב-Linux או ב-macOS, אתם יכולים להשתמש בסקריפט check_elf_alignment.sh כמו שמתואר בקטע הבא. אפשר גם להשתמש ישירות בכלי שורת הפקודה.

שימוש בסקריפט check_elf_alignment.sh‏ (Linux או macOS)

כדי לבדוק את ההתאמה של פלחי ELF באמצעות הסקריפט check_elf_alignment.sh:

1. שומרים את הסקריפט check_elf_alignment.sh בקובץ.

2. מריצים את הסקריפט בקובץ ה-APK של האפליקציה:

   check_elf_alignment.sh APK_NAME.apk
   

   הפלט של הסקריפט הוא ALIGNED או UNALIGNED לכל arm64-v8a הספריות המשותפות.

3. אם יש ספריות משותפות מסוג arm64-v8a או x86_64 שהן UNALIGNED, צריך לעדכן את האריזה של הספריות האלה, ואז לקמפל מחדש את האפליקציה ולבדוק אותה מחדש לפי השלבים שמופיעים בקטע הזה.

שימוש ישיר בכלי שורת הפקודה

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

1. מוודאים שגרסה 35.0.0 ואילך של Android SDK Build-Tools ו-Android NDK מותקנים באמצעות SDK Manager ב-Android Studio או באמצעות כלי שורת הפקודה sdkmanager.

2. מחולצים את קובץ ה-APK של האפליקציה:

   ‫Linux או macOS

   unzip APK_NAME.apk -d /tmp/my_apk_out
   

   ‫Windows (PowerShell)

   Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out
   

3. בספרייה הזמנית שאליה חילצת את קובץ ה-APK, בודקים את התוכן של הספרייה lib כדי למצוא קבצים של אובייקט משותף (.so). אלה אותם קבצים של אובייקטים משותפים שמוצגים כשמזהים ספריות מקוריות באמצעות הכלי לניתוח APK. מריצים את הפקודה הבאה על כל קובץ של אובייקט משותף:

   ‫Linux או macOS

   SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD
   

   ‫Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"
   

   כאשר SDK_ROOT_LOCATION הוא הנתיב לספרייה שבה התקנתם את Android SDK,‏ SHARED_OBJECT_FILE הוא שם קובץ האובייקט המשותף שאתם בודקים, ו-NDK_VERSION היא גרסת Android NDK שהתקנתם (לדוגמה, 28.0.12433566). הפלט ייראה בערך כך לכל קובץ שתבדקו:

   LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
   LOAD off    0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
   LOAD off    0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14
   

4. בודקים את שורות הפלט כדי לוודא שערכי פלחי הטעינה לא נמוכים מ-2**14. אם יש מקטעי טעינה עם ערכים של 2**13, 2**12 או פחות, צריך לעדכן את האריזה של הספריות האלה, ואז לקמפל מחדש את האפליקציה ולבדוק אותה מחדש לפי השלבים שמופיעים בקטע הזה.

5. לאחר מכן, מריצים את כלי שורת הפקודה zipalign בקובץ ה-APK של האפליקציה:

   ‫Linux או macOS

   SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
   

   ‫Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
   

   כאשר SDK_ROOT_LOCATION הוא הנתיב לספרייה שבה התקנתם את Android SDK, ו-APK_NAME הוא השם של קובץ ה-APK של האפליקציה. בשורה האחרונה של הפלט יופיע הכיתוב 'האימות בוצע בהצלחה' אם כל הספריות המשותפות מיושרות בצורה נכונה.

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

פיתוח האפליקציה עם תמיכה במכשירים עם 16 KB

אם האפליקציה שלך משתמשת בקוד Native, צריך לבצע את השלבים שמפורטים בקטעים הבאים כדי לוודא שהאפליקציה תומכת במכשירים עם דפי זיכרון בגודל 16 KB:

1. עדכון האריזה של הספריות המשותפות
2. קומפילציה של האפליקציה באמצעות יישור ELF בגודל 16 KB
3. תיקון קוד ופתרון בעיות בזמן ריצה
4. בדיקה של ערכות SDK לתמיכה ב-16 KB

טיפ: אם תעדכנו את הכלים לגרסאות האחרונות (AGP גרסה 8.5.1 ומעלה ו-NDK גרסה r28 ומעלה) ותשתמשו בתלות מוכנה מראש שתואמת ל-16 KB, האפליקציה שלכם תהיה תואמת ל-16 KB כברירת מחדל ותוכלו לדלג אל השלב של תיקון הקוד ופתרון בעיות בזמן ריצה.

עדכון האריזה של הספריות המשותפות

מומלץ לשדרג ל-AGP בגרסה 8.5.1 ומעלה ולהשתמש בספריות משותפות לא דחוסות.

גרסה 8.5.1 ומעלה של AGP

במכשירים עם 16 KB, אפליקציות שמופצות עם ספריות משותפות לא דחוסות צריכות להיות מיושרות בגבול של 16 KB ב-zip. כדי לעשות את זה, צריך לשדרג לגרסה 8.5.1 ואילך של Android Gradle Plugin ‏ (AGP). פרטים על תהליך השדרוג מופיעים בקטע כלי העזרה לשדרוג הפלאגין של Android Gradle.

AGP מגרסה 8.5 ומטה

הערה: ב-AGP מגרסה 8.3 עד 8.5, האפליקציות מיושרות כברירת מחדל ב-16 KB. עם זאת, bundletool לא מבצעת zipalign לקובצי APK כברירת מחדל. לכן, יכול להיות שהאפליקציה תיראה כאילו היא פועלת, אבל אם היא נוצרה מחבילה ב-Play, היא לא תותקן.

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

Groovy

מוסיפים את האפשרות הבאה לקובץ build.gradle:

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

Kotlin

מוסיפים את האפשרות הבאה לקובץ build.gradle.kts:

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

אזהרה: כשמשתמשים בספריות משותפות דחוסות, האפליקציה תופסת יותר מקום כשהיא מותקנת, כי הספריות נשלפות מקובץ ה-APK ומועתקות לדיסק. יכול להיות שהתקנת האפליקציה תיכשל לעיתים קרובות יותר, כי העלייה בשימוש בדיסק פירושה שיש פחות מקום במכשיר. כדי להימנע מכך, צריך לשדרג לגרסה 8.5.1 ואילך של AGP.

קומפילציה של האפליקציה באמצעות יישור ELF בגודל 16 KB

כדי שהאפליקציה תפעל במכשירים עם 16 KB, צריך ליישר את פלחי ה-ELF של הספריות המשותפות באמצעות יישור ELF של 16 KB.

מפתחי משחקים שמשתמשים במנוע המשחק Unity יכולים לעיין במדריך Unity. אם המשחק שלכם פועל על מנוע המשחק Unreal, כדאי לעיין במדריך ל-Unreal. אם אתם משתמשים במנועי משחקים מקוריים, אתם יכולים להמשיך עם המדריך הזה.

הערה: אם האפליקציה לא מחלצת ספריות Native למערכת הקבצים (extractNativeLibs מוגדר ל-false), סביר להניח שתבחינו בעלייה קלה בגודל הבינארי של האפליקציה אחרי הידור באמצעות יישור ELF של 16 KB. אופטימיזציות למנהל החבילות ב-Android 15 מבטלות את העלויות של זמן הריצה מהגידול הזה.

כדי להדר את האפליקציה באמצעות יישור ELF בגודל 16KB, פועלים לפי השלבים באחד מהקטעים הבאים, בהתאם לגרסה של Android NDK שבה אתם משתמשים.

חשוב: אם האפליקציה שלכם משתמשת בספריות משותפות מוכנות מראש, אתם צריכים גם להדר אותן מחדש באותו אופן ולייבא מחדש את הספריות בגודל 16 KB לאפליקציה.

‫Android NDK r28 ואילך

ב-NDK מגרסה r28 ואילך, ההידור (compile) מיושר ל-16 KB כברירת מחדל.

‫Android NDK r27

כדי לתמוך בהידור של ספריות משותפות בגודל 16 KB באמצעות Android NDK בגרסה r27 ואילך, צריך לעדכן את ndk-build,‏ build.gradle,‏ build.gradle.kts או את דגלי המקשר באופן הבא:

ndk-build

ב-Application.mk:

APP_SUPPORT_FLEXIBLE_PAGE_SIZES := true

Groovy

בקובץ build.gradle, מגדירים את הארגומנט -DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON:

android {
  ...
  defaultConfig {
    ...
    // This block is different from the one you use to link Gradle
    // to your CMake or ndk-build script.
    externalNativeBuild {
      // For ndk-build, instead use the ndkBuild block.
      cmake {
        // Passes optional arguments to CMake.
        arguments "-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON"
      }
    }
  }
}

Kotlin

בקובץ build.gradle.kts, מגדירים את הארגומנט -DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON:

android {
  ...
  defaultConfig {
    ...
    // This block is different from the one you use to link Gradle
    // to your CMake or ndk-build script.
    externalNativeBuild {
      // For ndk-build, instead use the ndkBuild block.
      cmake {
        // Passes optional arguments to CMake.
        arguments += listOf("-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON")
      }
    }
  }
}

מערכות build אחרות

מציינים את דגלי ה-linker הבאים:

-Wl,-z,max-page-size=16384

‫Android NDK r26 ומטה

חשוב לעדכן תמיד את ה-NDK. השימוש באפשרות הזו מומלץ רק כמוצא אחרון, ולא מובטחת תמיכה.

כדי לתמוך בהידור של ספריות משותפות בגודל 16KB עם Android NDK בגרסה r26 או בגרסאות מוקדמות יותר, צריך לעדכן את ההגדרות של ndk-build או cmake באופן הבא:

ndk-build

כדי להפעיל יישור ELF בגודל 16 KB, צריך לעדכן את Android.mk:

LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"

CMake

כדי להפעיל יישור ELF בגודל 16 KB, צריך לעדכן את CMakeLists.txt:

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,max-page-size=16384")

‫Android NDK r22 ומטה

חשוב לעדכן תמיד את ה-NDK. השימוש באפשרות הזו מומלץ רק כמוצא אחרון, ולא מובטחת תמיכה.

בנוסף לשלב שמתואר עבור NDK r26 ומטה, צריך להגדיר את common-page-size=16384 אם משתמשים ב-NDK r22 ומטה. ההגדרה common-page-size=16384 נדרשת בגלל באגים בגרסאות קודמות של מקשרים מסוג GNU ld ו-LLVM lld. הפתרון הזה של גודל דף נפוץ יעבוד רק אם קובץ ה-ELF מכיל גם את הקטע ‎ .relro_padding (LLD 18 ואילך).

כדי לקמפל ספריות משותפות שתואמות ל-16 KB באמצעות Android NDK בגרסה r22 או בגרסאות מוקדמות יותר, צריך לעדכן את ההגדרה של ndk-build או cmake באופן הבא:

ndk-build

כדי ליצור קובץ ELF שתואם לדפים בגודל 16KB, צריך לעדכן את Android.mk:

LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"
LOCAL_LDFLAGS += "-Wl,-z,common-page-size=16384"

CMake

כדי ליצור קובץ ELF שתואם לדפים בגודל 16KB, צריך לעדכן את CMakeLists.txt:

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,max-page-size=16384")
target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,common-page-size=16384")

חשוב: גם אם האפליקציה שלך מקשרת באופן דינמי לספריית התקנים של C++‎‏ (libc++_shared.so) מ-NDK r26 ומגרסאות קודמות, שחלקן לא מיושרות ל-16 KB, עדיין צריך לעדכן את היישור של כל שאר הספריות כאן, וצריך לעדכן את הקוד כדי להימנע מהסתמכות על PAGE_SIZE. כדי לבצע בדיקות בגרסאות נמוכות יותר של NDK במכשירים עם 16 KB, גרסאות קנרי של גרסאות LTS NDK‏ r23 ו-r25 זמינות ב-Android CI עם ספריות libc++_shared.so מיושרות של 16 KB. בכל מקרה, מומלץ לעבור ל-Android NDK r27 ואילך כדי לעדכן לגרסה 16 KB ELF aligned של ספריית התקנים של C++. אחרת, לא תהיה אפשרות להתקין את האפליקציה במכשירים עם 16 KB החל מהיום.
אם אין לך אפשרות לעבור ל-Android NDK החדש יותר, אולי תהיה לך אפשרות לעדכן את האפליקציה כדי להדר באופן סטטי את ספריית התקנים של C++ בספרייה המשותפת.
פרטים על קישור סטטי לספריית התקנים של C++‎ זמינים בקטע תמיכה בספריית C++‎. חשוב לקרוא גם את הקטע שיקולים חשובים.

תיקון קוד ופתרון בעיות בזמן ריצה

גם אם האפליקציה שלכם מותאמת ל-16 KB, יכול להיות שיופיעו בה שגיאות אם יש מקומות בקוד שבהם מניחים שמכשיר מסוים משתמש בגודל ספציפי של דף. כדי למנוע את הבעיה, צריך לבצע את השלבים הבאים:

1. מסירים מהלוגיקה של הקוד את כל התלות שמוגדרת מראש ומפנה לקבוע PAGE_SIZE או למופעים שבהם מניחים שגודל הדף של המכשיר הוא 4 KB ‏ (4096).

   במקום זאת, צריך להשתמש ב-getpagesize() או ב-sysconf(_SC_PAGESIZE).

2. מחפשים שימושים ב-mmap() ובממשקי API אחרים שדורשים ארגומנטים שתואמים לדף, ומחליפים אותם בחלופות במקומות שבהם זה נדרש.

במקרים מסוימים, אם האפליקציה שלך משתמשת בערך PAGE_SIZE כערך נוח שלא קשור לגודל הדף הבסיסי, השימוש בערך הזה במצב 16 KB לא יגרום לאפליקציה שלך להפסיק לפעול. עם זאת, אם הערך הזה מועבר לליבה עם mmap בלי MAP_FIXED, הליבה עדיין משתמשת בדף שלם, מה שגורם לבזבוז של חלק מהזיכרון. לכן, הערך של PAGE_SIZE לא מוגדר כשמצב 16KB מופעל ב-NDK r27 ומעלה.

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

בדיקה של ערכות SDK לתמיכה ב-16 KB

הרבה ערכות SDK תואמות לגודלי דפים של 16 KB, במיוחד אם אתם בונים אותן בעצמכם או משתמשים בגרסאות עדכניות מוכנות מראש. עם זאת, יש גרסאות SDK או קבצים בינאריים מוכנים מראש של SDK שלא תואמים ל-16 KB, ולכן כדאי לבדוק באתר של כל ספק SDK איזו גרסה מתאימה לשימוש עם 16 KB.

בדיקת האפליקציה בסביבה של 16KB

אחרי שיוצרים את האפליקציה עם תמיכה במכשירים עם 16KB, כדאי לבדוק את האפליקציה בסביבה של 16KB כדי לראות אם יש באפליקציה רגרסיות. לשם כך, בצע את הצעדים הבאים:

1. הגדרת Android 15 SDK

2. מגדירים אחת מסביבות הבדיקה הבאות:

   • הגדרת Android Emulator עם תמונת מערכת של Android 15 שמבוססת על 16 KB
     • שימוש ב-Cuttlefish עם גודל דף של 16 KB ב-ARM64
     • הדמיה של Cuttlefish עם גודל דף של 16 KB ב-x86-64
   • הפעלת מצב 16 KB במכשיר באמצעות אפשרויות למפתחים
   • שימוש ב-Samsung Remote Test Lab במכשירים נתמכים עם דפים בגודל 16KB

3. מפעילים את מכשיר הבדיקה ומריצים את הפקודה הבאה כדי לוודא שהוא משתמש בסביבה של 16 KB:

   adb shell getconf PAGE_SIZE
   

   הפקודה צריכה להחזיר את הערך 16384.

4. מריצים את הפקודה הבאה zipalign כדי לוודא שהאפליקציה מיושרת ל-16 KB, כאשר APK_NAME הוא השם של קובץ ה-APK של האפליקציה:

   zipalign -c -P 16 -v 4 APK_NAME.apk
   

5. צריך לבדוק את האפליקציה באופן יסודי, תוך התמקדות באזורים שעשויים להיות מושפעים משינוי מופעי קוד שמפנים לגדלי דפים ספציפיים.

הגדרה של Android Emulator עם קובץ אימג' של מערכת Android 15 שמבוסס על 16KB

חשוב: יש בעיה מוכרת שמונעת ניפוי באגים באמצעות LLDB עם תמונות מערכת של אמולטור בגודל 16 KB. תיקון לבעיה הזו כלול ב-NDK r27 RC 1 וב-Android Studio Koala Feature Drop | 2024.1.2 Canary 5.

כדי להגדיר סביבה של 16 KB באמצעות Android Emulator, פועלים לפי השלבים הבאים:

1. תמונות מערכת של אמולטור Android 15 מבוססות-16KB תואמות ל-Android Studio Jellyfish | 2023.3.1 או לגרסאות מתקדמות יותר. עם זאת, כדי ליהנות מהחוויה הטובה ביותר כשעובדים עם מכשירים בגודל 16 KB, מומלץ להשתמש ב-Android Studio Ladybug | 2024.2.1 ואילך.

   אנחנו תמיד עובדים על תכונות חדשות, ולכן מומלץ להוריד גרסאות חדשות יותר או את גרסת הטרום-השחרור האחרונה של Android Studio כשהן זמינות.

   חשוב לזכור שאפשר להשאיר את הגרסה הקיימת של Android Studio מותקנת, כי אפשר להתקין כמה גרסאות זו לצד זו.

2. ב-Android Studio, לוחצים על Tools > SDK Manager (כלים > כלי SDK).

3. בכרטיסייה SDK Platforms (פלטפורמות SDK), מסמנים את התיבה Show Package Details (הצגת פרטי החבילה), מרחיבים את הקטע Android VanillaIceCream (Android VanillaIceCream) או גרסה מתקדמת יותר ובוחרים אחת או יותר מתמונות המערכת הבאות של האמולטור, בהתאם למכשירים הווירטואליים שרוצים ליצור:

   • תמונת מערכת Google APIs Experimental 16 KB Page Size ARM 64 v8a
   • ‫Google APIs Experimental 16 KB Page Size Intel x86_64 Atom System Image
   הערה: אם אתם מתכננים להפעיל אמולציה של מכשיר Google Pixel נתמך, תצטרכו רק את תמונת המערכת ARM 64 v8a.

   

4. לוחצים על החלה > אישור כדי להוריד את תמונות המערכת שבחרתם.

5. פועלים לפי השלבים להגדרת מכשיר וירטואלי ל-Android 15, וכשמוצגת בקשה לבחירת תמונת מערכת, בוחרים את תמונת המערכת בגודל 16KB שהורדתם. אם היא לא מומלצת באופן אוטומטי, אפשר למצוא את תמונת המערכת בגודל 16 KB בכרטיסייה תמונות אחרות.

   

שלבים נוספים לחלק מגרסאות האמולטור ותמונות המערכת

כדי לדמות סביבה של 16KB במערכות x86_64 בגרסאות Android Emulator מ-35.1.5 עד 35.1.20, ולפני עדכון 4 של תמונות המערכת בגודל דף של 16KB ב-Android 15.0 שמוצעות ב-SDK Manager, צריך גם לבצע את השלבים הבאים. השלבים האלה לא נדרשים אחרי גרסה 35.1.21, ועם עדכון 4 של תמונות המערכת של Android 15.0 בגודל דף של 16 KB ומעלה.

1. במרכז ניהול המכשירים, לוחצים על סמל האפשרויות הנוספות (3 נקודות) לצד התמונה בגודל 16 KB, ואז לוחצים על הצגה בדיסק.
2. בתיקייה הזו, מחפשים את הקובץ config.ini.

3. מוסיפים את השורה הבאה לקובץ config.ini ושומרים את השינויים:

   kernel.parameters = androidboot.page_shift=14
   

4. כדי לוודא שהשינויים בוצעו, מריצים את הפקודה הבאה, שאמורה להחזיר 16384:

   adb shell getconf PAGE_SIZE
   

הפעלת האמולטור

אחרי שמסיימים להגדיר את Android Emulator ואת המכשירים הווירטואליים, מפעילים את האמולטור מתפריט מכשיר היעד או משורת הפקודה.

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

כדי להפעיל מכשיר במצב 16KB, מחליפים את המצב של אפשרות המפתח הפעלה בגודל דף של 16KB.

החל מ-Android 15 QPR1, אפשר להשתמש באפשרות למפתחים שזמינה במכשירים מסוימים כדי להפעיל את המכשיר במצב 16KB ולבצע בדיקות במכשיר. לפני שמשתמשים באפשרות למפתחים, עוברים אל הגדרות > מערכת > עדכוני תוכנה ומחילים את כל העדכונים שזמינים.

אפשרות המפתחים הזו זמינה במכשירים הבאים:

• ‫Pixel 8 ו-Pixel 8 Pro (עם Android 15 QPR1 ומעלה)

• ‫Pixel 8a (עם Android 15 QPR1 ואילך)

• ‫Pixel 9,‏ Pixel 9 Pro ו-Pixel 9 Pro XL (עם Android 15 QPR2 Beta 2 ומעלה)

הערה: גרסת Android 15 QPR2 נמצאת בבטא. מידע נוסף על קבלת QPR2 במכשיר שעומד בדרישות זמין במאמר הורדת גרסאות build של Android 15 QPR בטא.

מצב תאימות לאחור של 16KB

אזהרה במצב תאימות לגודל הדף

האפשרות של תאימות לאחור עם 16KB זמינה כשהמכשיר פועל עם ליבה של 16KB. מנהל החבילות מריץ אפליקציה במצב תאימות לאחור של 16 KB כשמתקיימים התנאים הבאים:

• אם לאפליקציה יש קובצי ELF (עם סיומת .so) עם יישור של פלח LOAD בגודל ‎4 KB.
• אם קובץ ה-APK הדחוס מכיל קובצי ELF לא דחוסים בגודל 4 KB עם יישור ZIP.

אם מנהל החבילות הפעיל מצב תאימות לאחור של 16KB עבור אפליקציה, האפליקציה תציג אזהרה כשהיא תופעל בפעם הראשונה, ותציין שהיא פועלת במצב תאימות לאחור של 16KB.

מצב תאימות לאחור של 16 KB מאפשר לאפליקציות מסוימות לפעול, אבל כדי להבטיח את המהימנות והיציבות הטובות ביותר, האפליקציות צריכות להיות מותאמות ל-16 KB.

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

הגדרה של מצב תאימות לגודל הדף

כדי להפעיל בכוח תאימות לאחור של 16 KB לכל אפליקציה במכשיר:

adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false

כדי להשבית את התאימות לאחור של 16 KB לכל אפליקציה במכשיר:

adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled true

מגדירים את המאפיין android:pageSizeCompat כ-enabled או כ-disabled כדי להפעיל או להשבית את מצב התאימות לאחור עבור אפליקציה ספציפית ב-AndroidManifest.xml שלה. כשהמאפיין הזה מוגדר, האפליקציה לא מציגה אזהרות לגבי מצב תאימות לאחור כשהיא מופעלת.

דרישות התאימות ל-Google Play

יצרני מכשירים מציידים את המכשירים ב-RAM גדול יותר כדי לשפר את הביצועים, ולכן הרבה מהם יאמצו גדלי דפים גדולים יותר כמו 16 KB. כדי להתכונן להשקת המכשירים החדשים האלה, אנחנו מציגים ב-Google Play דרישת תאימות חדשה: החל מ-1 בנובמבר 2025, כל האפליקציות החדשות והעדכונים לאפליקציות קיימות שיישלחו ל-Google Play ויטרגטו מכשירים עם Android 15 (רמת API 35) ומעלה, חייבים לתמוך בגודל דף של 16 KB.

מידע נוסף על דרישת התאימות הזו זמין בפוסט הזה בבלוג.