รองรับสถาปัตยกรรม 64 บิต

แอปที่เผยแพร่ใน Google Play ต้องรองรับสถาปัตยกรรม 64 บิต การเพิ่มแอปเวอร์ชัน 64 บิตจะช่วยปรับปรุงประสิทธิภาพและเตรียมคุณให้พร้อมสำหรับอุปกรณ์ที่มีฮาร์ดแวร์แบบ 64 บิตเท่านั้น

ขั้นตอนต่อไปนี้จะช่วยให้มั่นใจว่าแอป 32 บิตของคุณรองรับอุปกรณ์ 64 บิต

ประเมินแอปของคุณ

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

การตรวจสอบสถานะด่วน

ไปที่ Play Console และดูรุ่นที่มีอยู่เพื่อตรวจสอบว่าสอดคล้องกับนโยบายหรือไม่

นอกจากนี้ Play Console ยังแสดงคำเตือนที่ใช้กับเวอร์ชันร่างของคุณหากมีปัญหาเกี่ยวกับข้อกำหนด 64 บิต รูปภาพต่อไปนี้เป็นตัวอย่าง

หากการแจ้งเตือนปรากฏขึ้น โปรดดูขั้นตอนต่อไปนี้เพื่อทำให้แอปของคุณเข้ากันได้กับอุปกรณ์ 64 บิต

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

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

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

แอปของคุณมีไลบรารี 64 บิตไหม

ตรวจสอบโครงสร้างของไฟล์ APK เมื่อสร้างแล้ว APK จะรวมไลบรารีแบบเนทีฟที่แอปต้องการไว้ด้วย โดยไลบรารีแบบเนทีฟจะจัดเก็บไว้ในโฟลเดอร์ต่างๆ ตาม ABI ไม่จำเป็นต้องรองรับสถาปัตยกรรม 64 บิตทุกแบบ แต่สำหรับสถาปัตยกรรม 32 บิตแบบเนทีฟแต่ละแบบที่คุณรองรับ คุณต้องรวมสถาปัตยกรรม 64 บิตที่เกี่ยวข้องด้วย

สำหรับสถาปัตยกรรม ARM ไลบรารี 32 บิตจะอยู่ใน armeabi-v7a โดยสถาปัตยกรรม 64 บิตที่เทียบเท่าคือ arm64-v8a

สำหรับสถาปัตยกรรม x86 ให้มองหา x86 สำหรับ 32 บิต และ x86_64 สำหรับ 64 บิต

ตรวจสอบว่าคุณมีไลบรารีแบบเนทีฟในทั้ง 2 โฟลเดอร์นี้ กล่าวโดยสรุปคือ

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

ในกรณีทั่วไป APK หรือ Bundle ที่สร้างขึ้นสำหรับสถาปัตยกรรมทั้งแบบ 32 บิตและ 64 บิตจะมีโฟลเดอร์สำหรับ ABI ทั้ง 2 แบบ โดยแต่ละโฟลเดอร์จะมีชุดไลบรารีแบบเนทีฟที่สอดคล้องกัน หากไม่มีการรองรับ 64 บิต คุณอาจเห็นโฟลเดอร์ ABI 32 บิต แต่ไม่เห็นโฟลเดอร์ 64 บิต

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

ตัววิเคราะห์ APK เป็นเครื่องมือที่ช่วยให้คุณประเมินแง่มุมต่างๆ ของ APK ที่สร้างขึ้นได้ ใช้เครื่องมือนี้เพื่อค้นหาไลบรารีแบบเนทีฟและตรวจสอบว่ามีไลบรารี 64 บิตอยู่

1. เปิด Android Studio แล้วเปิดโปรเจ็กต์ใดก็ได้

2. จากเมนู ให้เลือกสร้าง > วิเคราะห์ APK…

   

3. เลือก APK ที่ต้องการประเมิน

4. ดูภายในโฟลเดอร์ lib ซึ่งโฮสต์ไฟล์ ".so" (หากมี) หากไม่มี แสดงว่าแอปของคุณรองรับอุปกรณ์ 64 บิตและไม่จำเป็นต้องดำเนินการใดๆ เพิ่มเติม หากเห็น armeabi-v7a หรือ x86 แสดงว่าคุณมีไลบรารี 32 บิต

5. ตรวจสอบว่าคุณมีไฟล์ ".so" ที่คล้ายกันในโฟลเดอร์ arm64-v8a หรือ x86_64 หรือไม่

   

6. หากคุณไม่มีไลบรารี arm64-v8a หรือ x86_64 ให้อัปเดตกระบวนการบิลด์เพื่อเริ่มสร้างและแพ็กอาร์ติแฟกต์เหล่านั้นใน APK

7. หากเห็นว่ามีการแพ็กเกจทั้ง 2 ไลบรารีแล้ว คุณสามารถข้ามไปที่การทดสอบแอปในฮาร์ดแวร์ 64 บิตได้เลย

มองหาไลบรารีแบบเนทีฟโดยการแตกไฟล์ APK

ไฟล์ APK มีโครงสร้างเหมือนไฟล์ ZIP แตกไฟล์ APK ด้วยบรรทัดคำสั่งหรือเครื่องมือแตกไฟล์อื่นๆ คุณอาจต้องเปลี่ยนชื่อไฟล์เป็น .zip ทั้งนี้ขึ้นอยู่กับเครื่องมือแตกไฟล์ที่ใช้

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

:: Command Line
> zipinfo -1 YOUR_APK_FILE.apk | grep \.so$
lib/armeabi-v7a/libmain.so
lib/armeabi-v7a/libmono.so
lib/armeabi-v7a/libunity.so
lib/arm64-v8a/libmain.so
lib/arm64-v8a/libmono.so
lib/arm64-v8a/libunity.so

โปรดสังเกตว่าในตัวอย่างนี้มีไลบรารี armeabi-v7a และ arm64-v8a ซึ่งหมายความว่าแอปนี้รองรับสถาปัตยกรรม 64 บิต

สร้างแอปด้วยไลบรารี 64 บิต

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

สร้างด้วย Android Studio หรือ Gradle

โปรเจ็กต์ Android Studio ส่วนใหญ่ใช้ Gradle เป็นระบบบิลด์ที่สำคัญ ดังนั้นส่วนนี้จึงใช้ได้กับทั้ง 2 กรณี หากต้องการเปิดใช้บิลด์สำหรับโค้ดแบบเนทีฟ ให้เพิ่ม arm64-v8a และ/หรือ x86_64 ลงในการตั้งค่า ndk.abiFilters ในไฟล์ "build.gradle" ของแอป โดยขึ้นอยู่กับสถาปัตยกรรมที่คุณต้องการรองรับ

// Your app's build.gradle
plugins {
  id 'com.android.app'
}

android {
   compileSdkVersion 27
   defaultConfig {
       appId "com.google.example.64bit"
       minSdkVersion 15
       targetSdkVersion 28
       versionCode 1
       versionName "1.0"
       ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
// ...

// Your app's build.gradle
plugins {
    id("com.android.app")
}

android {
    compileSdkVersion(27)
    defaultConfig {
        appId = "com.google.example.64bit"
        minSdkVersion(15)
        targetSdkVersion(28)
        versionCode = 1
        versionName = "1.0"
        ndk {
            abiFilters += listOf("armeabi-v7a","arm64-v8a","x86","x86_64")
        }
// ...

สร้างด้วย CMake

หากแอปสร้างขึ้นโดยใช้ CMake คุณสามารถสร้างสำหรับ ABI แบบ 64 บิตได้โดยส่ง arm64-v8a ไปยังพารามิเตอร์ "-DANDROID_ABI" ดังนี้

:: Command Line
> cmake -DANDROID_ABI=arm64-v8a … or
> cmake -DANDROID_ABI=x86_64 …

สร้างด้วย ndk-build

หากแอปสร้างขึ้นด้วย ndk-build คุณสามารถสร้างสำหรับ ABI แบบ 64 บิตได้โดยแก้ไขไฟล์ "Application.mk" โดยใช้ตัวแปร APP_ABI ดังนี้

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

พอร์ตโค้ด 32 บิตเป็น 64 บิต

หากโค้ดของคุณทำงานบนเดสก์ท็อปหรือ iOS อยู่แล้ว คุณก็ไม่จำเป็นต้องดำเนินการใดๆ เพิ่มเติมสำหรับ Android หากนี่เป็นครั้งแรกที่สร้างโค้ดสำหรับระบบ 64 บิต ปัญหาหลักที่คุณต้องแก้ไขคือพอยน์เตอร์ไม่พอดีกับประเภทจำนวนเต็ม 32 บิต เช่น int อีกต่อไป

อัปเดตโค้ดที่จัดเก็บพอยน์เตอร์ในประเภทต่างๆ เช่น int, unsigned หรือ uint32_t ในระบบ Unix long จะตรงกับขนาดตัวชี้ แต่ใน Windows จะไม่เป็นเช่นนั้น แต่ให้ใช้ประเภทที่แสดงเจตนาอย่าง uintptr_t หรือ intptr_t แทน หากต้องการจัดเก็บความแตกต่างระหว่างพอยน์เตอร์ 2 ตัว ให้ใช้ประเภท ptrdiff_t

คุณควรเลือกใช้ประเภทจำนวนเต็มที่มีความกว้างคงที่และเฉพาะเจาะจงซึ่งกำหนดไว้ใน <stdint.h> เสมอ แทนที่จะใช้ประเภทที่มีความกว้างไม่คงที่ เช่น int หรือ long แม้ว่าจะไม่ใช่พอยน์เตอร์ก็ตาม

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

-Werror=pointer-to-int-cast
-Werror=int-to-pointer-cast
-Werror=shorten-64-to-32

คลาส Java ที่มีช่อง int ซึ่งเก็บพอยเตอร์ไปยังออบเจ็กต์ C/C++ จะมีปัญหาเดียวกัน ค้นหา jint ในแหล่งที่มา JNI และตรวจสอบว่าคุณเปลี่ยนไปใช้ long ในฝั่ง Java และ jlong ในฝั่ง C++

การประกาศฟังก์ชันโดยนัยเป็นอันตรายต่อโค้ด 64 บิตมากกว่ามาก C/C++ ถือว่าประเภทการแสดงผลของฟังก์ชันที่ประกาศโดยนัย (นั่นคือฟังก์ชันที่คอมไพเลอร์ไม่เห็นการประกาศ) คือ int หากประเภทการแสดงผลจริงของฟังก์ชันเป็นตัวชี้ ฟังก์ชันนี้จะทำงานได้ดีในระบบ 32 บิตที่ตัวชี้พอดีกับ int อย่างไรก็ตาม ในระบบ 64 บิต คอมไพเลอร์จะทิ้งครึ่งบนของตัวชี้ เช่น

// This function returns a pointer:
// extern char* foo();

// If you don't include a header that declares it,
// when the compiler sees this:
char* result = foo();

// Instead of compiling that to:
result = foo();

// It compiles to something equivalent to:
result = foo() & 0xffffffff;

// Which will then cause a SIGSEGV if you try to dereference `result`.

แฟล็กคอมไพเลอร์ต่อไปนี้จะเปลี่ยนคำเตือนการประกาศฟังก์ชันโดยนัยเป็นข้อผิดพลาด เพื่อให้คุณค้นหาและแก้ไขปัญหานี้ได้ง่ายขึ้น

-Werror=implicit-function-declaration

หากคุณมีแอสเซมเบลอร์ในบรรทัด ให้เขียนใหม่หรือใช้การติดตั้งใช้งาน C/C++ แบบธรรมดา

หากคุณมีขนาดของประเภทที่ฮาร์ดโค้ด (เช่น 8 หรือ 16 ไบต์) ให้แทนที่ด้วยนิพจน์ sizeof(T) ที่เทียบเท่า เช่น sizeof(void*)

หากต้องการคอมไพล์โค้ดที่แตกต่างกันสำหรับ 32 บิตและ 64 บิตแบบมีเงื่อนไข คุณสามารถใช้ #if defined(__LP64__) สำหรับความแตกต่างทั่วไปของ 32/64 บิต หรือ __arm__, __aarch64__ (arm64), __i386__ (x86) และ __x86_64__ สำหรับสถาปัตยกรรมเฉพาะที่ Android รองรับ

ปรับสตริงรูปแบบสำหรับฟังก์ชันที่คล้ายกับ printf หรือ scanf เนื่องจากตัวระบุรูปแบบแบบดั้งเดิมไม่อนุญาตให้คุณระบุประเภท 64 บิตในลักษณะที่ถูกต้องสำหรับทั้งอุปกรณ์ 32 บิตและ 64 บิต มาโคร PRI และ SCN ใน <inttypes.h> จะช่วยแก้ปัญหานี้ โดย PRIxPTR และ SCNxPTR ใช้สำหรับการเขียนและอ่านพอยน์เตอร์เลขฐานสิบหก ส่วน PRId64 และ SCNd64 ใช้สำหรับการเขียนและอ่านค่า 64 บิตแบบพกพา

เมื่อเลื่อน คุณอาจต้องใช้ 1ULL เพื่อรับค่าคงที่ 64 บิตเพื่อเลื่อนแทนที่จะใช้ 1 ซึ่งมีเพียง 32 บิต

ลดขนาดที่เพิ่มขึ้นด้วย Android App Bundle

การเพิ่มการรองรับสถาปัตยกรรม 64 บิตลงในแอปอาจทำให้ขนาด APK เพิ่มขึ้น เราขอแนะนำอย่างยิ่งให้ใช้ประโยชน์จากฟีเจอร์ Android App Bundle เพื่อลดผลกระทบด้านขนาดจากการรวมโค้ดแบบเนทีฟทั้ง 32 บิตและ 64 บิตไว้ใน APK เดียวกัน

นักพัฒนาเกม

เครื่องมือที่ใช้กันมากที่สุด 3 รายการรองรับ 64 บิต ได้แก่

• Unreal ตั้งแต่ปี 2015
• Cocos2d ตั้งแต่ปี 2015
• Unity ตั้งแต่ปี 2018

นักพัฒนา Unity

อัปเกรดเป็นเวอร์ชันที่รองรับ

Unity รองรับ 64 บิตในเวอร์ชัน 2018.2 และ 2017.4.16

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

แผนภูมิต่อไปนี้แสดง Unity เวอร์ชันต่างๆ และสิ่งที่คุณควรทำ

เปลี่ยนการตั้งค่าบิลด์เพื่อแสดงผลไลบรารี 64 บิต

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

1. ไปที่ Build Settings และตรวจสอบว่าคุณกำลังสร้างสำหรับ Android โดยยืนยันว่าสัญลักษณ์ Unity อยู่ข้าง Android ในส่วน Platform 1. หากสัญลักษณ์ Unity ไม่ได้อยู่ข้างแพลตฟอร์ม Android ให้เลือก Android แล้วคลิก Switch Platform

2. คลิกการตั้งค่าเพลเยอร์

   

3. ไปที่แผงการตั้งค่าโปรแกรมเล่น > การตั้งค่าสำหรับ Android > การตั้งค่าอื่นๆ > การกำหนดค่า

4. ตั้งค่า Scripting Backend เป็น IL2CPP

5. เลือกช่องทำเครื่องหมายสถาปัตยกรรมเป้าหมาย > ARM64

   

6. สร้างตามปกติ

โปรดทราบว่าการสร้างสำหรับ ARM64 กำหนดให้ต้องสร้างชิ้นงานทั้งหมดสำหรับแพลตฟอร์มนั้นโดยเฉพาะ ทำตามคำแนะนำของ Unity ในการลดขนาด APK และพิจารณาใช้ประโยชน์จากฟีเจอร์ Android App Bundle เพื่อช่วยลดขนาดที่เพิ่มขึ้นนี้

การปฏิบัติตามข้อกำหนดของ Multi-APK และ 64 บิต

หากคุณใช้การรองรับ APK หลายรายการของ Google Play เพื่อเผยแพร่แอป โปรดทราบว่าระบบจะประเมินการปฏิบัติตามข้อกำหนด 64 บิตที่ระดับรุ่น อย่างไรก็ตาม ข้อกำหนด 64 บิตไม่มีผลกับ APK หรือ App Bundle ที่ไม่ได้เผยแพร่ไปยังอุปกรณ์ที่ใช้ Android 9 Pie ขึ้นไป

หาก APK รายการใดรายการหนึ่งของคุณถูกทำเครื่องหมายว่าไม่เป็นไปตามข้อกำหนด แต่เป็นเวอร์ชันก่อนหน้าและไม่สามารถทำให้เป็นไปตามข้อกำหนดได้ กลยุทธ์หนึ่งคือการเพิ่มแอตทริบิวต์ maxSdkVersion="27" ในองค์ประกอบ uses-sdk ในไฟล์ Manifest ของ APK นั้น APK นี้จะไม่ส่งไปยังอุปกรณ์ที่ใช้ Android 9 Pie ขึ้นไป และจะไม่บล็อกการปฏิบัติตามข้อกำหนดอีกต่อไป

การปฏิบัติตามข้อกำหนดของ RenderScript และ 64 บิต

หากแอปใช้ RenderScript และสร้างขึ้นด้วยเครื่องมือ Android เวอร์ชันก่อนหน้า คุณอาจเห็นปัญหาเกี่ยวกับการปฏิบัติตามข้อกำหนด 64 บิตสำหรับแอป หากใช้เครื่องมือสร้างเวอร์ชันก่อน 21.0.0 คอมไพเลอร์อาจสร้างบิตโค้ดลงในไฟล์ .bc ภายนอก ระบบไม่รองรับไฟล์ .bc เดิมเหล่านี้สำหรับสถาปัตยกรรม 64 บิตอีกต่อไป ดังนั้นการมีไฟล์ดังกล่าวใน APK จึงทำให้เกิดปัญหาด้านการปฏิบัติตามข้อกำหนด

ในการแก้ไขปัญหานี้ ให้นำไฟล์ .bc ออกจากโปรเจ็กต์ อัปเกรดสภาพแวดล้อมเป็น build-tools-21.0.0 ขึ้นไป และตั้งค่า renderscriptTargetApi ใน Android Studio เป็น 21 ขึ้นไป เพื่อบอกคอมไพเลอร์ไม่ให้สร้างไฟล์ .bc จากนั้นสร้างแอปใหม่ ตรวจสอบไฟล์ .bc และอัปโหลดไปยัง Play Console

ทดสอบแอปในฮาร์ดแวร์ 64 บิต

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

อุปกรณ์ 64 บิตเท่านั้น

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

• Google Pixel ที่มีอิมเมจระบบแบบ 64 บิตเท่านั้น
• โปรแกรมจำลองของ Android

Google Pixel ที่มีอิมเมจระบบแบบ 64 บิตเท่านั้น

เราได้จัดเตรียมอิมเมจระบบพิเศษที่มีสภาพแวดล้อมแบบ 64 บิตเท่านั้นที่เข้มงวดสำหรับอุปกรณ์ Pixel บางรุ่นเพื่ออำนวยความสะดวกในการพัฒนาและทดสอบแอป เดิมทีอิมเมจแบบ 64 บิตเท่านั้นเหล่านี้มีให้ใช้งานพร้อมกับอิมเมจระบบเวอร์ชันที่ใช้งานทั่วไปมาตรฐานสำหรับเวอร์ชันตัวอย่างของ Android 13 และ 14 แต่คุณสามารถใช้ต่อไปได้เมื่อทดสอบแอปเพื่อดูความเข้ากันได้กับระบบ 64 บิต

รับอิมเมจแบบ 64 บิตเท่านั้น

คุณสามารถแฟลชอิมเมจแบบ 64 บิตเท่านั้นลงในอุปกรณ์ได้โดยใช้ Android Flash Tool หรือแฟลชอุปกรณ์ด้วยตนเอง เช่นเดียวกับอิมเมจระบบจากโรงงาน ตามที่อธิบายไว้ในส่วนต่อไปนี้

แฟลชอุปกรณ์โดยใช้ Android Flash Tool

Android Flash Tool ช่วยให้คุณแฟลชอิมเมจระบบลงในอุปกรณ์ Pixel ที่รองรับได้อย่างปลอดภัย Android Flash Tool ทำงานร่วมกับเว็บเบราว์เซอร์ที่รองรับ WebUSB เช่น Chrome หรือ Edge 79 ขึ้นไป

Android Flash Tool จะแนะนำขั้นตอนการแฟลชอุปกรณ์ทีละขั้นตอน คุณไม่จำเป็นต้องติดตั้งเครื่องมือใดๆ แต่ต้องปลดล็อกอุปกรณ์และเปิดใช้การแก้ไขข้อบกพร่อง USB ในตัวเลือกสำหรับนักพัฒนาแอป ดูวิธีการแบบสมบูรณ์ได้ในเอกสารประกอบของ Android Flash Tool

เชื่อมต่ออุปกรณ์ผ่าน USB จากนั้นไปที่ Android Flash Tool โดยใช้ลิงก์ใดลิงก์หนึ่งต่อไปนี้และทำตามคำแนะนำบนหน้าจอ ทั้งนี้ขึ้นอยู่กับประเภทอิมเมจระบบที่คุณต้องการแฟลช

• อิมเมจระบบ Android 14 (เบต้า 5.2) แบบ 64 บิตเท่านั้น

  เลือกอุปกรณ์ที่ต้องการแฟลช

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • Pixel 6 Pro

• อิมเมจระบบแบบ 64 บิตเท่านั้นของ Android 13 (QPR3 Beta 3.2)

  เลือกอุปกรณ์ที่ต้องการแฟลช

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • Pixel 6 Pro

แฟลชอุปกรณ์ด้วยตนเอง

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

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

คุณเลือกกลับไปใช้บิลด์สาธารณะล่าสุดได้ทุกเมื่อ

อิมเมจค่าเริ่มต้นแบบ 64 บิตเท่านั้นสำหรับ Android 14 (เบต้า 5.3)

อิมเมจเหล่านี้มีสภาพแวดล้อมแบบ 64 บิตเท่านั้นที่เข้มงวดสำหรับการทดสอบความเข้ากันได้ของแอป 64 บิต การกำหนดค่าเฉพาะ 64 บิตเหล่านี้มีไว้สำหรับนักพัฒนาแอปเท่านั้น

ค่าเริ่มต้นแบบ 64 บิตเท่านั้นสำหรับ Android 13 (QPR3 เบต้า 3.2)

อิมเมจเหล่านี้มีสภาพแวดล้อมแบบ 64 บิตเท่านั้นที่เข้มงวดสำหรับการทดสอบความเข้ากันได้ของแอป 64 บิต การกำหนดค่าแบบ 64 บิตเท่านั้นเหล่านี้มีไว้สำหรับนักพัฒนาแอปเท่านั้น

กลับไปใช้บิลด์สาธารณะ

คุณจะใช้ Android Flash Tool เพื่อแฟลชค่าเริ่มต้น หรือรับอิมเมจระบบตามข้อกำหนดของค่าเริ่มต้นจากหน้าค่าเริ่มต้นสำหรับอุปกรณ์ Nexus และ Pixel แล้วแฟลชลงในอุปกรณ์ด้วยตนเองก็ได้

โปรแกรมจำลองของ Android

ตั้งแต่ Android 12 (ระดับ API 31) เป็นต้นไป อิมเมจระบบของโปรแกรมจำลองของ Android จะเป็นแบบ 64 บิตเท่านั้น สร้างอุปกรณ์เสมือน Android (AVD) โดยใช้อิมเมจระบบที่มี Android 12 (ระดับ API 31) ขึ้นไปเพื่อให้ได้สภาพแวดล้อมแบบ 64 บิตเท่านั้นที่เข้มงวดสำหรับการทดสอบแอป

ตัวเลือกอุปกรณ์อื่นๆ

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

ติดตั้งและทดสอบแอป

วิธีที่ง่ายที่สุดในการทดสอบ APK คือการติดตั้งแอปโดยใช้ Android Debug Bridge (adb) ในกรณีส่วนใหญ่ คุณสามารถระบุ --abi เป็นพารามิเตอร์เพื่อระบุไลบรารีที่จะติดตั้งลงในอุปกรณ์ ซึ่งจะติดตั้งแอปที่มีเฉพาะไลบรารี 64 บิตในอุปกรณ์

:: Command Line
# A successful install:
> adb install --abi armeabi-v7a YOUR_APK_FILE.apk
Success

# If your APK does not have the 64-bit libraries:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
adb: failed to install YOUR_APK_FILE.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]

# If your device does not support 64-bit, an emulator, for example:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
ABI arm64-v8a not supported on this device

เมื่อติดตั้งเรียบร้อยแล้ว ให้ทดสอบแอปตามปกติเพื่อให้แน่ใจว่าคุณภาพเหมือนกับเวอร์ชัน 32 บิต

ตรวจสอบปัญหาความเข้ากันได้ที่ทราบ

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

SoLoader

หากคุณใช้ SDK ตัวโหลดโค้ดแบบเนทีฟ SoLoader ให้อัปเดตเป็นเวอร์ชัน 0.10.4 ขึ้นไป หากแอปใช้ SDK ที่ขึ้นอยู่กับ SoLoader โปรดอัปเดต SDK ที่ได้รับผลกระทบเป็นเวอร์ชันเสถียรล่าสุดด้วย

SoLoader v0.9.0 และต่ำกว่าคาดเดาว่าไลบรารีของระบบมีอยู่ใน /vendor/lib:/system/lib ข้อบกพร่องนี้ไม่สามารถสังเกตได้ในอุปกรณ์อย่าง Pixel 7 ที่มีเส้นทางอยู่ แต่สมมติฐานนี้ทำให้เกิดข้อขัดข้องในอุปกรณ์ที่มีเฉพาะไลบรารีระบบใน /vendor/lib64:/system/lib64

ดูข้อมูลเพิ่มเติมเกี่ยวกับการแก้ไขปัญหานี้และปัญหาอื่นๆ ที่เกิดจาก SoLoader ได้ที่คำตอบที่เกี่ยวข้องในศูนย์ช่วยเหลือของ Google

OpenSSL

หากคุณใช้ไลบรารี OpenSSL ให้อัปเดตเป็น OpenSSL 1.1.1i ขึ้นไป หากแอปใช้ SDK ที่ให้บริการการสื่อสารโดยใช้ HTTPS หรือ SDK อื่นๆ ที่ใช้ OpenSSL โปรดอัปเดต SDK ที่ใช้ OpenSSL เวอร์ชันใหม่กว่าเป็นเวอร์ชันล่าสุดด้วย โปรดติดต่อผู้ให้บริการ SDK หากไม่มีเวอร์ชันดังกล่าวให้ใช้งาน

ARMv8.3 PAC เปิดใช้ Control Flow Integrity ด้วยการตรวจสอบสิทธิ์ Pointer ขณะรันไทม์ OpenSSL เวอร์ชันก่อนหน้าใช้ความสามารถเหล่านี้อย่างไม่ถูกต้อง ซึ่งทำให้รันไทม์ขัดข้องในอุปกรณ์ทั้งหมดที่มีโปรเซสเซอร์ที่ใช้ ARMv8.3a ขึ้นไป

ดูข้อมูลเพิ่มเติมเกี่ยวกับการแก้ไขปัญหานี้และปัญหาอื่นๆ ที่เกิดจาก OpenSSL ได้ที่คำตอบที่เกี่ยวข้องในศูนย์ช่วยเหลือของ Google

BTI

ARMv8.5 ขึ้นไปใช้ Branch Target Instructions (BTI) เพื่อช่วยป้องกันการโจมตี JOP SDK ที่มีการสร้างความสับสนเวอร์ชันก่อนหน้าซึ่งแยกสาขาเป็นออฟเซ็ตแบบสุ่มของไลบรารีที่สร้างด้วย BTI อาจทําให้แอปขัดข้องได้ เนื่องจากวิธีการได้รับการเข้ารหัสเป็นคำแนะนำ ข้อบกพร่องนี้จึงไม่สามารถสังเกตได้ในอุปกรณ์ที่ไม่รองรับ BTI

เผยแพร่

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

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