คำถามที่พบบ่อย

Google ใช้ A/B OTA บนอุปกรณ์ใดบ้างหรือไม่

ใช่. ชื่อทางการตลาดสำหรับการอัปเดต A/B คือ การอัปเดตที่ราบรื่น โทรศัพท์ Pixel และ Pixel XL ตั้งแต่เดือนตุลาคม 2016 จัดส่งมาพร้อมกับ A/B และ Chromebook ทั้งหมดใช้การใช้งาน update_engine ของ A/B แบบเดียวกัน การใช้งานโค้ดแพลตฟอร์มที่จำเป็นเป็นแบบสาธารณะใน Android 7.1 และสูงกว่า

เหตุใด A/B OTA จึงดีกว่า

A/B OTA มอบประสบการณ์ผู้ใช้ที่ดีขึ้นเมื่อทำการอัปเดต การวัดผลจากการอัปเดตความปลอดภัยรายเดือนแสดงให้เห็นว่าฟีเจอร์นี้พิสูจน์แล้วว่าประสบความสำเร็จแล้ว โดย ณ เดือนพฤษภาคม 2017 เจ้าของ Pixel 95% ใช้งานการอัปเดตความปลอดภัยล่าสุดหลังจากผ่านไปหนึ่งเดือน เทียบกับผู้ใช้ Nexus 87% และผู้ใช้ Pixel อัปเดตเร็วกว่าผู้ใช้ Nexus ความล้มเหลวในการอัปเดตบล็อกระหว่าง OTA จะไม่ส่งผลให้อุปกรณ์ไม่สามารถบู๊ตได้อีกต่อไป จนกว่าอิมเมจระบบใหม่จะบูตได้สำเร็จ Android จะยังคงสามารถย้อนกลับไปใช้อิมเมจระบบการทำงานก่อนหน้าได้

A/B ส่งผลต่อขนาดพาร์ติชันพิกเซลปี 2559 อย่างไร

ตารางต่อไปนี้ประกอบด้วยรายละเอียดเกี่ยวกับการกำหนดค่า A/B ในการจัดส่งเทียบกับการกำหนดค่าที่ไม่ใช่ A/B ที่ทดสอบภายใน:

การอัปเดต A/B ต้องการเพิ่มขึ้นเพียง 320 MiB ในแฟลช โดยประหยัดได้ 32MiB จากการถอดพาร์ติชันการกู้คืน และอีก 100MiB จะคงไว้โดยการลบพาร์ติชันแคช สิ่งนี้จะสมดุลต้นทุนของพาร์ติชัน B สำหรับ bootloader พาร์ติชันสำหรับเริ่มระบบ และพาร์ติชันวิทยุ พาร์ติชันของผู้จำหน่ายมีขนาดเพิ่มขึ้นสองเท่า (ขนาดส่วนใหญ่เพิ่มขึ้น) อิมเมจระบบ A/B ของ Pixel มีขนาดเพียงครึ่งหนึ่งของอิมเมจระบบที่ไม่ใช่ A/B ดั้งเดิม

สำหรับรุ่น Pixel A/B และรุ่นที่ไม่ใช่ A/B ที่ทดสอบภายใน (จัดส่ง A/B เท่านั้น) พื้นที่ที่ใช้ต่างกันเพียง 320MiB บนอุปกรณ์ 32GiB นี่เป็นเพียงไม่ถึง 1% สำหรับอุปกรณ์ 16GiB ค่านี้จะน้อยกว่า 2% และสำหรับอุปกรณ์ 8GiB เกือบ 4% (สมมติว่าอุปกรณ์ทั้งสามเครื่องมีอิมเมจระบบเดียวกัน)

ทำไมคุณไม่ใช้ SquashFS?

เราทดลองกับ SquashFS แต่ไม่สามารถบรรลุประสิทธิภาพที่ต้องการสำหรับอุปกรณ์ระดับไฮเอนด์ได้ เราไม่ใช้หรือแนะนำ SquashFS สำหรับอุปกรณ์มือถือ

โดยเฉพาะอย่างยิ่ง SquashFS ประหยัดขนาดพาร์ติชันระบบได้ประมาณ 50% แต่ไฟล์ส่วนใหญ่ที่ได้รับการบีบอัดอย่างดีนั้นเป็นไฟล์ .odex ที่คอมไพล์แล้ว ไฟล์เหล่านั้นมีอัตราส่วนการบีบอัดที่สูงมาก (เกือบ 80%) แต่อัตราส่วนการบีบอัดสำหรับส่วนที่เหลือของพาร์ติชันระบบนั้นต่ำกว่ามาก นอกจากนี้ SquashFS ใน Android 7.0 ยังทำให้เกิดข้อกังวลด้านประสิทธิภาพดังต่อไปนี้:

• Pixel มีแฟลชที่เร็วมากเมื่อเทียบกับอุปกรณ์รุ่นก่อนๆ แต่มีรอบ CPU สำรองไม่มาก ดังนั้นการอ่านไบต์จากแฟลชน้อยลงแต่ต้องใช้ CPU มากขึ้นสำหรับ I/O อาจเป็นปัญหาคอขวด
• การเปลี่ยนแปลง I/O ที่ทำงานได้ดีบนการวัดประสิทธิภาพปลอมที่ทำงานบนระบบที่ไม่ได้โหลด บางครั้งอาจทำงานได้ไม่ดีในกรณีการใช้งานจริงภายใต้โหลดในโลกแห่งความเป็นจริง (เช่น การเข้ารหัสลับบน Nexus 6)
• การเปรียบเทียบแสดงการถดถอย 85% ในบางสถานที่

เมื่อ SquashFS เติบโตและเพิ่มคุณสมบัติเพื่อลดผลกระทบของ CPU (เช่น ไวท์ลิสต์ของไฟล์ที่เข้าถึงได้ทั่วไปซึ่งไม่ควรบีบอัด) เราจะประเมินต่อไปและเสนอคำแนะนำแก่ผู้ผลิตอุปกรณ์

คุณลดขนาดของพาร์ติชันระบบลงครึ่งหนึ่งโดยไม่มี SquashFS ได้อย่างไร

แอปพลิเคชันจะถูกจัดเก็บไว้ในไฟล์ .apk ซึ่งจริงๆ แล้วเป็นไฟล์ ZIP ไฟล์ .apk แต่ละไฟล์มีไฟล์ .dex หนึ่งไฟล์ขึ้นไปที่มีรหัสไบต์ Dalvik แบบพกพา ไฟล์ .odex (.dex ที่ปรับให้เหมาะสม) จะแยกจากไฟล์ .apk และอาจมีรหัสเครื่องเฉพาะของอุปกรณ์ได้ หากมีไฟล์ .odex Android จะสามารถเรียกใช้แอปพลิเคชันด้วยความเร็วที่คอมไพล์ล่วงหน้าได้โดยไม่ต้องรอให้คอมไพล์โค้ดทุกครั้งที่เปิดแอปพลิเคชัน ไฟล์ .odex ไม่จำเป็นอย่างเคร่งครัด เพราะจริงๆ แล้ว Android สามารถเรียกใช้โค้ด .dex ได้โดยตรงผ่านการตีความหรือการคอมไพล์ Just-In-Time (JIT) แต่ไฟล์ .odex ให้การผสมผสานที่ดีที่สุดของความเร็วในการเปิดและความเร็วรันไทม์ หาก มีพื้นที่ว่าง

ตัวอย่าง: สำหรับไฟล์ที่ติดตั้งแล้ว file.txt จาก Nexus 6P ที่ใช้ Android 7.1 โดยมีขนาดอิมเมจระบบรวม 2628MiB (2755792836 ไบต์) การแยกย่อยของผู้มีส่วนร่วมที่ใหญ่ที่สุดในขนาดอิมเมจระบบโดยรวมตามประเภทไฟล์มีดังนี้:

ตัวเลขเหล่านี้คล้ายคลึงกับอุปกรณ์อื่นๆ เช่นกัน ดังนั้นในอุปกรณ์ Nexus/Pixel ไฟล์ .odex จะใช้พื้นที่ประมาณครึ่งหนึ่งของพาร์ติชันระบบ ซึ่งหมายความว่าเราสามารถใช้ ext4 ต่อไปได้ แต่เขียนไฟล์ .odex ไปยังพาร์ติชัน B ที่โรงงาน จากนั้นคัดลอกไปที่ /data ในการบูตครั้งแรก พื้นที่จัดเก็บข้อมูลจริงที่ใช้กับ ext4 A/B จะเหมือนกับ SquashFS A/B เพราะหากเราใช้ SquashFS เราจะจัดส่งไฟล์ .odex ที่เลือกใช้ล่วงหน้าไปที่ system_a แทนที่จะเป็น system_b

การไม่คัดลอกไฟล์ .odex ไปที่ /data หมายความว่าพื้นที่ที่บันทึกไว้ใน /system หายไปใน /data หรือไม่

ไม่อย่างแน่นอน บน Pixel พื้นที่ส่วนใหญ่ที่ไฟล์ .odex ใช้สำหรับแอป ซึ่งโดยทั่วไปจะมีอยู่ใน /data แอปเหล่านี้รับการอัปเดตของ Google Play ดังนั้นไฟล์ .apk และ .odex บนอิมเมจระบบจึงไม่ได้ใช้เกือบตลอดชีวิตของอุปกรณ์ ไฟล์ดังกล่าวสามารถแยกออกทั้งหมดได้และแทนที่ด้วยไฟล์ .odex ขนาดเล็กที่ขับเคลื่อนด้วยโปรไฟล์ เมื่อผู้ใช้ใช้งานแต่ละแอปจริงๆ (จึงไม่ต้องใช้พื้นที่สำหรับแอปที่ผู้ใช้ไม่ได้ใช้) สำหรับรายละเอียด โปรดดูการพูดคุยของ Google I/O 2016 เรื่อง The Evolution of Art

การเปรียบเทียบทำได้ยากด้วยเหตุผลสำคัญบางประการ:

• แอปที่อัปเดตโดย Google Play จะมีไฟล์ .odex อยู่ใน /data เสมอทันทีที่ได้รับการอัปเดตครั้งแรก
• แอปที่ผู้ใช้ไม่ได้ใช้งานไม่จำเป็นต้องมีไฟล์ .odex เลย
• การคอมไพล์ที่ขับเคลื่อนด้วยโปรไฟล์จะสร้างไฟล์ .odex ที่เล็กกว่าการคอมไพล์ล่วงหน้า (เนื่องจากแบบแรกจะปรับให้เหมาะสมเฉพาะโค้ดที่มีความสำคัญต่อประสิทธิภาพเท่านั้น)

สำหรับรายละเอียดเกี่ยวกับตัวเลือกการปรับแต่งที่มีให้สำหรับ OEM โปรดดู การกำหนดค่า ART

มีไฟล์ .odex สองชุดอยู่ใน /data หรือไม่

ซับซ้อนกว่านี้เล็กน้อย ... หลังจากเขียนอิมเมจระบบใหม่แล้ว dex2oat เวอร์ชันใหม่จะถูกรันโดยเทียบกับไฟล์ .dex ใหม่เพื่อสร้างไฟล์ .odex ใหม่ สิ่งนี้เกิดขึ้นในขณะที่ระบบเก่ายังคงทำงานอยู่ ดังนั้นไฟล์ .odex เก่าและใหม่จึงอยู่บน /data ในเวลาเดียวกัน

รหัสใน OtaDexoptService ( frameworks/base/+/main/services/core/java/com/android/server/pm/OtaDexoptService.java ) เรียก getAvailableSpace ก่อนที่จะเพิ่มประสิทธิภาพแต่ละแพ็คเกจเพื่อหลีกเลี่ยงการเติมมากเกินไป /data โปรดทราบว่า ที่ นี่ยังคงเป็นแบบอนุรักษ์นิยม นั่นคือจำนวนพื้นที่ว่าง ก่อนที่ จะถึงเกณฑ์พื้นที่ว่างของระบบตามปกติ (วัดเป็นทั้งเปอร์เซ็นต์และจำนวนไบต์) ดังนั้นหาก /data เต็ม ไฟล์ .odex ทุกไฟล์จะไม่มีสำเนาสองชุด รหัสเดียวกันนี้ยังมี BULK_DELETE_THRESHOLD: หากอุปกรณ์ใกล้จะเต็มพื้นที่ว่าง (ตามที่อธิบายไว้) ไฟล์ .odex ที่เป็นของแอปที่ไม่ได้ใช้จะถูกลบออก นั่นเป็นอีกกรณีหนึ่งที่ไม่มีสำเนาทุกไฟล์ .odex สองชุด

ในกรณีที่เลวร้ายที่สุดที่ /data เต็มโดยสมบูรณ์ การอัปเดตจะรอจนกว่าอุปกรณ์จะรีบูตเข้าสู่ระบบใหม่และไม่ต้องการไฟล์ .odex ของระบบเก่าอีกต่อไป PackageManager จัดการสิ่งนี้: ( frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215 ) หลังจากที่ระบบใหม่บูตสำเร็จแล้ว installd ( frameworks/native/+/main/cmds/installd/dexopt.cpp#2422 ) สามารถลบไฟล์ .odex ที่ใช้โดยระบบเก่า ทำให้อุปกรณ์กลับสู่สถานะคงที่ โดยมีสำเนาเพียงฉบับเดียว

ดังนั้น แม้ว่า /data จะมีสำเนาไฟล์ .odex ทั้งหมดสองชุด แต่ (a) นี่เป็นเพียงสำเนาชั่วคราว และ (b) จะเกิดขึ้นก็ต่อเมื่อคุณมีพื้นที่ว่างบน /data มากพอเท่านั้น ยกเว้นในระหว่างการอัพเดต จะมีเพียงสำเนาเดียวเท่านั้น และในฐานะส่วนหนึ่งของคุณสมบัติความทนทานทั่วไปของ ART มันจะไม่เติม /data ด้วยไฟล์ .odex เลย (เพราะนั่นอาจเป็นปัญหากับระบบที่ไม่ใช่ A/B เช่นกัน)

การเขียน/การคัดลอกทั้งหมดนี้ไม่ได้เพิ่มการสึกหรอของแฟลชใช่ไหม

มีเพียงส่วนเล็กๆ ของแฟลชเท่านั้นที่ถูกเขียนใหม่: การอัปเดตระบบ Pixel แบบเต็มเขียนประมาณ 2.3GiB (แอปต่างๆ จะได้รับการคอมไพล์ใหม่ด้วยเช่นกัน แต่ก็ใช้ได้กับโปรแกรมที่ไม่ใช่ A/B เช่นกัน) ตามธรรมเนียมแล้ว OTA เต็มรูปแบบแบบบล็อกจะเขียนข้อมูลในปริมาณที่ใกล้เคียงกัน ดังนั้นอัตราการสึกหรอของแฟลชจึงควรใกล้เคียงกัน

การกะพริบสองพาร์ติชันระบบจะทำให้เวลาการแฟลชจากโรงงานเพิ่มขึ้นหรือไม่

ไม่ พิกเซลไม่ได้เพิ่มขนาดรูปภาพของระบบ (เพียงแบ่งพื้นที่ออกเป็นสองพาร์ติชัน)

การไม่เก็บไฟล์ .odex ไว้ที่ B ทำให้การรีบูตหลังจากข้อมูลจากโรงงานรีเซ็ตช้าใช่หรือไม่

ใช่. หากคุณใช้อุปกรณ์จริง ใช้ OTA และรีเซ็ตข้อมูลเป็นค่าเริ่มต้น การรีบูตครั้งแรกจะช้ากว่าปกติ (1 นาที 40 วินาที เทียบกับ 40 วินาทีบน Pixel XL) เนื่องจากไฟล์ .odex จะสูญหายไปจาก B หลังจาก OTA แรก และไม่สามารถคัดลอกไปยัง /data ได้ นั่นคือการแลกเปลี่ยน

การรีเซ็ตข้อมูลเป็นค่าเริ่มต้นควรเป็นการดำเนินการที่ไม่ค่อยพบนักเมื่อเทียบกับการบูตปกติ ดังนั้นเวลาที่ใช้จึงมีความสำคัญน้อยกว่า (ซึ่งจะไม่ส่งผลกระทบต่อผู้ใช้หรือผู้ตรวจสอบที่ได้รับอุปกรณ์มาจากโรงงาน เพราะในกรณีนั้น พาร์ติชัน B จะพร้อมใช้งาน) การใช้คอมไพเลอร์ JIT หมายความว่าเราไม่จำเป็นต้องคอมไพล์ ใหม่ทั้งหมด ดังนั้นจึงไม่แย่เท่าคุณ อาจจะคิด. นอกจากนี้ยังสามารถทำเครื่องหมายแอปว่าต้องมีการคอมไพล์ล่วงหน้าโดยใช้ coreApp="true" ในรายการ: ( frameworks/base/+/main/packages/SystemUI/AndroidManifest.xml#23 ) ขณะนี้ระบบใช้สิ่งนี้โดย system_server เนื่องจากไม่ได้รับอนุญาตให้ JIT ด้วยเหตุผลด้านความปลอดภัย

ไม่เก็บไฟล์ .odex ไว้ /data มากกว่า /system ทำให้การรีบูตหลังจาก OTA ช้าใช่หรือไม่

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

เราสามารถ (ควร) จัดส่งอุปกรณ์ 32GiB A/B ได้หรือไม่ 16กิ๊บ? 8GiB?

32GiB ทำงานได้ดีเหมือนที่ได้รับการพิสูจน์แล้วบน Pixel และ 320MiB จาก 16GiB หมายถึงการลดลง 2% ในทำนองเดียวกัน 320MiB จาก 8GiB ลดลง 4% แน่นอนว่า A/B ไม่ใช่ตัวเลือกที่แนะนำบนอุปกรณ์ที่มี 4GiB เนื่องจากค่าใช้จ่าย 320MiB นั้นเกือบ 10% ของพื้นที่ว่างทั้งหมด

AVB2.0 ต้องใช้ A/B OTA หรือไม่

ไม่ Android Verified Boot จำเป็นต้องมีการอัปเดตแบบบล็อกเสมอ แต่ไม่จำเป็นต้องอัปเดต A/B

A/B OTA ต้องใช้ AVB2.0 หรือไม่

เลขที่

A/B OTA ทำลายการป้องกันการย้อนกลับของ AVB2.0 หรือไม่

ไม่ มีความสับสนอยู่บ้าง เนื่องจากหากระบบ A/B ไม่สามารถบูตเข้าสู่อิมเมจระบบใหม่ได้ ระบบจะแปลงกลับเป็นอิมเมจระบบ "ก่อนหน้า" โดยอัตโนมัติ (หลังจากลองใหม่หลายครั้งซึ่งกำหนดโดยโปรแกรมโหลดบูตของคุณ) ประเด็นสำคัญที่นี่คือ "ก่อนหน้า" ในความหมาย A/B ยังคงเป็นอิมเมจระบบ "ปัจจุบัน" ทันทีที่อุปกรณ์บูทอิมเมจใหม่ได้สำเร็จ ระบบป้องกันการย้อนกลับจะเริ่มทำงานและทำให้แน่ใจว่าคุณจะไม่สามารถย้อนกลับได้ แต่จนกว่าคุณจะบูตอิมเมจใหม่ได้สำเร็จจริง การป้องกันการย้อนกลับจะไม่ถือว่าเป็นอิมเมจระบบปัจจุบัน

หากคุณกำลังติดตั้งการอัปเดตในขณะที่ระบบกำลังทำงานอยู่ มันก็ไม่ช้าใช่ไหม

สำหรับการอัปเดตที่ไม่ใช่ A/B จุดมุ่งหมายคือการติดตั้งการอัปเดตโดยเร็วที่สุดเนื่องจากผู้ใช้กำลังรอและไม่สามารถใช้อุปกรณ์ของตนได้ในขณะที่ใช้การอัปเดต ด้วยการอัปเดต A/B สิ่งที่ตรงกันข้ามจะเป็นจริง เนื่องจากผู้ใช้ยังคงใช้อุปกรณ์ของตน เป้าหมายจึงได้รับผลกระทบน้อยที่สุด ดังนั้นการอัปเดตจึงจงใจช้า ด้วยตรรกะในไคลเอนต์การอัปเดตระบบ Java (ซึ่งสำหรับ Google คือ GmsCore ซึ่งเป็นแพ็คเกจหลักที่ GMS มอบให้) Android ยังพยายามเลือกเวลาที่ผู้ใช้ไม่ได้ใช้อุปกรณ์เลย แพลตฟอร์มรองรับการหยุดชั่วคราว/ดำเนินการอัปเดตต่อ และไคลเอนต์สามารถใช้เพื่อหยุดการอัปเดตชั่วคราวหากผู้ใช้เริ่มใช้อุปกรณ์และดำเนินการต่อเมื่ออุปกรณ์ไม่ได้ใช้งานอีกครั้ง

มีสองขั้นตอนในขณะที่รับ OTA ซึ่งแสดงไว้อย่างชัดเจนใน UI เป็น ขั้นตอนที่ 1 จาก 2 และ ขั้นตอนที่ 2 จาก 2 ใต้แถบความคืบหน้า ขั้นตอนที่ 1 สอดคล้องกับการเขียนบล็อกข้อมูล ในขณะที่ขั้นตอนที่ 2 กำลังรวบรวมไฟล์ .dex ไว้ล่วงหน้า สองระยะนี้ค่อนข้างแตกต่างกันในแง่ของผลกระทบต่อประสิทธิภาพ ระยะแรกคือ I/O แบบธรรมดา สิ่งนี้ต้องการทรัพยากรเพียงเล็กน้อย (RAM, CPU, I/O) เนื่องจากเป็นการคัดลอกบล็อกไปรอบๆ อย่างช้าๆ

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

กระบวนการนี้คล้ายกับเมื่อ Google Play ติดตั้งการอัปเดตแอปในพื้นหลังก่อนที่จะแสดงการแจ้งเตือน ที่อัปเดตแอปทั้ง 5 รายการ ดังที่ทำมาหลายปีแล้ว

จะเกิดอะไรขึ้นหากผู้ใช้กำลังรอการอัปเดตจริงๆ

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

จะเกิดอะไรขึ้นหากใช้การอัปเดตล้มเหลว

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

ระบบใดบนชิป (SoC) รองรับ A/B

ณ วันที่ 15-03-2017 เรามีข้อมูลดังต่อไปนี้:

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