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

หากคุณมี inline Aslicitr ให้เขียนใหม่หรือใช้ 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 บิต ดังนี้

• เหนือจริงตั้งแต่ปี 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 แล้วคลิก Switch Platform

2. คลิกการตั้งค่าโปรแกรมเล่น

   

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

4. ตั้งค่าแบ็กเอนด์สคริปต์เป็น 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 บิตเท่านั้นไปยัง โดยใช้เครื่องมือ Flash ของ Android หรือโดยแฟลช ด้วยตนเอง ตามที่อธิบายไว้ในส่วนต่อไปนี้

แฟลชอุปกรณ์ของคุณโดยใช้เครื่องมือ Flash ของ Android

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

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

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

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

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

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

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

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

  • 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 บิตเหล่านี้มีไว้สําหรับนักพัฒนาซอฟต์แวร์เท่านั้น

กลับไปยังบิลด์สาธารณะ

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

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

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

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

หากคุณไม่มีอุปกรณ์เหล่านี้ หรือไม่สามารถใช้ Android Emulator ทางเลือกที่ดีที่สุดคือใช้อุปกรณ์ ที่รองรับระบบ 64 บิต เช่น Pixel หรืออุปกรณ์หลักรุ่นใหม่ล่าสุดจากผู้ผลิตอุปกรณ์รายอื่น

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

วิธีที่ง่ายที่สุดในการทดสอบ APK คือการติดตั้งแอปโดยใช้ Android Debug ตัวเชื่อม (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 เปิดใช้การควบคุมด้วยฮาร์ดแวร์ ความสมบูรณ์ของโฟลว์โดยการตรวจสอบสิทธิ์ตัวชี้ขณะรันไทม์ เวอร์ชันก่อนหน้าของ OpenSSL ใช้ความสามารถเหล่านี้อย่างไม่ถูกต้อง ทำให้รันไทม์ขัดข้อง อุปกรณ์ที่ใช้โปรเซสเซอร์ที่ใช้ ARMv8.3a ขึ้นไป

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

BTI

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

เผยแพร่

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

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