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

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

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).

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

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

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

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

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

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):

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

    אפשרות בתפריט Build ב-Studio להפעלת הכלי לניתוח APK
  3. בוחרים את קובץ ה-APK שרוצים לנתח.

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

    תצוגה של הכלי לניתוח APK שבה מוצגים קובצי אובייקט משותפים

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

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

התראות אזהרה ב-Studio לגבי בעיות התאמה בפרויקט

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

אזהרה של כלי ה-linting ב-Studio לגבי ספריה מקורית שלא מיושרת

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

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

מגניב

מוסיפים את האפשרות הבאה לקובץ 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 ואילך, ההידור מיושר ל-16 KB כברירת מחדל.

‫Android NDK r27

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

ndk-build

ב-Application.mk:

APP_SUPPORT_FLEXIBLE_PAGE_SIZES := true

מגניב

בקובץ 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 ומטה

כדי לתמוך בהידור של ספריות משותפות עם יישור של 16 KB באמצעות 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 r26 ומטה, צריך להגדיר את common-page-size=16384 אם משתמשים ב-NDK r22 ומטה. ההגדרה common-page-size=16384 נדרשת בגלל באגים בגרסאות קודמות של מקשרים GNU ld ו-LLVM lld. עם זאת, מומלץ מאוד לעדכן את כלי הפיתוח לגרסה עדכנית יותר כדי להימנע מהבאגים האלה לחלוטין.

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

ndk-build

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

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

CMake

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

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")

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

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

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

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

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

במקרים מסוימים, אם האפליקציה משתמשת בערך PAGE_SIZE כערך נוח שלא קשור לגודל הדף הבסיסי, השימוש בערך הזה במצב 16KB לא יגרום לאפליקציה להפסיק לפעול. עם זאת, אם הערך הזה מועבר לליבה עם 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.

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

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

  1. הגדרת Android 15 SDK

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

  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

כדי להגדיר סביבה של 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 Manager).

  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
    הורדת תמונות מערכת של אמולטור בגודל 16KB באמצעות SDK Manager ב-Android Studio
  4. לוחצים על החלה > אישור כדי להוריד את תמונות המערכת שבחרתם.

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

    איתור תמונת האמולטור בגודל 16KB בכרטיסייה Other Images (תמונות אחרות)

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

כדי לדמות סביבה של 16KB במערכות x86_64, צריך לבצע גם את השלבים הבאים בגרסאות Android Emulator 35.1.5 עד 35.1.20, ולפני עדכון 4 של תמונות המערכת של Android 15.0 בגודל 16KB שמוצעות ב-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 ואת המכשירים הווירטואליים, מפעילים את האמולטור מתפריט מכשיר היעד או משורת הפקודה.

Enable 16 KB mode on a device using developer options

Toggle the Boot with 16KB page size developer option to boot a device in 16 KB mode.

Starting with Android 15 QPR1, you can use the developer option that's available on certain devices to boot the device in 16 KB mode and perform on-device testing. Before using the developer option, go to Settings > System > Software updates and apply any updates that are available.

This developer option is available on the following devices:

  • Pixel 8 and 8 Pro (with Android 15 QPR1 or higher)

  • Pixel 8a (with Android 15 QPR1 or higher)

  • Pixel 9, 9 Pro, and 9 Pro XL (with Android 15 QPR2 Beta 2 or higher)

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

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

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