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

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

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

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

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

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

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

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

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

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

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

האם באפליקציה שלכם נעשה שימוש בקוד מקורי?

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

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

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

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

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

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

   

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

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

   

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

בכל ספרייה משותפת, צריך לוודא שהפלחים של ה-ELF בספריות המשותפות מותאמים בצורה נכונה באמצעות התאמה של 16 KB ELF. אם אתם מפתחים ב-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. מוודאים ש-Android SDK Build-Tools בגרסה 35.0.0 ואילך ו-Android NDK מותקנים באמצעות מנהל ה-SDK ב-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 Analyzer. מריצים את הפקודה הבאה בכל קובץ אובייקט משותף:

   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 של האפליקציה. אם כל הספריות המשותפות מותאמות בצורה נכונה, בשורה האחרונה של הפלט יופיע הכיתוב 'Verification successful'.

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

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

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

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

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

AGP מגרסה 8.5.1 ואילך

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

AGP מגרסה 8.5 ומטה

הערה: בגרסאות AGP 8.3 עד 8.5, האפליקציות מותאמות כברירת מחדל ל-16KB. עם זאת, 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
      }
  }
}

איך מקמפלים את האפליקציה באמצעות התאמה של ELF ל-16KB

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

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

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

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

Android NDK r28 ואילך

בגרסה r28 ואילך של NDK, הידור מתבצע כברירת מחדל עם התאמה ל-16KB.

Android NDK r27

כדי לתמוך בתכנות של ספריות משותפות בגודל 16KB עם 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 אחרות

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

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

Android NDK r26 וגרסאות קודמות

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

ndk-build

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

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

CMake

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

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

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

אם אין לכם אפשרות לעבור ל-Android NDK החדש יותר, יכול להיות שתוכלו לעדכן את האפליקציה כך שתתבצע הידור סטטי של הספרייה הרגילה של C++ בספרייה המשותפת. בקטע תמיכה בספריית C++‎ מוסבר בהרחבה איך יוצרים קישור סטטי לספרייה הרגילה של C++‎, ומומלץ לקרוא את הקטע שיקולים חשובים.

בדיקת מופעי קוד שמפנים לגדלי דפים ספציפיים

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

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

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

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

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

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

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

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

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

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

1. הגדרת Android 15 SDK

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

   • הגדרת Android Emulator באמצעות קובץ אימג' של מערכת Android 15 בגודל 16KB
   • הפעלת מצב 16KB במכשיר באמצעות אפשרויות למפתחים
   • שימוש ב-Cuttlefish עם גודל דף של 16KB ב-ARM64
   • הדמיה של Cuttlefish עם גודל דף של 16KB ב-x86-64

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

   adb shell getconf PAGE_SIZE
   

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

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

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

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

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

חשוב: יש בעיה ידועה שמונעת ניפוי באגים באמצעות LLDB עם קובצי אימג' של מערכת למהדורת אמולטור בנפח 16KB. תיקון לבעיה הזו כלול ב-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 ואילך. עם זאת, כדי ליהנות מחוויית השימוש הטובה ביותר ב-Android 15 Beta, מומלץ להוריד את גרסת התצוגה המקדימה העדכנית של Android Studio.

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

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

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

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

   

4. לוחצים על אישור > בסדר כדי להוריד את קובצי האימג' של המערכת שבחרתם.

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

   

אזהרה: כדי לדמות סביבה של 16 KB במערכות x86_64, צריך לבצע גם את השלבים הבאים. השלבים האלה הם זמניים ותוסר בעתיד.

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

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

   kernel.parameters = androidboot.page_shift=14
   

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

   adb shell getconf PAGE_SIZE
   

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

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

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

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

• Pixel 8 ו-Pixel 8 Pro (עם Android 15 QPR1 Beta 1 ואילך)

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