Historically, Android has only supported 4 KB memory page sizes, which has optimized system memory performance for the average amount of total memory that Android devices have typically had. Beginning with Android 15, AOSP supports devices that are configured to use a page size of 16 KB (16 KB devices). If your app uses any NDK libraries, either directly or indirectly through an SDK, then you will need to rebuild your app for it to work on these 16 KB devices.
As device manufacturers continue to build devices with larger amounts of physical memory (RAM), many of these devices will adopt 16 KB (and eventually greater) page sizes to optimize the device's performance. Adding support for 16 KB page size devices enables your app to run on these devices and helps your app benefit from the associated performance improvements. Without recompiling, apps won't work on 16 KB devices in future Android releases.
To help you add support for your app, we've provided guidance on how to check if your app is impacted, how to rebuild your app (if applicable), and how to test your app in a 16 KB environment using emulators (including Android 15 system images for the Android Emulator).
היתרונות ושיפורי הביצועים
Devices configured with 16 KB page sizes use slightly more memory on average, but also gain various performance improvements for both the system and apps:
- Lower app launch times while the system is under memory pressure: 3.16% lower on average, with more significant improvements (up to 30%) for some apps that we tested
- Reduced power draw during app launch: 4.56% reduction on average
- Faster camera launch: 4.48% faster hot starts on average, and 6.60% faster cold starts on average
- Improved system boot time: improved by 8% (approximately 950 milliseconds) on average
These improvements are based on our initial testing, and results on actual devices will likely differ. We'll provide additional analysis of potential gains for apps as we continue our testing.
איך בודקים אם האפליקציה מושפעת
If your app uses any native code, then you should rebuild your app with support for 16 KB devices. If you are unsure if your app uses native code, you can use the APK Analyzer to identify whether any native code is present and then check the alignment of ELF segments for any shared libraries that you find. Android Studio also provides features that help you to automatically detect alignment issues.
If your app only uses code written in the Java programming language or in Kotlin, including all libraries or SDKs, then your app already supports 16 KB devices. Nevertheless, we recommend that you test your app in a 16 KB environment to verify that there are no unexpected regressions in app behavior.
האם האפליקציה שלך משתמשת בקוד מקורי?
האפליקציה שלך משתמשת בקוד מקורי אם אחד מהתנאים הבאים מתקיים:
- האפליקציה שלך משתמשת בקוד C/C++ (מקורי). אם האפליקציה שלכם משתמשת ב-Android NDK, היא משתמשת בקוד מקורי.
- האפליקציה שלך מקשרת לספריות או לתלות של צד שלישי (כמו ערכות SDK) שמשתמשות בהן.
- האפליקציה שלך נוצרה על ידי כלי צד שלישי ליצירת אפליקציות שמשתמש בספריות Native במכשיר.
זיהוי ספריות Native באמצעות הכלי לניתוח APK
APK Analyzer הוא כלי שמאפשר להעריך היבטים שונים של קובץ APK בנוי. כדי לבדוק אם האפליקציה משתמשת בקוד Native (גם אם היא תואמת ל-16 KB):
- פותחים את Android Studio, לוחצים על File > Open (קובץ > פתיחה) ובוחרים פרויקט כלשהו.
בסרגל התפריטים, לוחצים על Build > Analyze APK...
בוחרים את קובץ ה-APK שרוצים לנתח.
בודקים בתיקייה
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, פועלים לפי השלבים הבאים:
שומרים את הסקריפט
check_elf_alignment.shבקובץ.מריצים את הסקריפט בקובץ ה-APK של האפליקציה:
check_elf_alignment.sh APK_NAME.apkהפלט של הסקריפט הוא
ALIGNEDאוUNALIGNEDלכלarm64-v8aהספריות המשותפות.אם יש ספריות משותפות מסוג
arm64-v8aאוx86_64שהןUNALIGNED, צריך לעדכן את האריזה של הספריות האלה, ואז לקמפל מחדש את האפליקציה ולבדוק אותה מחדש לפי השלבים שמופיעים בקטע הזה.
שימוש ישיר בכלי שורת הפקודה
כדי לבדוק את ההתאמה של פלחי ELF באמצעות כלים של שורת הפקודה ישירות:
- מוודאים שגרסה 35.0.0 ואילך של Android SDK Build-Tools ו-Android NDK מותקנים באמצעות SDK Manager ב-Android Studio או באמצעות כלי שורת הפקודה
sdkmanager. מחולצים את קובץ ה-APK של האפליקציה:
Linux או macOS
unzip APK_NAME.apk -d /tmp/my_apk_outWindows (PowerShell)
Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_outבספרייה הזמנית שאליה חילצתם את קובץ ה-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 LOADWindows (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בודקים את שורות הפלט כדי לוודא שערכי פלחי הטעינה לא נמוכים מ-
2**14. אם יש מקטעי טעינה עם ערכים של2**13,2**12או פחות, צריך לעדכן את האריזה של הספריות האלה, ואז לקמפל מחדש את האפליקציה ולבדוק אותה מחדש לפי השלבים שמופיעים בקטע הזה.לאחר מכן, מריצים את כלי שורת הפקודה
zipalignבקובץ ה-APK של האפליקציה:Linux או macOS
SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apkWindows (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:
- עדכון האריזה של הספריות המשותפות
- קומפילציה של האפליקציה באמצעות יישור ELF בגודל 16 KB
- תיקון קוד ופתרון בעיות בזמן ריצה
- בדיקה של ערכות SDK לתמיכה ב-16 KB
עדכון האריזה של הספריות המשותפות
מומלץ לשדרג ל-AGP בגרסה 8.5.1 ומעלה ולהשתמש בספריות משותפות לא דחוסות.
גרסה 8.5.1 ומעלה של AGP
במכשירים עם 16KB, אפליקציות שמופצות עם ספריות משותפות לא דחוסות צריכות להיות מיושרות בגבול של 16KB ב-zip. כדי לעשות את זה, צריך לשדרג לגרסה 8.5.1 ואילך של Android Gradle Plugin (AGP). פרטים על תהליך השדרוג מופיעים בקטע כלי העזרה לשדרוג הפלאגין של Android Gradle.
AGP מגרסה 8.5 ומטה
אם אין לכם אפשרות לשדרג את AGP לגרסה 8.5.1 ואילך, האפשרות החלופית היא לעבור לשימוש בספריות משותפות דחוסות. כדי למנוע בעיות בהתקנת האפליקציה בגלל ספריות משותפות לא מיושרות, צריך לעדכן את ההגדרה של Gradle כך ש-Gradle ידחס את הספריות המשותפות כשיוצרים חבילת אפליקציה.
Groovy
מוסיפים את האפשרות הבאה לקובץ build.gradle:
android {
...
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
}
Kotlin
מוסיפים את האפשרות הבאה לקובץ build.gradle.kts:
android {
...
packagingOptions {
jniLibs {
useLegacyPackaging = true
}
}
}
קומפילציה של האפליקציה באמצעות יישור ELF בגודל 16 KB
כדי שהאפליקציה תפעל במכשירים עם 16 KB, צריך ליישר את פלחי ה-ELF של הספריות המשותפות בצורה נכונה באמצעות יישור ELF של 16 KB.
מפתחי משחקים שמשתמשים במנוע המשחק Unity יכולים לעיין במדריך Unity. אם המשחק שלכם פועל על מנוע המשחק Unreal, כדאי לעיין במדריך של Unreal. אם אתם משתמשים במנועי משחקים מקוריים, אתם יכולים להמשיך עם המדריך הזה.
כדי להדר את האפליקציה באמצעות יישור ELF בגודל 16KB, פועלים לפי השלבים באחד מהקטעים הבאים, בהתאם לגרסה של Android NDK שבה אתם משתמשים.
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 יכול לעקוף באגים במקשרים הישנים GNU ld ו-LLVM lld. הפעולה הזו אפשרית רק אם יש גם קטע .relro_padding בקובץ ה-ELF. הפעולה הזו תלויה בגרסה של הכלי לקישור ובתוכנית הספציפית שנכתבה. אין תמיכה בגרסאות האלה של NDK, ואם היא לא פועלת, צריך לעדכן את גרסת NDK לפני שמדווחים על בעיה כלשהי.
תיקון קוד ופתרון בעיות בזמן ריצה
גם אם האפליקציה שלכם מותאמת ל-16 KB, יכול להיות שיופיעו בה שגיאות אם יש מקומות בקוד שבהם מניחים שמכשיר מסוים משתמש בגודל ספציפי של דף. כדי למנוע את הבעיה, צריך לבצע את השלבים הבאים:
מסירים מהלוגיקה של הקוד את כל התלות שמוגדרת מראש ומפנה לקבוע
PAGE_SIZEאו למופעים שבהם מניחים שגודל הדף של המכשיר הוא 4 KB (4096).במקום זאת, צריך להשתמש ב-
getpagesize()או ב-sysconf(_SC_PAGESIZE).מחפשים שימושים ב-
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 או קבצים בינאריים מוכנים מראש של SDK שלא תואמים ל-16 KB, ולכן כדאי לבדוק באתר של כל ספק SDK איזו גרסה מתאימה לשימוש עם 16 KB.
בדיקת האפליקציה בסביבה של 16KB
אחרי שיוצרים את האפליקציה עם תמיכה במכשירים עם 16KB, כדאי לבדוק את האפליקציה בסביבה של 16KB כדי לראות אם יש באפליקציה רגרסיות. לשם כך, בצע את הצעדים הבאים:
מגדירים את Android 15 SDK או גרסה מתקדמת יותר.
מגדירים אחת מסביבות הבדיקה הבאות:
מפעילים את מכשיר הבדיקה ומריצים את הפקודה הבאה כדי לוודא שהוא משתמש בסביבה של 16 KB:
adb shell getconf PAGE_SIZEהפקודה צריכה להחזיר את הערך
16384.מריצים את הפקודה הבאה
zipalignכדי לוודא שהאפליקציה מיושרת ל-16 KB, כאשר APK_NAME הוא השם של קובץ ה-APK של האפליקציה:zipalign -c -P 16 -v 4 APK_NAME.apkצריך לבדוק את האפליקציה באופן יסודי, תוך התמקדות באזורים שעשויים להיות מושפעים משינוי מופעי קוד שמפנים לגדלי דפים ספציפיים.
הגדרה של Android Emulator עם תמונת מערכת שמבוססת על 16KB
כדי להגדיר סביבה של 16 KB באמצעות Android Emulator, פועלים לפי השלבים הבאים:
- ב-Android Studio, לוחצים על Tools > SDK Manager (כלים > SDK Manager).
בכרטיסייה 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
לוחצים על החלה > אישור כדי להוריד את תמונות המערכת שבחרתם.
פועלים לפי השלבים להגדרת מכשיר וירטואלי ל-Android 15, וכשמוצגת בקשה לבחירת תמונת מערכת, בוחרים את תמונת המערכת בגודל 16KB שהורדתם. אם היא לא מומלצת באופן אוטומטי, אפשר למצוא את תמונת המערכת בגודל 16 KB בכרטיסייה תמונות אחרות.
הפעלת האמולטור
אחרי שמסיימים להגדיר את Android Emulator ואת המכשירים הווירטואליים, מפעילים את האמולטור מתפריט מכשיר היעד או משורת הפקודה.
הפעלת מצב 16 KB במכשיר באמצעות אפשרויות למפתחים
כדי להפעיל מכשיר במצב 16KB, מעבירים את המתג של אפשרות המפתחים הפעלה בגודל דף של 16KB.
בגרסאות QPR של Android 15, אפשר להשתמש באפשרות למפתחים שזמינה במכשירים מסוימים כדי להפעיל את המכשיר במצב 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 ואילך)
מצב תאימות לאחור של 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) ומעלה, חייבים לתמוך בגודל דף של 16KB.
מידע נוסף על דרישת התאימות הזו זמין בפוסט הזה בבלוג.