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

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

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

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

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

ในกรณีทั่วไป APK หรือ App 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 ใช้สําหรับการเขียนและการอ่านเคอร์เซอร์ฐาน 16 และ 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. ไปที่แผงการตั้งค่าโปรแกรมเล่น > การตั้งค่าสำหรับ 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 ภายนอก สถาปัตยกรรม 64 บิตไม่รองรับไฟล์ .bc เดิมเหล่านี้อีกต่อไป ดังนั้นการมีไฟล์ดังกล่าวใน 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 หรือแฟลชอุปกรณ์ด้วยตนเอง เช่นเดียวกับอิมเมจระบบของโรงงาน ตามที่อธิบายไว้ในส่วนต่อไปนี้

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

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

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

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

• ภาพระบบ Android 14 (เบต้า 5.2) 64 บิตเท่านั้น

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

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