รองรับขนาดหน้าหน่วยความจำขนาด 16 KB

ในอดีต Android รองรับเฉพาะหน้าหน่วยความจำขนาด 4 KB ซึ่งได้ เพิ่มประสิทธิภาพหน่วยความจำของระบบสำหรับปริมาณหน่วยความจำทั้งหมดโดยเฉลี่ยที่ อุปกรณ์ Android มักจะมี ตั้งแต่ Android 15 เป็นต้นไป AOSP จะรองรับ อุปกรณ์ที่กำหนดค่าให้ใช้หน้าขนาด 16 KB (อุปกรณ์ 16 KB) หากแอปใช้ไลบรารี NDK ไม่ว่าจะโดยตรงหรือโดยอ้อมผ่าน SDK คุณจะต้องสร้างแอปใหม่เพื่อให้ทำงานในอุปกรณ์ที่มีขนาด 16 KB เหล่านี้ได้

เนื่องจากผู้ผลิตอุปกรณ์ยังคงสร้างอุปกรณ์ที่มีหน่วยความจำจริง (RAM) มากขึ้น อุปกรณ์จำนวนมากเหล่านี้จะใช้ขนาดหน้า 16 KB (และในที่สุดก็จะใหญ่ขึ้น) เพื่อเพิ่มประสิทธิภาพของอุปกรณ์ การเพิ่มการรองรับอุปกรณ์ที่มีขนาดหน้า 16 KB จะช่วยให้แอปของคุณทำงานบนอุปกรณ์เหล่านี้ได้ และช่วยให้แอปได้รับประโยชน์จากการปรับปรุงประสิทธิภาพที่เกี่ยวข้อง หากไม่มีการคอมไพล์ใหม่ แอปจะใช้ไม่ได้ในอุปกรณ์แบบ 16 KB ใน Android รุ่นต่อๆ ไป

เราได้ให้คำแนะนำเกี่ยวกับวิธีตรวจสอบว่าแอปได้รับผลกระทบหรือไม่ วิธีสร้างแอปใหม่ (หากมี) และวิธีทดสอบแอปในสภาพแวดล้อมแบบ 16 KB โดยใช้โปรแกรมจำลอง (รวมถึงอิมเมจระบบ Android 15 สำหรับ Android Emulator) เพื่อช่วยให้คุณเพิ่มการรองรับแอปได้

ข้อกำหนดความเข้ากันได้ของ Google Play

แอปทั้งหมดที่กำหนดเป้าหมายเป็น Android 15 (ระดับ API 35) ขึ้นไปต้องรองรับหน้าหน่วยความจำขนาด 16 KB ในอุปกรณ์ 64 บิตบน Google Play เพื่อให้มั่นใจว่าแอปของคุณจะทำงานได้อย่างถูกต้องใน Android เวอร์ชันล่าสุด ตั้งแต่วันที่ 1 กุมภาพันธ์ 2027 เป็นต้นไป หากการอัปเดตแอปของคุณไม่รองรับหน้าหน่วยความจำขนาด 16 KB คุณจะเผยแพร่การอัปเดตเหล่านี้ไม่ได้

คำเตือนใน Google Play Console ว่าการอัปเดตแอปต้องรองรับหน้าหน่วยความจำขนาด 16 KB ภายในวันที่ 1 กุมภาพันธ์ 2027
รูปที่ 1 คำเตือนเกี่ยวกับความเข้ากันได้ของ Google Play Console

สิทธิประโยชน์และประสิทธิภาพที่เพิ่มขึ้น

อุปกรณ์ที่กำหนดค่าหน้าเว็บขนาด 16 KB จะใช้หน่วยความจำโดยเฉลี่ยมากกว่าเล็กน้อย แต่ปรับปรุงประสิทธิภาพการทำงานได้หลากหลายสำหรับทั้งระบบและแอป ดังนี้

  • เวลาเปิดแอปลดลงขณะที่ระบบมีภาระเกี่ยวกับหน่วยความจำ: ลดลงโดยเฉลี่ย 3.16% โดยการปรับปรุงที่เห็นได้ชัดมากขึ้น (สูงสุด 30%) สำหรับบางแอปที่เราทดสอบ
  • การลดพลังงานในระหว่างการเปิดแอป: ลดลง 4.56% โดยเฉลี่ย
  • การเปิดตัวกล้องเร็วขึ้น: Hot Start เร็วขึ้น 4.48% โดยเฉลี่ย และ Cold Start เร็วขึ้น 6.60% โดยเฉลี่ย
  • ปรับปรุงเวลาในการบูตระบบ: เร็วขึ้น 8% (ประมาณ 950 มิลลิวินาที) โดยเฉลี่ย

การปรับปรุงเหล่านี้อิงตามการทดสอบขั้นต้นของเรา และผลลัพธ์ในอุปกรณ์จริงอาจแตกต่างกัน เราจะให้การวิเคราะห์เพิ่มเติมเกี่ยวกับโอกาสในการได้ผู้ใช้ใหม่สำหรับแอปขณะที่เราทำการทดสอบต่อไป

ตรวจสอบว่าแอปของคุณได้รับผลกระทบหรือไม่

หากแอปใช้โค้ดเนทีฟ คุณควรสร้างแอปใหม่ ให้รองรับอุปกรณ์ขนาด 16 KB หากไม่แน่ใจว่าแอปใช้โค้ดเนทีฟหรือไม่ คุณสามารถใช้ APK Analyzer เพื่อระบุว่ามีโค้ดเนทีฟหรือไม่ จากนั้นตรวจสอบการจัดแนวของส่วน ELF สำหรับไลบรารีที่ใช้ร่วมกันที่คุณพบ Android Studio ยังมีฟีเจอร์ที่จะช่วยให้คุณตรวจหาปัญหาการจัดแนวโดยอัตโนมัติได้ด้วย

หากแอปใช้เฉพาะโค้ดที่เขียนในภาษาโปรแกรม Java หรือ Kotlin ซึ่งรวมถึงไลบรารีหรือ SDK ทั้งหมด แสดงว่าแอปของคุณรองรับอุปกรณ์ขนาด 16 KB อยู่แล้ว อย่างไรก็ตาม เราขอแนะนำให้คุณทดสอบแอปในสภาพแวดล้อมแบบ 16 KB เพื่อยืนยันว่าไม่มีการถดถอยที่ไม่คาดคิดในลักษณะการทำงานของแอป

แอปของคุณใช้โค้ดแบบเนทีฟหรือไม่

แอปของคุณใช้โค้ดแบบเนทีฟหากตรงกับข้อใดข้อหนึ่งต่อไปนี้

  • แอปของคุณใช้โค้ด C/C++ (แบบเนทีฟ) หากแอปของคุณใช้ Android NDK แสดงว่าแอปใช้โค้ดแบบเนทีฟ
  • แอปของคุณลิงก์กับไลบรารีหรือทรัพยากร Dependency แบบเนทีฟของบุคคลที่สาม (เช่น SDK) ที่ใช้โค้ดแบบเนทีฟ
  • แอปของคุณสร้างขึ้นโดยเครื่องมือสร้างแอปของบุคคลที่สามที่ใช้ไลบรารีแบบเนทีฟในอุปกรณ์

ระบุไลบรารีแบบเนทีฟโดยใช้ตัววิเคราะห์ APK

ตัววิเคราะห์ APK เป็นเครื่องมือที่ช่วยให้คุณประเมินแง่มุมต่างๆ ของ APK ที่สร้างขึ้น วิธีตรวจสอบว่าแอปของคุณใช้โค้ดแบบเนทีฟหรือไม่ (ไม่ว่าแอปจะรองรับขนาด 16 KB หรือไม่)

  1. เปิด Android Studio แล้วคลิก ไฟล์ > เปิด แล้วเลือกโปรเจ็กต์ใดก็ได้
  2. จากแถบเมนู ให้คลิกสร้าง > วิเคราะห์ APK...

    ตัวเลือกเมนูบิลด์ของ Studio เพื่อเปิดตัววิเคราะห์ APK
  3. เลือก APK ที่ต้องการวิเคราะห์

  4. ดูในโฟลเดอร์ lib ซึ่งเก็บไฟล์ออบเจ็กต์ที่ใช้ร่วมกัน (.so) หากมี หากมีไฟล์ออบเจ็กต์ที่ใช้ร่วมกัน แสดงว่าแอปของคุณใช้โค้ดแบบเนทีฟ คอลัมน์ การจัดเรียง จะแสดงข้อความคำเตือนสำหรับไฟล์ที่มีปัญหาด้านการจัดเรียง หากไม่มีไฟล์ออบเจ็กต์ที่ใช้ร่วมกันหรือไม่มีโฟลเดอร์ lib แสดงว่าแอปของคุณไม่ได้ใช้โค้ดแบบเนทีฟ

    มุมมองตัววิเคราะห์ APK แสดงว่ามีไฟล์ออบเจ็กต์ที่แชร์

ตรวจหาปัญหาการจัดเรียงด้วยการตรวจสอบอัตโนมัติ

Android Studio จะเตือนคุณล่วงหน้าหากไลบรารีหรือ APK ที่สร้างไว้ล่วงหน้าไม่เป็นไปตามข้อกำหนดขนาด 16 KB ใช้เครื่องมือ APK Analyzer เพื่อตรวจสอบว่าไลบรารีใดต้องได้รับการ อัปเดตหรือต้องมีการเปลี่ยนแปลงโค้ดหรือไม่

การแจ้งเตือนคำเตือนของ Studio เกี่ยวกับปัญหาการจัดแนวในโปรเจ็กต์

Lint ใน Android Studio ยังไฮไลต์ไลบรารีแบบเนทีฟที่ ไม่ได้จัดเรียงขนาด 16 KB ด้วย

คำเตือนของ Linter ใน Studio เกี่ยวกับไลบรารีเนทีฟที่ไม่ได้จัดแนว

ตรวจสอบการจัดเรียงส่วน ELF สำหรับไลบรารีที่ใช้ร่วมกัน

สำหรับไลบรารีที่ใช้ร่วมกัน ให้ตรวจสอบว่าส่วน ELF ของไลบรารีที่ใช้ร่วมกันได้รับการจัดเรียงอย่างถูกต้องโดยใช้การจัดเรียง ELF ขนาด 16 KB หากคุณพัฒนาใน 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 เวอร์ชัน 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 เรียกใช้คำสั่งต่อไปนี้ในไฟล์ออบเจ็กต์ที่ใช้ร่วมกันแต่ละไฟล์

    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" หากไลบรารีที่ใช้ร่วมกันทั้งหมดได้รับการจัดเรียงอย่างถูกต้อง

    หากการยืนยันล้มเหลว แสดงว่าไลบรารีที่ใช้ร่วมกันบางรายการต้องได้รับการจัดเรียงใหม่ ดังนั้น คุณจะต้องอัปเดตการแพ็กเกจสำหรับไลบรารีเหล่านั้น จากนั้น คอมไพล์แอปอีกครั้งและทดสอบอีกครั้งโดยทำตามขั้นตอนในส่วนนี้

ตรวจสอบแฟล็กความปลอดภัย RELRO

เพื่อลดการใช้ประโยชน์จากช่องโหว่ด้านความปลอดภัย Linker สมัยใหม่ใช้ แฟล็ก Relocation Read-Only (RELRO) เพื่อทำให้ส่วนการย้ายข้อมูล ของไฟล์ออบเจ็กต์ที่ใช้ร่วมกันเป็นแบบอ่านอย่างเดียวหลังจากโหลด เปิดใช้แฟล็ก RELRO ใน บิวด์

ส่วน RELRO ที่มีที่อยู่เริ่มต้นบวกขนาดส่วน (MemSize) ที่ไม่ได้จัดเรียงขนาด 16 KB จะทำให้แอปขัดข้องในรันไทม์ด้วยข้อผิดพลาดในการแบ่งส่วน เหตุการณ์นี้ เกิดขึ้นหากสร้างไฟล์ .so ด้วยเชนเครื่องมือ NDK เวอร์ชัน r27 ลงไปโดยไม่ได้ เปิดใช้ แฟล็กที่เกี่ยวข้อง

เรียกใช้คำสั่งต่อไปนี้ในไฟล์ออบเจ็กต์ที่ใช้ร่วมกันแต่ละไฟล์ (Linux หรือ macOS)

SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-readelf -Wl SHARED_OBJECT_FILE.so | grep 'RELRO\|Type'

สตริง GNU_RELRO จะพิมพ์ออกมาหากมีส่วน RELRO

จากนั้นตรวจสอบการจัดเรียงส่วน RELRO โดยรวมที่อยู่ชดเชยเสมือน (VirtAddr) กับขนาดหน่วยความจำส่วน (MemSiz) แล้วหารด้วย 16 KB (0x4000) หากเศษ (โมดูโล) เป็น 0 แสดงว่าส่วน RELRO ได้รับการจัดเรียงขนาด 16 KB

ตัวอย่างไฟล์ .so ที่ไม่ได้จัดเรียง

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align  
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x01510 R   0x1

สูตร: (VirtAddr + MemSiz) % 0x4000 == 0

ผลลัพธ์: (0xdfaf0 + 0x01510) % 0x4000 = 0xE1000 % 0x4000 == 0x1000

เนื่องจาก 0x1000 ไม่ใช่ 0 แสดงว่า libbad.so ไม่เป็นไปตามข้อกำหนดขนาด 16 KB ช่วงการป้องกัน RELRO จาก DC000 (ตัวแบ่งหน้าก่อนหน้า) ถึง E4000 เป็นแบบอ่านอย่างเดียว, แต่ Android Linker คาดหวังให้ช่วงย่อยจาก E1000 ถึง E4000 เป็นแบบเขียนได้ ซึ่งส่งผลให้เกิดข้อผิดพลาดในการแบ่งส่วน ในกรณีนี้ ให้สร้างไฟล์ .so อีกครั้งตามที่อธิบายไว้ใน ส่วนคอมไพล์แอปโดยใช้การจัดเรียง ELF ขนาด 16 KB

ตัวอย่างไฟล์ .so ที่จัดเรียงแล้วพร้อมส่วน RELRO

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x00510 R   0x1  

สร้างแอปที่รองรับอุปกรณ์ขนาด 16 KB

หากแอปของคุณใช้โค้ดแบบเนทีฟ ให้ทำตามขั้นตอนที่ระบุไว้ในส่วนต่อไปนี้เพื่อให้แน่ใจว่าแอปของคุณรองรับอุปกรณ์ขนาด 16 KB

  1. อัปเดตการแพ็กเกจของไลบรารีที่ใช้ร่วมกัน
  2. คอมไพล์แอปโดยใช้การจัดเรียง ELF ขนาด 16 KB
  3. แก้ไขโค้ดและแก้ปัญหาในรันไทม์
  4. ตรวจสอบว่า SDK รองรับขนาด 16 KB

อัปเดตการแพ็กเกจของไลบรารีที่ใช้ร่วมกัน

อัปเกรดเป็น AGP เวอร์ชัน 8.5.1 ขึ้นไปและใช้ไลบรารีที่ใช้ร่วมกันที่ไม่ได้บีบอัด

ใช้ bundletool เพื่อยืนยันการจัดเรียง zip

หากต้องการดูการจัดเรียงของ Bundle ให้ใช้คำสั่งต่อไปนี้

bundletool dump config --bundle=<my .aab>  | grep alignment

หากเห็น PAGE_ALIGNMENT_16K แสดงว่า Bundle ของคุณขอการจัดเรียง zip ขนาด 16 KB หากเห็น PAGE_ALIGNMENT_4K แสดงว่าคำสั่งนี้จะบอกให้ APK ที่สร้างจาก AAB นี้มีไฟล์ .so ที่จัดเรียงขนาด 4 KB ในไฟล์ zip

AGP เวอร์ชัน 8.5.1 ขึ้นไป

อุปกรณ์ขนาด 16 KB กำหนดให้แอปที่มาพร้อมกับไลบรารีที่ใช้ร่วมกันที่ไม่ได้บีบอัดต้องจัดเรียงไลบรารีเหล่านั้นในขอบเขตที่จัดเรียง zip ขนาด 16 KB หากต้องการทำเช่นนี้ คุณต้องอัปเกรดเป็นปลั๊กอิน Android Gradle (AGP) เวอร์ชัน 8.5.1 ขึ้นไป ดูรายละเอียดเกี่ยวกับกระบวนการอัปเกรดได้ในส่วนผู้ช่วยอัปเกรดปลั๊กอิน 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
      }
  }
}
AGP เวอร์ชัน 8.0 ลงไป

หากคุณใช้ AGP เวอร์ชัน 8.0 ลงไป คุณต้องปิดใช้ตัวเลือกไลบรารีแบบเนทีฟที่ไม่ได้บีบอัดสำหรับ App Bundle ในไฟล์ gradle.properties ด้วย

android.bundle.enableUncompressedNativeLibs=false

คอมไพล์แอปโดยใช้การจัดเรียง ELF ขนาด 16 KB

อุปกรณ์ขนาด 16 KB กำหนดให้ส่วน ELF ของไลบรารีที่ใช้ร่วมกันต้องได้รับการจัดเรียงอย่างถูกต้องโดยใช้การจัดเรียง ELF ขนาด 16 KB เพื่อให้แอปทำงานได้

สำหรับนักพัฒนาเกม หากเกมของคุณทำงานบน เอนจินเกม Unity โปรดดูคู่มือ Unity หากเกมของคุณทำงานบน เกมเอนจิน Unreal, โปรดดู คู่มือ Unreal สำหรับเอนจินเกมแบบเนทีฟ ให้ทำตามคู่มือนี้ต่อไป

หากต้องการคอมไพล์แอปโดยใช้การจัดเรียง ELF ขนาด 16 KB ให้ทำตามขั้นตอนในส่วนใดส่วนหนึ่งต่อไปนี้ ทั้งนี้ขึ้นอยู่กับเวอร์ชันของ Android NDK ที่คุณใช้

Android NDK r28 ขึ้นไป

NDK เวอร์ชัน r28 ขึ้นไปจะคอมไพล์ขนาด 16 KB ที่จัดเรียงแล้วโดยค่าเริ่มต้น

Android NDK r27 ลงไป

หากต้องการรองรับการคอมไพล์ไลบรารีที่ใช้ร่วมกันที่จัดเรียงขนาด 16 KB ด้วย Android NDK เวอร์ชัน r27 ลงไป ให้ใช้แฟล็ก Linker ต่อไปนี้

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

วิธีอัปเดตไฟล์การกำหนดค่าระบบบิวด์

ndk-build

หากใช้ ndk-build ให้อัปเดต Android.mk เพื่อเปิดใช้การจัดเรียง ELF ขนาด 16 KB

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

CMake

หากใช้ CMake ให้อัปเดต CMakeLists.txt เพื่อเปิดใช้การจัดเรียง ELF ขนาด 16 KB

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

แก้ไขโค้ดและแก้ปัญหาในรันไทม์

แม้ว่าแอปของคุณจะได้รับการจัดเรียงขนาด 16 KB แล้ว แต่แอปก็อาจพบข้อผิดพลาดหากบางส่วนในโค้ดของคุณคาดว่าอุปกรณ์ใช้ขนาดหน้าเว็บที่เฉพาะเจาะจง หากต้องการหลีกเลี่ยงปัญหานี้ ให้ทำตามขั้นตอนต่อไปนี้

  1. นำทรัพยากร Dependency ที่ฮาร์ดโค้ดซึ่งอ้างอิงค่าคงที่ PAGE_SIZE หรืออินสแตนซ์ในตรรกะโค้ดที่คาดว่าขนาดหน้าของอุปกรณ์คือ 4 KB (4096) ออก

    ให้ใช้ getpagesize() หรือ sysconf(_SC_PAGESIZE) แทน

  2. มองหาการใช้งาน mmap() และ API อื่นๆ ที่ต้องใช้การจัดเรียงอาร์กิวเมนต์ หน้าเว็บ แล้วแทนที่ด้วยตัวเลือกอื่นหากจำเป็น

ในบางกรณี หากแอปของคุณใช้ PAGE_SIZE เป็นค่าที่สะดวกซึ่งไม่ได้เชื่อมโยงกับขนาดหน้าเว็บพื้นฐาน การดำเนินการนี้จะไม่ทำให้แอปหยุดทำงานเมื่อใช้ในโหมด 16 KB อย่างไรก็ตาม หากส่งค่านี้ไปยังเคอร์เนลด้วย mmap โดยไม่มี MAP_FIXED เคอร์เนลจะยังใช้ทั้งหน้า ซึ่งทำให้สิ้นเปลืองหน่วยความจำ ด้วยเหตุนี้ PAGE_SIZE จึงไม่กำหนดไว้เมื่อเปิดใช้โหมด 16 KB ใน NDK เวอร์ชัน r27 ขึ้นไป

หากแอปของคุณใช้ PAGE_SIZE ในลักษณะนี้และไม่เคยส่งค่านี้ไปยังเคอร์เนลโดยตรง ให้สร้างตัวแปรใหม่ที่มีชื่อใหม่แทนการใช้ PAGE_SIZE เพื่อแสดงว่าตัวแปรนี้ใช้เพื่อวัตถุประสงค์อื่นและไม่ได้แสดงหน้าหน่วยความจำจริง

ตรวจสอบว่า SDK รองรับขนาด 16 KB

SDK หลายรายการเข้ากันได้กับขนาดหน้า 16 KB โดยเฉพาะอย่างยิ่งหากคุณสร้าง SDK เองหรือใช้ SDK ที่สร้างไว้ล่วงหน้ารุ่นล่าสุด อย่างไรก็ตาม เนื่องจาก SDK ที่สร้างไว้ล่วงหน้าหรือ SDK บางเวอร์ชันไม่เข้ากันได้กับขนาด 16 KB คุณจึงควรตรวจสอบเว็บไซต์ของผู้ให้บริการ SDK แต่ละรายเพื่อดูว่าควรใช้เวอร์ชันใดกับขนาด 16 KB

ทดสอบแอปในสภาพแวดล้อมขนาด 16 KB

หลังจากสร้างแอปที่รองรับอุปกรณ์ขนาด 16 KB แล้ว คุณควรทดสอบแอปในสภาพแวดล้อมขนาด 16 KB เพื่อดูว่าแอปของคุณพบการถดถอยหรือไม่ โดยทำตามขั้นตอนต่อไปนี้

  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 ด้วยอิมเมจระบบแบบ 16 KB

หากต้องการตั้งค่าสภาพแวดล้อมขนาด 16 KB โดยใช้โปรแกรมจำลองของ Android ให้ทำตามขั้นตอนต่อไปนี้

  1. ใน Android Studio ให้คลิกเครื่องมือ > เครื่องมือจัดการ SDK
  2. ในแท็บ SDK Platforms ให้เลือกแสดงรายละเอียดแพ็กเกจ จากนั้นขยาย ส่วน Android VanillaIceCream ขึ้นไป แล้วเลือกอิมเมจระบบโปรแกรมจำลองอย่างน้อย 1 รายการต่อไปนี้ ทั้งนี้ขึ้นอยู่กับอุปกรณ์เสมือนที่คุณ ต้องการสร้าง

    • อิมเมจระบบ Google APIs Experimental ขนาดหน้า 16 KB ARM 64 v8a
    • อิมเมจระบบ Google APIs Experimental ขนาดหน้า 16 KB Intel x86_64 Atom
    ดาวน์โหลดอิมเมจระบบของโปรแกรมจำลองขนาด 16 KB โดยใช้เครื่องมือจัดการ SDK ใน Android Studio
  3. คลิกใช้ > ตกลง เพื่อดาวน์โหลดอิมเมจระบบที่คุณเลือก

  4. ทำตามขั้นตอนเพื่อตั้งค่าอุปกรณ์เสมือนจริงสำหรับ Android 15 และเมื่อระบบแจ้งให้เลือกอิมเมจระบบ ให้เลือกอิมเมจระบบขนาด 16 KB ที่คุณดาวน์โหลด หากระบบไม่แนะนำโดยอัตโนมัติ คุณจะค้นหาอิมเมจระบบขนาด 16 KB ได้ในแท็บอิมเมจอื่นๆ

    ค้นหาอิมเมจโปรแกรมจำลองขนาด 16 KB ในแท็บ &quot;อิมเมจอื่นๆ&quot;

เปิดโปรแกรมจำลอง

หลังจากตั้งค่าโปรแกรมจำลองของ Android และอุปกรณ์เสมือนเสร็จแล้ว ให้เปิด โปรแกรมจำลอง จากเมนูอุปกรณ์เป้าหมาย หรือ จากบรรทัดคำสั่ง

เปิดใช้โหมด 16 KB ในอุปกรณ์โดยใช้ตัวเลือกสำหรับนักพัฒนาแอป

สลับตัวเลือกสำหรับนักพัฒนาแอปบูตโดยใช้หน้าหน่วยความจำขนาด 16 KB เพื่อบูตอุปกรณ์ในโหมด 16 KB

ใน Android 15 เวอร์ชัน QPR คุณสามารถใช้ตัวเลือกสำหรับนักพัฒนาแอปที่มีในอุปกรณ์บางรุ่นเพื่อบูตอุปกรณ์ในโหมด 16 KB และทำการทดสอบในอุปกรณ์ได้ ก่อนใช้ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ ให้ไปที่การตั้งค่า > ระบบ > การอัปเดตซอฟต์แวร์ แล้วใช้การอัปเดตที่มี

ตัวเลือกสำหรับนักพัฒนาแอปนี้พร้อมใช้งานในอุปกรณ์ต่อไปนี้

  • Pixel 8 และ 8 Pro (ที่ใช้ Android 15 QPR1 ขึ้นไป)

  • Pixel 8a (ใช้ Android 15 QPR1 ขึ้นไป)

  • Pixel 9, 9 Pro และ 9 Pro XL (ใช้ Android 15 QPR2 ขึ้นไป)

  • Pixel 9a (ใช้ Android 16 ขึ้นไป)

โหมด Backcompat ขนาด 16 KB

คำเตือนในโหมดเข้ากันได้กับขนาดหน้า

คำเตือนในโหมดเข้ากันได้กับขนาดหน้า

ตัวเลือก Backcompat ขนาด 16 KB จะพร้อมใช้งานเมื่ออุปกรณ์ทำงานด้วยเคอร์เนลขนาด 16 KB ตัวจัดการแพ็กเกจจะเรียกใช้แอปในโหมด Backcompat ขนาด 16 KB เมื่อเป็นไปตามเงื่อนไขต่อไปนี้

  • หากแอปมีไฟล์ ELF (นามสกุล .so) ที่มีการจัดเรียงส่วน LOAD ขนาด 4 KB
  • หาก APK ที่บีบอัดมีไฟล์ ELF ที่ไม่ได้บีบอัดซึ่งจัดเรียง zip ขนาด 4 KB

หากตัวจัดการแพ็กเกจเปิดใช้โหมด Backcompat ขนาด 16 KB สำหรับแอป แอปจะแสดงคำเตือนเมื่อเปิดใช้ครั้งแรกว่าแอปกำลังทำงานในโหมด Backcompat ขนาด 16 KB

โหมด Backcompat ขนาด 16 KB ช่วยให้แอปบางแอปทำงานได้ แต่แอปควรได้รับการจัดเรียงขนาด 16 KB เพื่อความน่าเชื่อถือและความเสถียรสูงสุด

ในหน้าข้อมูลแอป ให้สลับการตั้งค่าเรียกใช้แอปด้วย โหมดเข้ากันได้กับขนาดหน้า ในส่วนขั้นสูง เพื่อเปิดหรือปิดใช้โหมด Backcompat ขนาด 16 KB สำหรับแอปที่เฉพาะเจาะจง การตั้งค่านี้จะปรากฏขึ้นเมื่ออุปกรณ์ทำงานด้วย ขนาดหน้า 16 KB เท่านั้น

การตั้งค่าโหมดเข้ากันได้กับขนาดหน้า

การตั้งค่าโหมดเข้ากันได้กับขนาดหน้า

วิธีบังคับเปิดใช้ Backcompat ขนาด 16 KB สำหรับทุกแอปในอุปกรณ์

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

วิธีบังคับปิดใช้ Backcompat ขนาด 16 KB สำหรับทุกแอปในอุปกรณ์

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

ใน Android 17 คุณยังบังคับปิดใช้ Backcompat ขนาด 16 KB สำหรับทุกแอปและทำให้ไบนารีที่ไม่เข้ากันหยุดทำงานทันทีได้ด้วย

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

ตั้งค่าพร็อพเพอร์ตี้ android:pageSizeCompat เป็นเปิดใช้หรือปิดใช้เพื่อเปิดหรือปิดโหมด Backcompat สำหรับแอปที่เฉพาะเจาะจงใน AndroidManifest.xml ของแอป เมื่อตั้งค่าพร็อพเพอร์ตี้นี้ แอปจะไม่แสดงคำเตือนโหมด Backcompat เมื่อเปิดแอป