การเปลี่ยนแปลงลักษณะการทำงาน: แอปที่กำหนดเป้าหมายเป็น Android 16 ขึ้นไป

Android 16 มีการเปลี่ยนแปลงลักษณะการทำงานที่อาจส่งผลต่อแอปของคุณเช่นเดียวกับรุ่นก่อนหน้า การเปลี่ยนแปลงลักษณะการทำงานต่อไปนี้จะมีผลเฉพาะกับแอปที่กำหนดเป้าหมายเป็น Android 16 ขึ้นไป หากแอปกำหนดเป้าหมายเป็น Android 16 ขึ้นไป คุณควรแก้ไขแอปให้รองรับลักษณะการทำงานเหล่านี้ (หากมี)

อย่าลืมตรวจสอบรายการการเปลี่ยนแปลงลักษณะการทำงานที่ส่งผลต่อแอปทั้งหมดที่ทำงานใน Android 16 ด้วย ไม่ว่าแอปของคุณจะมี targetSdkVersion เป็นเวอร์ชันใดก็ตาม

ประสบการณ์ของผู้ใช้และ UI ของระบบ

Android 16 (ระดับ API 36) มีการเปลี่ยนแปลงต่อไปนี้ซึ่งมีจุดประสงค์เพื่อสร้างประสบการณ์ของผู้ใช้ที่สอดคล้องและใช้งานง่ายยิ่งขึ้น

การเลือกไม่ใช้การแสดงผลแบบไร้ขอบจะไม่มีให้ใช้งานอีกต่อไป

Android 15 บังคับใช้การแสดงผลแบบไร้ขอบสำหรับแอปที่กำหนดเป้าหมายเป็น Android 15 (API ระดับ 35) แต่แอปของคุณสามารถเลือกไม่ใช้ได้โดยตั้งค่า R.attr#windowOptOutEdgeToEdgeEnforcement เป็น true สำหรับแอปที่กำหนดเป้าหมายเป็น Android 16 (API ระดับ 36) ระบบจะเลิกใช้งานและปิดใช้ R.attr#windowOptOutEdgeToEdgeEnforcement และแอปของคุณจะเลือกไม่ใช้การแสดงผลแบบไร้ขอบไม่ได้

• หากแอปกำหนดเป้าหมายเป็น Android 16 (ระดับ API 36) และทำงานบนอุปกรณ์ Android 15 R.attr#windowOptOutEdgeToEdgeEnforcement จะยังคงทำงานต่อไป
• หากแอปกำหนดเป้าหมายเป็น Android 16 (API ระดับ 36) และทำงานในอุปกรณ์ Android 16 ระบบจะปิดใช้ R.attr#windowOptOutEdgeToEdgeEnforcement

สำหรับการทดสอบใน Android 16 ให้ตรวจสอบว่าแอปของคุณรองรับการแสดงผลแบบไร้ขอบและนำการใช้ R.attr#windowOptOutEdgeToEdgeEnforcement ออกเพื่อให้แอปของคุณรองรับการแสดงผลแบบไร้ขอบในอุปกรณ์ Android 15 ด้วย หากต้องการรองรับการแสดงผลแบบไร้ขอบ โปรดดูคำแนะนำเกี่ยวกับ Compose และ Views

ต้องย้ายข้อมูลหรือเลือกไม่ใช้การย้อนกลับที่คาดการณ์ได้

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

หากแอปของคุณขัดขวางเหตุการณ์การย้อนกลับและคุณยังไม่ได้ย้ายข้อมูลไปยังการย้อนกลับที่คาดการณ์ได้ ให้อัปเดตแอปเพื่อใช้ API การนำทางย้อนกลับที่รองรับ หรือเลือกไม่ใช้ชั่วคราวโดยตั้งค่าแอตทริบิวต์ android:enableOnBackInvokedCallback เป็น false ในแท็ก <application> หรือ <activity> ของไฟล์ AndroidManifest.xml ของแอป

Elegant font API เลิกใช้งานและปิดใช้แล้ว

แอปที่กำหนดเป้าหมายเป็น Android 15 (API ระดับ 35) จะมีแอตทริบิวต์ elegantTextHeight TextView ตั้งค่าเป็น true โดยค่าเริ่มต้น ซึ่งจะแทนที่แบบอักษรแบบย่อด้วยแบบอักษรที่อ่านง่ายกว่ามาก คุณลบล้างค่านี้ได้โดยตั้งค่าแอตทริบิวต์ elegantTextHeight เป็น false

Android 16 จะเลิกใช้งานแอตทริบิวต์ elegantTextHeight และระบบจะละเว้นแอตทริบิวต์เมื่อแอปกำหนดเป้าหมายเป็น Android 16 เราจะเลิกใช้ "UI fonts" ที่ควบคุมโดย API เหล่านี้ ดังนั้นคุณควรปรับเลย์เอาต์ใดๆ เพื่อให้การแสดงข้อความในภาษาอาหรับ ลาว เมียนมาร์ ทมิฬ คุชราต กันนาดา มาลายาลัม โอเดีย เตลูกู หรือไทยมีความสอดคล้องกันและพร้อมใช้งานในอนาคต

ลักษณะการทำงานของ

ลักษณะการทํางานของ

ฟังก์ชันหลัก

Android 16 (API ระดับ 36) มีการเปลี่ยนแปลงต่อไปนี้ซึ่งปรับเปลี่ยนหรือขยายความสามารถหลักต่างๆ ของระบบ Android

การเพิ่มประสิทธิภาพการจัดตารางเวลาการทำงานแบบอัตราคงที่

ก่อนที่จะกำหนดเป้าหมายเป็น Android 16 เมื่อ scheduleAtFixedRate พลาดการเรียกใช้งานเนื่องจากอยู่นอกวงจรการประมวลผลที่ถูกต้อง การเรียกใช้ทั้งหมดที่พลาดไปจะดำเนินการทันทีเมื่อแอปกลับไปยังวงจรการประมวลผลที่ถูกต้อง

เมื่อกำหนดเป้าหมายเป็น Android 16 ระบบจะเรียกใช้scheduleAtFixedRate ที่พลาดไปไม่เกิน1 ครั้งทันทีเมื่อแอปกลับมาอยู่ในวงจรที่ถูกต้อง การเปลี่ยนแปลงลักษณะการทำงานนี้คาดว่าจะช่วยปรับปรุงประสิทธิภาพของแอป ทดสอบลักษณะการทำงานนี้ในแอปเพื่อดูว่าแอปได้รับผลกระทบหรือไม่ นอกจากนี้ คุณยังทดสอบโดยใช้เฟรมเวิร์กความเข้ากันได้ของแอปและเปิดใช้ Flag STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS compat ได้ด้วย

รูปแบบของอุปกรณ์

Android 16 (ระดับ API 36) มีการเปลี่ยนแปลงต่อไปนี้สำหรับแอปเมื่อแสดงบนอุปกรณ์หน้าจอขนาดใหญ่

เลย์เอาต์แบบปรับขนาดได้

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

ละเว้นข้อจำกัดด้านการวางแนว ความสามารถในการปรับขนาด และสัดส่วนภาพ

สำหรับแอปที่กำหนดเป้าหมายเป็น Android 16 (ระดับ API 36) ข้อจำกัดด้านการวางแนว ความสามารถในการปรับขนาด และสัดส่วนการแสดงผลจะไม่มีผลกับจอแสดงผลที่มีความกว้างที่เล็กที่สุด >= 600dp อีกต่อไป แอปจะแสดงเต็มหน้าต่างแสดงผล ไม่ว่าสัดส่วนภาพหรือการวางแนวที่ผู้ใช้ต้องการจะเป็นอย่างไร และไม่มีการใช้แถบดำด้านข้าง

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

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

การเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบที่พบได้ทั่วไป

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

การอนุญาตให้หมุนอุปกรณ์จะส่งผลให้มีการสร้างกิจกรรมใหม่มากขึ้น ซึ่งอาจส่งผลให้สถานะของผู้ใช้สูญหายหากไม่ได้รับการเก็บรักษาอย่างเหมาะสม ดูวิธีบันทึกสถานะ UI อย่างถูกต้องในบันทึกสถานะ UI

รายละเอียดการใช้งาน

ระบบจะไม่สนใจแอตทริบิวต์ไฟล์ Manifest และ API รันไทม์ต่อไปนี้ในอุปกรณ์หน้าจอขนาดใหญ่ในโหมดเต็มหน้าจอและโหมดหลายหน้าต่าง

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

ระบบจะละเว้นค่าต่อไปนี้สำหรับ screenOrientation, setRequestedOrientation() และ getRequestedOrientation()

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

android:resizeableActivity="false", android:minAspectRatio และ android:maxAspectRatio จะไม่มีผลต่อความสามารถในการปรับขนาดการแสดงผล

สำหรับแอปที่กำหนดเป้าหมายเป็น Android 16 (ระดับ API 36) ระบบจะไม่สนใจข้อจำกัดด้านการวางแนว ความสามารถในการปรับขนาด และสัดส่วนการแสดงผลของแอปในหน้าจอขนาดใหญ่โดยค่าเริ่มต้น แอปที่ยังไม่พร้อมอย่างเต็มรูปแบบสามารถลบล้างลักษณะการทำงานนี้ชั่วคราวได้โดยเลือกไม่ใช้ ซึ่งจะส่งผลให้ลักษณะการทำงานก่อนหน้านี้อยู่ในโหมดความเข้ากันได้

ข้อยกเว้น

ข้อจำกัดด้านการวางแนว ความสามารถในการปรับขนาด และสัดส่วนการแสดงผลของ Android 16 จะไม่มีผลในสถานการณ์ต่อไปนี้

• เกม (อิงตามแฟล็ก android:appCategory)
• ผู้ใช้เลือกใช้ลักษณะการทำงานเริ่มต้นของแอปอย่างชัดแจ้งในการตั้งค่าสัดส่วนภาพของอุปกรณ์
• หน้าจอที่มีขนาดเล็กกว่า sw600dp

เลือกไม่ใช้ชั่วคราว

หากต้องการเลือกไม่ใช้กิจกรรมที่เฉพาะเจาะจง ให้ประกาศพร็อพเพอร์ตี้ไฟล์ Manifest PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY ดังนี้

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

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

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

สุขภาพและการออกกำลังกาย

Android 16 (API ระดับ 36) มีการเปลี่ยนแปลงต่อไปนี้ที่เกี่ยวข้องกับข้อมูลสุขภาพและการออกกำลังกาย

สิทธิ์ด้านสุขภาพและการออกกำลังกาย

สำหรับแอปที่กำหนดเป้าหมายเป็น Android 16 (API ระดับ 36) ขึ้นไป สิทธิ์ BODY_SENSORS จะใช้สิทธิ์ที่ละเอียดยิ่งขึ้นในส่วน android.permissions.health ซึ่ง Health Connect ก็ใช้ด้วย และตั้งแต่ Android 16 เป็นต้นไป API ใดก็ตามที่ก่อนหน้านี้ต้องใช้ BODY_SENSORS หรือ BODY_SENSORS_BACKGROUND จะต้องใช้สิทธิ์ android.permissions.health ที่เกี่ยวข้องแทน ซึ่งจะส่งผลต่อประเภทข้อมูล, API และประเภทบริการที่ทำงานอยู่เบื้องหน้าต่อไปนี้

• HEART_RATE_BPM จากบริการข้อมูลสุขภาพใน Wear OS
• Sensor.TYPE_HEART_RATE จาก Android Sensor Manager
• heartRateAccuracy และ heartRateBpm จาก ProtoLayout ใน Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH ในกรณีที่ต้องใช้สิทธิ์ android.permission.health ที่เกี่ยวข้องแทน BODY_SENSORS

หากแอปใช้ API เหล่านี้ แอปควรขอสิทธิ์แบบละเอียดที่เกี่ยวข้อง ดังนี้

• สำหรับการตรวจสอบอัตราการเต้นของหัวใจ ค่าความอิ่มตัวของออกซิเจนในเลือด หรืออุณหภูมิผิวหนังขณะใช้งาน ให้ขอสิทธิ์แบบละเอียดภายใต้ android.permissions.health เช่น READ_HEART_RATE แทน BODY_SENSORS
• สำหรับการเข้าถึงเซ็นเซอร์ในเบื้องหลัง: ให้ขอ READ_HEALTH_DATA_IN_BACKGROUND แทน BODY_SENSORS_BACKGROUND

สิทธิ์เหล่านี้เหมือนกับสิทธิ์ที่ป้องกันการเข้าถึงเพื่ออ่านข้อมูลจาก Health Connect ซึ่งเป็นพื้นที่เก็บข้อมูล Android สำหรับข้อมูลสุขภาพ การออกกำลังกาย และสุขภาวะ

แอปบนมือถือ

แอปบนมือถือที่ย้ายข้อมูลไปใช้ READ_HEART_RATE และสิทธิ์แบบละเอียดอื่นๆ จะต้องประกาศกิจกรรมเพื่อแสดงนโยบายความเป็นส่วนตัวของแอปด้วย ซึ่งเป็นข้อกำหนดเดียวกันกับ Health Connect

การเชื่อมต่อ

Android 16 (API ระดับ 36) มีการเปลี่ยนแปลงต่อไปนี้ในสแต็กบลูทูธเพื่อปรับปรุงการเชื่อมต่อกับอุปกรณ์ต่อพ่วง

Intent ใหม่เพื่อจัดการกับการสูญเสียการเชื่อมโยงและการเปลี่ยนแปลงการเข้ารหัส

การจัดการการสูญเสียการเชื่อมโยงที่ดีขึ้นทำให้ Android 16 เปิดตัว Intent ใหม่ 2 รายการเพื่อให้แอปรับรู้ถึงการสูญเสียการเชื่อมโยงและการเปลี่ยนแปลงการเข้ารหัสได้ดียิ่งขึ้น

ตอนนี้แอปที่กําหนดเป้าหมายเป็น Android 16 ทําสิ่งต่อไปนี้ได้

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

การปรับให้เข้ากับการใช้งาน OEM ที่หลากหลาย

แม้ว่า Android 16 จะเปิดตัว Intent ใหม่เหล่านี้ แต่การใช้งานและการออกอากาศอาจแตกต่างกันไปตามผู้ผลิตอุปกรณ์ (OEM) แต่ละราย นักพัฒนาแอปควรออกแบบการจัดการการสูญเสียการเชื่อมโยงให้ปรับให้เข้ากับการเปลี่ยนแปลงที่อาจเกิดขึ้นเหล่านี้ได้อย่างราบรื่น เพื่อให้แอปมอบประสบการณ์การใช้งานที่สอดคล้องกันและเชื่อถือได้ในอุปกรณ์ทุกเครื่อง

เราขอแนะนําลักษณะการทํางานของแอปดังต่อไปนี้

• หากมีการออกอากาศ Intent ACTION_KEY_MISSING ให้ทำดังนี้

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

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

  หากอุปกรณ์ตัดการเชื่อมต่อหลังจากได้รับ ACTION_KEY_MISSING แอปของคุณควรระมัดระวังเกี่ยวกับการเชื่อมต่ออีกครั้ง เนื่องจากอุปกรณ์อาจไม่ได้จับคู่กับระบบแล้ว

• หากไม่ได้ออกอากาศ Intent ACTION_KEY_MISSING

  ลิงก์ ACL จะยังคงเชื่อมต่ออยู่ และระบบจะนำข้อมูลการเชื่อมโยงของอุปกรณ์ออก เช่นเดียวกับลักษณะการทำงานใน Android 15

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

วิธีใหม่ในการนำการเชื่อมโยงบลูทูธออก

ตอนนี้แอปทั้งหมดที่กำหนดเป้าหมายเป็น Android 16 สามารถยกเลิกการจับคู่อุปกรณ์บลูทูธได้โดยใช้ API สาธารณะใน CompanionDeviceManager หากอุปกรณ์ที่ใช้ร่วมกันได้รับการจัดการเป็นการเชื่อมโยง CDM แอปจะทริกเกอร์การนำการเชื่อมโยงบลูทูธออกได้โดยใช้ removeBond(int) API ใหม่ในอุปกรณ์ที่เชื่อมโยง แอปสามารถตรวจสอบการเปลี่ยนแปลงสถานะการเชื่อมโยงได้โดยฟังเหตุการณ์การแพร่กระจายข้อมูลของอุปกรณ์บลูทูธ ACTION_BOND_STATE_CHANGED

ความปลอดภัย

Android 16 (API ระดับ 36) มีการเปลี่ยนแปลงด้านความปลอดภัยต่อไปนี้

การล็อกเวอร์ชัน MediaStore

สำหรับแอปที่กําหนดเป้าหมายเป็น Android 16 ขึ้นไป MediaStore#getVersion() จะมีลักษณะเฉพาะสำหรับแต่ละแอป ซึ่งจะนําพร็อพเพอร์ตี้ระบุออกจากสตริงเวอร์ชันเพื่อป้องกันการละเมิดและการใช้เทคนิคการระบุตัวตน แอปไม่ควรคาดเดารูปแบบของเวอร์ชันนี้ แอปควรจัดการการเปลี่ยนแปลงเวอร์ชันอยู่แล้วเมื่อใช้ API นี้ และในกรณีส่วนใหญ่ก็ไม่จำเป็นต้องเปลี่ยนแปลงลักษณะการทำงานปัจจุบัน เว้นแต่นักพัฒนาแอปจะพยายามอนุมานข้อมูลเพิ่มเติมที่อยู่นอกเหนือขอบเขตที่ตั้งใจไว้ของ API นี้

Intent ที่ปลอดภัยยิ่งขึ้น

ฟีเจอร์ Safer Intents เป็นโครงการริเริ่มด้านความปลอดภัยแบบหลายระยะที่ออกแบบมาเพื่อปรับปรุงความปลอดภัยของกลไกการแก้ไข Intent ของ Android เป้าหมายคือการปกป้องแอปจากการกระทำที่เป็นอันตรายโดยเพิ่มการตรวจสอบระหว่างการประมวลผล Intent และกรอง Intent ที่ไม่เป็นไปตามเกณฑ์ที่เฉพาะเจาะจง

ใน Android 15 ฟีเจอร์นี้จะมุ่งเน้นไปที่แอปที่ส่ง ตอนนี้ใน Android 16 การควบคุมจะเปลี่ยนไปที่แอปที่รับ ซึ่งช่วยให้นักพัฒนาแอปเลือกใช้การแปลง Intent ที่เข้มงวดได้โดยใช้ไฟล์ Manifest ของแอป

เรากำลังดำเนินการเปลี่ยนแปลงที่สำคัญ 2 ประการดังนี้

1. Intent ที่ชัดแจ้งต้องตรงกับตัวกรอง Intent ของคอมโพเนนต์เป้าหมาย: หาก Intent กำหนดเป้าหมายคอมโพเนนต์อย่างชัดแจ้ง ก็ควรตรงกับตัวกรอง Intent ของคอมโพเนนต์นั้น

2. Intent ที่ไม่มีการดำเนินการไม่สามารถจับคู่กับตัวกรอง Intent ใดๆ: Intent ที่ไม่ได้ระบุการดำเนินการไม่ควรได้รับการแก้ไขเป็นตัวกรอง Intent ใดๆ

การเปลี่ยนแปลงเหล่านี้จะมีผลเมื่อมีแอปหลายแอปเข้ามาเกี่ยวข้องเท่านั้น และจะไม่ส่งผลต่อการจัดการ Intent ภายในแอปเดียว

ผลกระทบ

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

• ทราบเกี่ยวกับฟีเจอร์ Safer Intents และประโยชน์ของฟีเจอร์นี้
• เลือกที่จะรวมแนวทางปฏิบัติในการจัดการ Intent ที่เข้มงวดมากขึ้นไว้ในแอปของตนอย่างสม่ำเสมอ

แนวทางการเลือกใช้นี้จะช่วยลดความเสี่ยงที่จะทำให้แอปที่มีอยู่ซึ่งอาจอาศัยลักษณะการทำงานของการแปลง Intent ที่มีความปลอดภัยน้อยกว่าในปัจจุบันใช้งานไม่ได้

แม้ว่าผลกระทบเบื้องต้นใน Android 16 อาจมีจำกัด แต่โครงการริเริ่ม Safer Intents ก็มีแผนกลยุทธ์สำหรับผลกระทบที่กว้างขึ้นใน Android รุ่นต่อๆ ไป เราวางแผนที่จะทำให้การแก้ไข Intent ที่เข้มงวดเป็นลักษณะการทำงานเริ่มต้นในท้ายที่สุด

ฟีเจอร์ Safer Intents มีศักยภาพในการเพิ่มความปลอดภัยของระบบนิเวศ Android อย่างมาก โดยทำให้แอปที่เป็นอันตรายใช้ประโยชน์จากช่องโหว่ในกลไกการแก้ไข Intent ได้ยากขึ้น

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

การใช้งาน

นักพัฒนาแอปต้องเปิดใช้การจับคู่ Intent ที่เข้มงวดขึ้นอย่างชัดเจนโดยใช้แอตทริบิวต์ intentMatchingFlags ในไฟล์ Manifest ของแอป ต่อไปนี้คือตัวอย่างที่ฟีเจอร์นี้เป็นแบบเลือกใช้สำหรับทั้งแอป แต่ปิดใช้/เลือกไม่ใช้ในตัวรับสัญญาณ

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

ข้อมูลเพิ่มเติมเกี่ยวกับแฟล็กที่รองรับ

การทดสอบและการแก้ไขข้อบกพร่อง

เมื่อการบังคับใช้ทำงานอยู่ แอปควรทำงานได้อย่างถูกต้องหากผู้เรียกใช้ Intent ได้ป้อนข้อมูล Intent อย่างเหมาะสม อย่างไรก็ตาม Intent ที่ถูกบล็อกจะทริกเกอร์ข้อความในบันทึกคำเตือน เช่น "Intent does not match component's intent filter:" และ "Access blocked:" พร้อมแท็ก "PackageManager." ซึ่งบ่งชี้ถึงปัญหาที่อาจเกิดขึ้นซึ่งอาจส่งผลต่อแอปและต้องได้รับการตรวจสอบ

ตัวกรอง Logcat:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

การกรอง Syscall ของ GPU

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

การเปลี่ยนแปลงนี้จะเกิดขึ้นในอุปกรณ์ Pixel ที่ใช้ Mali GPU (Pixel 6-9) Arm ได้จัดหมวดหมู่ IOCTL อย่างเป็นทางการไว้ในDocumentation/ioctl-categories.rstของรุ่น r54p2 เราจะยังคงดูแลรักษารายการนี้ต่อไปในไดรเวอร์รุ่นต่อๆ ไป

การเปลี่ยนแปลงนี้ไม่ส่งผลต่อ API กราฟิกที่รองรับ (รวมถึง Vulkan และ OpenGL) และคาดว่าจะไม่ส่งผลต่อนักพัฒนาแอปหรือแอปพลิเคชันที่มีอยู่ เครื่องมือสร้างโปรไฟล์ GPU เช่น Streamline Performance Analyzer และ Android GPU Inspector จะไม่ได้รับผลกระทบ

การทดสอบ

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

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

หากแอปพลิเคชันของคุณจำเป็นต้องใช้ IOCTL ที่ถูกบล็อก โปรดรายงานข้อบกพร่องและมอบหมายให้ android-partner-security@google.com

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

1. การเปลี่ยนแปลงนโยบายนี้มีผลกับ OEM ทั้งหมดไหม การเปลี่ยนแปลงนี้จะเป็นแบบเลือกใช้ แต่พร้อมให้บริการแก่ OEM ทุกรายที่ต้องการใช้วิธีการเพิ่มความปลอดภัยนี้ ดูวิธีการใช้การเปลี่ยนแปลงได้ในเอกสารประกอบเกี่ยวกับการใช้งาน

2. จำเป็นต้องทำการเปลี่ยนแปลงในฐานของโค้ด OEM เพื่อใช้ฟีเจอร์นี้ไหม หรือฟีเจอร์นี้มาพร้อมกับรุ่น AOSP ใหม่โดยค่าเริ่มต้น การเปลี่ยนแปลงระดับแพลตฟอร์มจะมาพร้อมกับรุ่น AOSP ใหม่โดยค่าเริ่มต้น ผู้ให้บริการสามารถเลือกใช้การเปลี่ยนแปลงนี้ในฐานของโค้ดได้หากต้องการใช้

3. SoC มีหน้าที่รับผิดชอบในการอัปเดตรายการ IOCTL ให้เป็นปัจจุบันอยู่เสมอใช่ไหม เช่น หากอุปกรณ์ของฉันใช้ ARM Mali GPU ฉันจะต้องติดต่อ ARM เพื่อทำการเปลี่ยนแปลงใดๆ ไหม SoC แต่ละรายการต้องอัปเดตรายการ IOCTL ต่ออุปกรณ์เมื่อมีการเผยแพร่ไดรเวอร์ ตัวอย่างเช่น ARM จะอัปเดตรายการ IOCTL ที่เผยแพร่เมื่อมีการอัปเดตไดรเวอร์ อย่างไรก็ตาม OEM ควรตรวจสอบว่าได้รวมการอัปเดตไว้ใน SEPolicy ของตน และเพิ่ม IOCTL ที่กำหนดเองที่เลือกไว้ลงในรายการตามความจำเป็น

4. การเปลี่ยนแปลงนี้จะมีผลกับอุปกรณ์ Pixel ทั้งหมดในตลาดโดยอัตโนมัติ หรือผู้ใช้ต้องดำเนินการเพื่อเปิด/ปิดบางอย่างเพื่อให้การเปลี่ยนแปลงนี้มีผลหรือไม่ การเปลี่ยนแปลงนี้จะมีผลกับอุปกรณ์ Pixel ทั้งหมดในตลาดที่ใช้ Mali GPU (Pixel 6-9) ผู้ใช้ไม่จำเป็นต้องดำเนินการใดๆ เพื่อใช้การเปลี่ยนแปลงนี้

5. การใช้นโยบายนี้จะส่งผลต่อประสิทธิภาพของไดรเวอร์เคอร์เนลไหม นโยบายนี้ได้รับการทดสอบบน Mali GPU โดยใช้ GFXBench และไม่พบการเปลี่ยนแปลงที่วัดได้ในประสิทธิภาพของ GPU

6. รายการ IOCTL จำเป็นต้องสอดคล้องกับเวอร์ชันพื้นที่ผู้ใช้และไดรเวอร์เคอร์เนลปัจจุบันหรือไม่ ใช่ รายการ IOCTL ที่อนุญาตต้องซิงค์กับ IOCTL ที่รองรับทั้งไดรเวอร์พื้นที่ผู้ใช้และไดรเวอร์เคอร์เนล หากมีการอัปเดต IOCTL ในพื้นที่ผู้ใช้หรือไดรเวอร์เคอร์เนล รายการ SEPolicy IOCTL จะต้องได้รับการอัปเดตให้ตรงกัน

7. ARM ได้จัดหมวดหมู่ IOCTL เป็น 'ถูกจำกัด' / 'การวัดคุม' แต่เราต้องการใช้บางรายการใน Use Case ของเวอร์ชันที่ใช้งานจริง และ/หรือปฏิเสธรายการอื่นๆ OEM/SoC แต่ละรายมีหน้าที่รับผิดชอบในการตัดสินใจว่าจะจัดหมวดหมู่ IOCTL ที่ใช้ตามการกำหนดค่าของไลบรารี Mali ในพื้นที่ผู้ใช้อย่างไร รายการของ ARM สามารถใช้เพื่อช่วยตัดสินใจเกี่ยวกับสิ่งเหล่านี้ได้ แต่กรณีการใช้งานของ OEM/SoC แต่ละรายอาจแตกต่างกัน

ความเป็นส่วนตัว

Android 16 (API ระดับ 36) มีการเปลี่ยนแปลงด้านความเป็นส่วนตัวต่อไปนี้

สิทธิ์สำหรับเครือข่ายภายใน

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

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

แผนการเผยแพร่

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

ผลกระทบ

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

แอปจะได้รับผลกระทบหากเข้าถึงเครือข่ายภายในของผู้ใช้โดยใช้สิ่งต่อไปนี้

• การใช้ซ็อกเก็ตข้อมูลดิบโดยตรงหรือผ่านไลบรารีในที่อยู่เครือข่ายภายใน (เช่น โปรโตคอล Service Discovery ของ mDNS หรือ SSDP)
• การใช้คลาสระดับเฟรมเวิร์กที่เข้าถึงเครือข่ายภายใน (เช่น NsdManager)

การรับส่งข้อมูลไปยังและจากที่อยู่เครือข่ายภายในต้องมีสิทธิ์เข้าถึงเครือข่ายภายใน ตารางต่อไปนี้แสดงกรณีที่พบบ่อยบางกรณี

ข้อจำกัดเหล่านี้จะใช้ในสแต็กเครือข่ายที่ลึกมาก จึงมีผลกับ API ของเครือข่ายทั้งหมด ซึ่งรวมถึงซ็อกเก็ตที่สร้างในโค้ดเนทีฟหรือโค้ดที่มีการจัดการ ไลบรารีเครือข่าย เช่น Cronet และ OkHttp และ API ที่ติดตั้งใช้งานบนไลบรารีเหล่านั้น การพยายามแก้ไขบริการในเครือข่ายภายใน (เช่น บริการที่มีคำต่อท้าย .local) จะต้องได้รับสิทธิ์เข้าถึงเครือข่ายภายใน

ข้อยกเว้นสำหรับกฎข้างต้นมีดังนี้

• หากเซิร์ฟเวอร์ DNS ของอุปกรณ์อยู่ในเครือข่ายภายใน การรับส่งข้อมูลไปยังหรือจากเซิร์ฟเวอร์ดังกล่าว (ที่พอร์ต 53) ไม่จำเป็นต้องมีสิทธิ์เข้าถึงเครือข่ายภายใน
• แอปพลิเคชันที่ใช้ตัวสลับเอาต์พุตเป็นเครื่องมือเลือกในแอปจะไม่ต้องใช้สิทธิ์เข้าถึงเครือข่าย LAN (จะมีคำแนะนำเพิ่มเติมในไตรมาสที่ 4 ของปี 2025)

คำแนะนำสำหรับนักพัฒนาแอป (เลือกรับ)

หากต้องการเลือกใช้ข้อจำกัดของเครือข่ายภายใน ให้ทำดังนี้

1. แฟลชอุปกรณ์เป็นบิลด์ที่มี 25Q2 Beta 3 ขึ้นไป
2. ติดตั้งแอปที่จะทดสอบ

3. สลับแฟล็ก Appcompat ใน adb โดยทำดังนี้

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. รีบูตอุปกรณ์

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

หากต้องการคืนค่าสิทธิ์เข้าถึง คุณต้องให้สิทธิ์ของแอปเข้าถึง NEARBY_WIFI_DEVICES

1. ตรวจสอบว่าแอปประกาศสิทธิ์ NEARBY_WIFI_DEVICES ในไฟล์ Manifest
2. ไปที่การตั้งค่า > แอป > [ชื่อแอปพลิเคชัน] > สิทธิ์ > อุปกรณ์ที่อยู่ใกล้เคียง > อนุญาต

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

เมื่อการบังคับใช้การปกป้องเครือข่ายภายในเริ่มต้นขึ้น การจราจรของข้อมูลในเครือข่ายของแอปจะได้รับผลกระทบดังนี้

ใช้คำสั่งต่อไปนี้เพื่อปิดแฟล็ก App-Compat

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

ข้อผิดพลาด

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

ตัวอย่างข้อผิดพลาด

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

คำจำกัดความของเครือข่ายภายใน

เครือข่ายภายในในโปรเจ็กต์นี้หมายถึงเครือข่าย IP ที่ใช้อินเทอร์เฟซเครือข่ายที่สามารถออกอากาศได้ เช่น Wi-Fi หรืออีเทอร์เน็ต แต่ไม่รวมการเชื่อมต่อเครือข่ายมือถือ (WWAN) หรือการเชื่อมต่อ VPN

เครือข่ายต่อไปนี้ถือเป็นเครือข่ายท้องถิ่น

IPv4:

• 169.254.0.0/16 // Link Local
• 100.64.0.0/10 // CGNAT
• 10.0.0.0/8 // RFC1918
• 172.16.0.0/12 // RFC1918
• 192.168.0.0/16 // RFC1918

IPv6:

• Link-local
• เส้นทางที่เชื่อมต่อโดยตรง
• เครือข่าย Stub เช่น Thread
• ซับเน็ตหลายรายการ (จะแจ้งภายหลัง)

นอกจากนี้ ทั้งที่อยู่แบบมัลติแคสต์ (224.0.0.0/4, ff00::/8) และที่อยู่ในการบรอดแคสต์ IPv4 (255.255.255.255) จะจัดอยู่ในประเภทที่อยู่เครือข่ายภายใน

รูปภาพที่แอปเป็นเจ้าของ

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