รองรับสถาปัตยกรรม 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 โดยแต่ละโฟลเดอร์จะมีชุดไลบรารีเนทีฟ ที่เกี่ยวข้อง หากไม่มีการรองรับ 64 บิต คุณอาจเห็นโฟลเดอร์ ABI 32 บิต แต่ไม่เห็นโฟลเดอร์ 64 บิต

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

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

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

2. จากเมนู ให้เลือก Build > Analyze 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 เสมอ แม้ว่าจะไม่ใช่พอยน์เตอร์ก็ตาม

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

-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. ไปที่การตั้งค่าการสร้างและตรวจสอบว่าคุณกำลังสร้างสำหรับ Android โดย ยืนยันว่าสัญลักษณ์ Unity อยู่ข้าง Android ในส่วนแพลตฟอร์ม 1. หากไม่มีสัญลักษณ์ Unity อยู่ข้างแพลตฟอร์ม Android ให้เลือก Android แล้วคลิกเปลี่ยนแพลตฟอร์ม

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

   

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

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

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

   

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

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

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

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

  เลือกอุปกรณ์ที่คุณพยายามแฟลช

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

• อิมเมจระบบ 64 บิตเท่านั้นของ Android 13 (QPR3 เบต้า 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 Emulator ไม่ได้ ตัวเลือกที่ดีที่สุดถัดไปคือการใช้อุปกรณ์ที่รองรับ 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 ให้อัปเดตเป็น v0.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 ขึ้นไปใช้คำสั่งเป้าหมายของกิ่งก้าน (BTI) เพื่อช่วยป้องกันการโจมตีแบบ JOP การปิดบัง SDK เวอร์ชันก่อนหน้า ที่แยกเป็นออฟเซ็ตแบบสุ่มของไลบรารีที่สร้างด้วย BTI อาจทําให้แอป ขัดข้อง เนื่องจากมีการเข้ารหัสคำสั่งเป็นคำแนะนำ อุปกรณ์ที่ไม่รองรับ BTI จึงไม่พบข้อบกพร่องนี้

เผยแพร่

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

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