เช่นเดียวกับรุ่นก่อนๆ 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
Apps targeting Android 15 (API level 35) have the
elegantTextHeight
TextView attribute set to true by
default, replacing the compact font with one that is much more readable. You
could override this by setting the elegantTextHeight attribute to false.
Android 16 deprecates the
elegantTextHeight attribute,
and the attribute will be ignored once your app targets Android 16. The "UI
fonts" controlled by these APIs are being discontinued, so you should adapt any
layouts to ensure consistent and future proof text rendering in Arabic, Lao,
Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.
elegantTextHeight behavior for apps targeting Android
14 (API level 34) and lower, or for apps targeting Android 15 (API level 35)
that overrode the default by setting the elegantTextHeight
attribute to false.
elegantTextHeight behavior for apps targeting Android
16 (API level 36), or for apps targeting Android 15 (API level 35) that didn't
override the default by setting the elegantTextHeight attribute
to false.ฟังก์ชันหลัก
Android 16 (API ระดับ 36) มีการเปลี่ยนแปลงต่อไปนี้ซึ่งแก้ไขหรือ ขยายความสามารถหลักต่างๆ ของระบบ Android
การเพิ่มประสิทธิภาพการจัดกำหนดเวลางานแบบอัตราคงที่
在以 Android 16 为目标平台之前,如果 scheduleAtFixedRate 因不在有效的进程生命周期内而错过了任务执行,则当应用返回到有效的生命周期时,所有错过的执行会立即执行。
以 Android 16 为目标平台时,当应用返回到有效的生命周期时,系统会立即执行最多 1 次未执行的 scheduleAtFixedRate 执行。此行为变更预计会提升应用性能。在您的应用中测试此行为,检查您的应用是否受到影响。您还可以使用应用兼容性框架并启用 STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS 兼容性标志进行测试。
รูปแบบของอุปกรณ์
Android 16 (API ระดับ 36) มีการเปลี่ยนแปลงต่อไปนี้สำหรับแอปเมื่อ แสดงบนอุปกรณ์หน้าจอขนาดใหญ่
เลย์เอาต์แบบปรับขนาดได้
เนื่องจากตอนนี้แอป Android ทำงานบนอุปกรณ์ต่างๆ ได้แล้ว (เช่น โทรศัพท์ แท็บเล็ต อุปกรณ์พับได้ เดสก์ท็อป รถยนต์ และทีวี) และมีโหมดการจัดหน้าต่างบนหน้าจอขนาดใหญ่ (เช่น การแยกหน้าจอและการจัดหน้าต่างบนเดสก์ท็อป) นักพัฒนาแอปจึงควรสร้างแอป Android ที่ปรับให้เข้ากับขนาดหน้าจอและหน้าต่างได้ทุกขนาด ไม่ว่าอุปกรณ์จะอยู่ในแนวนอนหรือแนวตั้ง กระบวนทัศน์ต่างๆ เช่น การจำกัดการวางแนวและความสามารถในการปรับขนาด มีข้อจำกัดมากเกินไปในโลกที่มีอุปกรณ์หลายเครื่องในปัจจุบัน
ไม่สนใจข้อจำกัดด้านการวางแนว ความสามารถในการปรับขนาด และสัดส่วนภาพ
สำหรับแอปที่กำหนดเป้าหมายเป็น Android 16 (API ระดับ 36) ข้อจำกัดด้านการวางแนว ความสามารถในการปรับขนาด และอัตราส่วนจะไม่ใช้กับจอแสดงผลที่มีความกว้างน้อยที่สุด >= 600dp อีกต่อไป แอปจะแสดงเต็มหน้าต่างแสดงผล ไม่ว่าสัดส่วนภาพหรือการวางแนวที่ผู้ใช้ต้องการจะเป็นอย่างไร และจะไม่มีการใช้แถบดำด้านข้าง
การเปลี่ยนแปลงนี้จะทำให้แพลตฟอร์มมีลักษณะการทำงานมาตรฐานใหม่ Android กำลังเปลี่ยนไปใช้โมเดลที่คาดหวังให้แอปปรับให้เข้ากับการวางแนว ขนาดการแสดงผล และสัดส่วนภาพต่างๆ ข้อจำกัดต่างๆ เช่น การวางแนวคงที่ หรือการปรับขนาดที่จำกัด จะขัดขวางความสามารถในการปรับตัวของแอป ทำให้แอปของคุณ ปรับเปลี่ยนตามอุปกรณ์เพื่อมอบประสบการณ์ของผู้ใช้ที่ดีที่สุด
นอกจากนี้ คุณยังทดสอบลักษณะการทำงานนี้ได้โดยใช้เฟรมเวิร์กความเข้ากันได้ของแอปและเปิดใช้
UNIVERSAL_RESIZABLE_BY_DEFAULT compat flag
การเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบที่พบบ่อย
การไม่สนใจข้อจำกัดด้านการวางแนว ความสามารถในการปรับขนาด และสัดส่วนภาพอาจส่งผลต่อ UI ของแอปในอุปกรณ์บางเครื่อง โดยเฉพาะองค์ประกอบที่ออกแบบมาสำหรับเลย์เอาต์ขนาดเล็ก ที่ล็อกไว้ในแนวตั้ง เช่น ปัญหาต่างๆ เช่น เลย์เอาต์ที่ยืดออก และภาพเคลื่อนไหวและคอมโพเนนต์ที่อยู่นอกหน้าจอ การคาดเดาเกี่ยวกับสัดส่วนภาพหรือการวางแนวอาจทำให้เกิดปัญหาด้านภาพกับแอป ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีหลีกเลี่ยงปัญหาดังกล่าวและปรับปรุงลักษณะการทำงานแบบปรับเปลี่ยนได้ของแอป
การอนุญาตให้หมุนอุปกรณ์จะทำให้เกิดการสร้างกิจกรรมใหม่มากขึ้น ซึ่งอาจส่งผล ให้สถานะของผู้ใช้สูญหายหากไม่ได้เก็บรักษาไว้อย่างถูกต้อง ดูวิธีบันทึกสถานะ UI อย่างถูกต้องในบันทึกสถานะ UI
รายละเอียดการใช้งาน
ระบบจะละเว้นแอตทริบิวต์ในไฟล์ Manifest และ API รันไทม์ต่อไปนี้ในอุปกรณ์หน้าจอขนาดใหญ่ในโหมดเต็มหน้าจอและโหมดหลายหน้าต่าง
screenOrientationresizableActivityminAspectRatiomaxAspectRatiosetRequestedOrientation()getRequestedOrientation()
ระบบจะละเว้นค่าต่อไปนี้สำหรับ screenOrientation, setRequestedOrientation() และ getRequestedOrientation()
portraitreversePortraitsensorPortraituserPortraitlandscapereverseLandscapesensorLandscapeuserLandscape
ในส่วนของการปรับขนาดจอแสดงผล android:resizeableActivity="false",
android:minAspectRatio และ android:maxAspectRatio จะไม่มีผล
สำหรับแอปที่กำหนดเป้าหมายเป็น Android 16 (API ระดับ 36) ระบบจะละเว้นข้อจำกัดด้านการวางแนว ความสามารถในการปรับขนาด และสัดส่วนภาพของแอปในหน้าจอขนาดใหญ่โดยค่าเริ่มต้น แต่แอปทุกแอปที่ยังไม่พร้อมอย่างเต็มที่สามารถลบล้างลักษณะการทำงานนี้ชั่วคราวได้โดยการเลือกไม่ใช้ (ซึ่งจะส่งผลให้แอปมีลักษณะการทำงานก่อนหน้าคืออยู่ในโหมดความเข้ากันได้)
ข้อยกเว้น
ข้อจำกัดด้านการวางแนว ความสามารถในการปรับขนาด และสัดส่วนภาพของ Android 16 จะไม่ มีผลในกรณีต่อไปนี้
- เกม (อิงตามธง
android:appCategory) - ผู้ใช้เลือกใช้ลักษณะการทำงานเริ่มต้นของแอปอย่างชัดแจ้งในการตั้งค่าสัดส่วนภาพของอุปกรณ์
- หน้าจอที่มีขนาดเล็กกว่า
sw600dp
เลือกไม่ใช้ชั่วคราว
หากต้องการเลือกไม่ใช้กิจกรรมที่เฉพาะเจาะจง ให้ประกาศ
PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITYพร็อพเพอร์ตี้ของไฟล์ Manifest ดังนี้
<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 OSSensor.TYPE_HEART_RATEจาก Android Sensor ManagerheartRateAccuracyและheartRateBpmจากProtoLayoutใน Wear OSFOREGROUND_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) มีการเปลี่ยนแปลงต่อไปนี้ในสแต็กบลูทูธ เพื่อปรับปรุงการเชื่อมต่อกับอุปกรณ์ต่อพ่วง
เจตนาใหม่ในการจัดการการสูญเสียพันธะและการเปลี่ยนแปลงการเข้ารหัส
การจัดการการสูญเสียการเชื่อมโยงที่ดีขึ้นทำให้ Android 16 เปิดตัว Intent ใหม่ 2 รายการเพื่อให้แอปรับรู้ถึงการสูญเสียการเชื่อมโยงและการเปลี่ยนแปลงการเข้ารหัสได้ดียิ่งขึ้น
ตอนนี้แอปที่กําหนดเป้าหมายเป็น Android 16 ทําสิ่งต่อไปนี้ได้
- รับ Intent
ACTION_KEY_MISSINGเมื่อตรวจพบการสูญเสียการเชื่อมโยงระยะไกล ซึ่งช่วยให้สามารถแสดงความคิดเห็นที่เป็นประโยชน์ต่อผู้ใช้มากขึ้นและดำเนินการที่เหมาะสม - รับ Intent
ACTION_ENCRYPTION_CHANGEเมื่อใดก็ตามที่สถานะการเข้ารหัสของลิงก์มีการเปลี่ยนแปลง ซึ่งรวมถึงการเปลี่ยนแปลงสถานะการเข้ารหัส การเปลี่ยนแปลงอัลกอริทึมการเข้ารหัส และการเปลี่ยนแปลงขนาดคีย์การเข้ารหัส แอปต้องถือว่าการเชื่อมโยงได้รับการคืนค่าหากลิงก์ได้รับการเข้ารหัสเรียบร้อยแล้วเมื่อได้รับ IntentACTION_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 นี้
ความตั้งใจที่ปลอดภัยยิ่งขึ้น
ฟีเจอร์เจตนาที่ปลอดภัยยิ่งขึ้นเป็นโครงการริเริ่มด้านความปลอดภัยแบบหลายเฟสที่ออกแบบมาเพื่อ ปรับปรุงความปลอดภัยของกลไกการแก้ไขเจตนาของ Android เป้าหมายคือการปกป้องแอปจากการกระทำที่เป็นอันตรายด้วยการเพิ่มการตรวจสอบระหว่าง การประมวลผล Intent และการกรอง Intent ที่ไม่เป็นไปตามเกณฑ์ที่เฉพาะเจาะจง
ใน Android 15 ฟีเจอร์นี้มุ่งเน้นที่แอปที่ส่ง แต่ใน Android 16 จะเปลี่ยนการควบคุมไปที่แอปที่รับ ซึ่งช่วยให้นักพัฒนาแอปเลือกใช้ การแก้ปัญหา Intent ที่เข้มงวดได้โดยใช้ไฟล์ Manifest ของแอป
เราจะดำเนินการเปลี่ยนแปลงที่สำคัญ 2 อย่าง ดังนี้
Intent แบบเจาะจงปลายทางต้องตรงกับตัวกรอง Intent ของคอมโพเนนต์เป้าหมาย หาก Intent กำหนดเป้าหมายคอมโพเนนต์อย่างชัดแจ้ง Intent นั้นควรตรงกับ ตัวกรอง Intent ของคอมโพเนนต์นั้น
Intent ที่ไม่มีการดำเนินการจะจับคู่กับตัวกรอง Intent ไม่ได้: Intent ที่ไม่ได้ระบุการดำเนินการไม่ควรได้รับการแก้ไขเป็นตัวกรอง Intent ใดๆ
การเปลี่ยนแปลงเหล่านี้จะมีผลเมื่อเกี่ยวข้องกับแอปหลายแอปเท่านั้น และจะไม่มีผลต่อ การจัดการ Intent ภายในแอปเดียว
ผลกระทบ
ลักษณะการเลือกใช้หมายความว่านักพัฒนาแอปต้องเปิดใช้ฟีเจอร์นี้อย่างชัดแจ้งใน ไฟล์ Manifest ของแอปเพื่อให้มีผล ด้วยเหตุนี้ ผลกระทบของฟีเจอร์นี้จึงจำกัดอยู่เฉพาะแอปที่นักพัฒนาแอป
- ทราบถึงฟีเจอร์เจตนาที่ปลอดภัยยิ่งขึ้นและประโยชน์ของฟีเจอร์นี้
- เลือกที่จะนำแนวทางปฏิบัติในการจัดการ Intent ที่เข้มงวดมากขึ้นมาใช้ในแอปของตน
แนวทางการเลือกใช้นี้ช่วยลดความเสี่ยงที่จะทำให้แอปที่มีอยู่ซึ่งอาจต้องอาศัย ลักษณะการทำงานของการแก้ปัญหา Intent ที่มีความปลอดภัยน้อยในปัจจุบันใช้งานไม่ได้
แม้ว่าผลกระทบเริ่มต้นใน Android 16 อาจมีจำกัด แต่โครงการ Safer Intents มีแผนงานที่จะสร้างผลกระทบในวงกว้างขึ้นใน Android รุ่นต่อๆ ไป แผนของเราคือการทำให้การแก้เจตนาอย่างเข้มงวดเป็นลักษณะการทำงานเริ่มต้นในที่สุด
ฟีเจอร์เจตนาที่ปลอดภัยยิ่งขึ้นมีศักยภาพในการปรับปรุง ความปลอดภัยของระบบนิเวศ Android ได้อย่างมากด้วยการทำให้แอปที่เป็นอันตราย ใช้ประโยชน์จากช่องโหว่ในกลไกการแก้ปัญหาเจตนาได้ยากขึ้น
อย่างไรก็ตาม การเปลี่ยนไปใช้การเลือกไม่ใช้และการบังคับใช้ที่จำเป็นต้องได้รับการจัดการอย่างรอบคอบเพื่อแก้ไขปัญหาความเข้ากันได้ที่อาจเกิดขึ้นกับแอปที่มีอยู่
การใช้งาน
นักพัฒนาแอปต้องเปิดใช้การจับคู่ 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>
ข้อมูลเพิ่มเติมเกี่ยวกับฟีเจอร์ที่รองรับ
| ชื่อแฟล็ก | คำอธิบาย |
|---|---|
| enforceIntentFilter | บังคับใช้การจับคู่ที่เข้มงวดขึ้นสำหรับ Intent ขาเข้า |
| ไม่มี | ปิดใช้กฎการจับคู่พิเศษทั้งหมดสำหรับ Intent ขาเข้า เมื่อระบุหลายแฟล็ก ค่าที่ขัดแย้งกันจะได้รับการแก้ไขโดยให้ความสำคัญกับแฟล็ก "none" |
| allowNullAction | ผ่อนปรนกฎการจับคู่เพื่อให้ Intent ที่ไม่มีการดำเนินการจับคู่ได้ ใช้แฟล็กนี้ร่วมกับ "enforceIntentFilter" เพื่อให้ได้ลักษณะการทำงานที่เฉพาะเจาะจง |
การทดสอบและการแก้ไขข้อบกพร่อง
เมื่อการบังคับใช้มีผล แอปควรทํางานได้อย่างถูกต้องหากผู้เรียกใช้ 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 表面,在正式版 build 中,已弃用或仅用于 GPU 开发的 Mali GPU IOCTL 已被屏蔽。此外,用于 GPU 性能分析的 IOCTL 已限制为 shell 进程或可调试的应用。如需详细了解平台级政策,请参阅 SAC 更新。
此变化发生在使用 Mali GPU 的 Pixel 设备(Pixel 6-9)上。Arm 已在其 r54p2 版本的 Documentation/ioctl-categories.rst 中提供了 IOCTL 的官方分类。此列表将在未来的驱动程序版本中继续维护。
此项变更不会影响受支持的图形 API(包括 Vulkan 和 OpenGL),预计也不会影响开发者或现有应用。 Streamline Performance Analyzer 和 Android GPU 检查器等 GPU 性能剖析工具不会受到影响。
测试
如果您看到类似如下所示的 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,请提交 bug 并将其分配给 android-partner-security@google.com。
常见问题解答
此政策变更是否适用于所有原始设备制造商 (OEM)? 此变更将采用选择启用模式,但任何想要使用此强化方法的原始设备制造商 (OEM) 都可以使用。如需了解如何实现此变更,请参阅实现文档。
是否必须在 OEM 代码库中进行更改才能实现此功能,还是默认随新的 AOSP 版本提供? 平台级变更将默认随新的 AOSP 版本一起发布。如果供应商想要应用此变更,可以在其代码库中选择启用此变更。
SoC 是否负责使 IOCTL 列表保持最新状态?例如,如果我的设备使用 ARM Mali GPU,我是否需要就任何更改与 ARM 联系? 各个 SoC 必须在驱动程序发布后根据设备更新其 IOCTL 列表。 例如,ARM 会在驱动程序更新时更新其已发布的 IOCTL 列表。 不过,OEM 应确保在 SEPolicy 中纳入这些更新,并根据需要将任何选定的自定义 IOCTL 添加到列表中。
此变更是否会自动应用于所有在售 Pixel 设备,还是需要用户执行操作来切换某些设置才能应用此变更? 此变更适用于所有使用 Mali GPU 的 Pixel 在售设备(Pixel 6-9)。用户无需采取任何行动即可应用此变更。
使用此政策会影响内核驱动程序的性能吗? 我们使用 GFXBench 在 Mali GPU 上测试了此政策,未发现 GPU 性能有任何可衡量的变化。
IOCTL 列表是否需要与当前的用户空间和内核驱动程序版本保持一致? 是的,允许的 IOCTL 列表必须与用户空间和内核驱动程序支持的 IOCTL 同步。如果用户空间或内核驱动程序中的 IOCTL 发生更新,则必须更新 SEPolicy IOCTL 列表以保持一致。
ARM 已将 IOCTL 分类为“受限”/“检测”,但我们希望在生产用例中使用其中一些,并拒绝其他 IOCTL。 各个 OEM/SoC 负责根据其用户空间 Mali 库的配置来决定如何对其使用的 IOCTL 进行分类。ARM 的列表可用于帮助确定这些值,但每个 OEM/SoC 的使用情形可能有所不同。
ความเป็นส่วนตัว
Android 16 (API ระดับ 36) มีการเปลี่ยนแปลงด้านความเป็นส่วนตัวต่อไปนี้
สิทธิ์เข้าถึงเครือข่ายภายใน
แอปที่มีINTERNETจะเข้าถึงอุปกรณ์ใน LAN ได้
ซึ่งช่วยให้แอปเชื่อมต่อกับอุปกรณ์ในพื้นที่ได้ง่าย แต่ก็มีผลกระทบด้านความเป็นส่วนตัวด้วย เช่น การสร้างลายนิ้วมือของผู้ใช้ และการเป็นพร็อกซีสำหรับตำแหน่ง
โปรเจ็กต์การป้องกันเครือข่าย LAN มีเป้าหมายเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้โดย จำกัดการเข้าถึงเครือข่าย LAN ไว้เบื้องหลังสิทธิ์รันไทม์ใหม่
แผนการเปิดตัว
การเปลี่ยนแปลงนี้จะเปิดตัวระหว่าง 2 รุ่น ได้แก่ 25Q2 และ 26Q2 ตามลำดับ นักพัฒนาแอปต้องปฏิบัติตามคำแนะนำนี้สำหรับ 25Q2 และแชร์ความคิดเห็น เนื่องจากระบบจะบังคับใช้การป้องกันเหล่านี้ใน Android รุ่นต่อๆ ไป นอกจากนี้ นักพัฒนาแอปจะต้องอัปเดตสถานการณ์ที่ขึ้นอยู่กับการเข้าถึงเครือข่ายภายในโดยนัยโดยใช้คำแนะนำต่อไปนี้ และเตรียมพร้อมสำหรับการปฏิเสธของผู้ใช้ และการเพิกถอนสิทธิ์ใหม่
ผลกระทบ
ในระยะปัจจุบัน LNP เป็นฟีเจอร์ที่ต้องเลือกใช้ ซึ่งหมายความว่าจะมีผลกับแอปที่เลือกใช้เท่านั้น เป้าหมายของระยะการเลือกใช้คือการช่วยให้นักพัฒนาแอปเข้าใจว่าส่วนใดของแอปที่ต้องอาศัยการเข้าถึงเครือข่าย LAN โดยนัย เพื่อเตรียมพร้อมที่จะใช้การป้องกันสิทธิ์สำหรับแอปดังกล่าวในการเปิดตัวครั้งถัดไป
แอปจะได้รับผลกระทบหากเข้าถึงเครือข่ายท้องถิ่นของผู้ใช้โดยใช้สิ่งต่อไปนี้
- การใช้ซ็อกเก็ตดิบโดยตรงหรือผ่านไลบรารีในที่อยู่เครือข่ายภายใน (เช่น โปรโตคอลการค้นพบบริการ mDNS หรือ SSDP)
- การใช้คลาสระดับเฟรมเวิร์กที่เข้าถึงเครือข่ายในเครื่อง (เช่น NsdManager)
การรับส่งข้อมูลไปยังและจากที่อยู่เครือข่ายภายในต้องมีสิทธิ์เข้าถึงเครือข่ายภายใน ตารางต่อไปนี้แสดงกรณีที่พบบ่อย
| การดำเนินการเครือข่ายระดับต่ำของแอป | ต้องมีสิทธิ์เข้าถึงเครือข่ายภายใน |
|---|---|
| สร้างการเชื่อมต่อ TCP ขาออก | ใช่ |
| ยอมรับการเชื่อมต่อ TCP ขาเข้า | ใช่ |
| การส่ง Unicast, Multicast, Broadcast แบบ UDP | ใช่ |
| รับ Unicast, Multicast, Broadcast แบบ UDP ขาเข้า | ใช่ |
ข้อจำกัดเหล่านี้จะใช้ในส่วนลึกของสแต็กเครือข่าย จึงมีผลกับAPI เครือข่ายทั้งหมด ซึ่งรวมถึงซ็อกเก็ตที่สร้างขึ้นในโค้ดเนทีฟหรือโค้ดที่มีการจัดการ ไลบรารีเครือข่าย เช่น Cronet และ OkHttp รวมถึง API ใดๆ ที่ใช้เหนือไลบรารีเหล่านั้น การพยายามแก้ไขบริการใน เครือข่ายภายใน (เช่น บริการที่มีคำต่อท้าย .local) จะต้องมีสิทธิ์เข้าถึง เครือข่ายภายใน
ข้อยกเว้นสำหรับกฎข้างต้น
- หากเซิร์ฟเวอร์ DNS ของอุปกรณ์อยู่ในเครือข่ายภายใน การรับส่งข้อมูลไปยังหรือจากเซิร์ฟเวอร์ (ที่พอร์ต 53) ไม่จำเป็นต้องมีสิทธิ์เข้าถึงเครือข่ายภายใน
- แอปพลิเคชันที่ใช้ตัวสลับเอาต์พุตเป็นเครื่องมือเลือกในแอปจะไม่ต้องมีสิทธิ์เข้าถึงเครือข่ายในพื้นที่ (จะมีคำแนะนำเพิ่มเติมในไตรมาสที่ 4 ปี 2025)
คำแนะนำสำหรับนักพัฒนาแอป (เลือกใช้)
หากต้องการเลือกใช้ข้อจำกัดเครือข่ายในเครื่อง ให้ทำดังนี้
- แฟลชอุปกรณ์เป็นบิลด์ที่มี 25Q2 เบต้า 3 ขึ้นไป
- ติดตั้งแอปที่จะทดสอบ
สลับสถานะ Appcompat ใน adb โดยทำดังนี้
adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>รีบูตอุปกรณ์
ตอนนี้สิทธิ์เข้าถึงเครือข่ายภายในของแอปถูกจำกัดแล้ว และการพยายามเข้าถึงเครือข่ายภายในจะทำให้เกิดข้อผิดพลาดของซ็อกเก็ต หากคุณใช้ API ที่ ดำเนินการในเครือข่ายภายในนอกกระบวนการของแอป (เช่น NsdManager) API เหล่านี้จะไม่ได้รับผลกระทบในระหว่างระยะการเลือกใช้
หากต้องการคืนค่าสิทธิ์เข้าถึง คุณต้องให้สิทธิ์แอปในการเข้าถึง NEARBY_WIFI_DEVICES
- ตรวจสอบว่าแอปประกาศสิทธิ์
NEARBY_WIFI_DEVICESในไฟล์ Manifest - ไปที่การตั้งค่า > แอป > [ชื่อแอปพลิเคชัน] > สิทธิ์ > อุปกรณ์ที่อยู่ใกล้เคียง > อนุญาต
ตอนนี้สิทธิ์เข้าถึงเครือข่าย LAN ของแอปควรได้รับการกู้คืนแล้ว และสถานการณ์ทั้งหมดควรทํางานได้เหมือนก่อนที่จะเลือกใช้แอป
เมื่อการบังคับใช้เพื่อการปกป้องเครือข่าย LAN เริ่มขึ้น การเข้าชมเครือข่ายของแอป จะได้รับผลกระทบดังนี้
| สิทธิ์ | คำขอ LAN ขาออก | คำขออินเทอร์เน็ตขาออก/ขาเข้า | คำขอ LAN ขาเข้า |
|---|---|---|---|
| ให้สิทธิ์ | Works | Works | Works |
| ไม่ให้สิทธิ์ | เรื่องหน้าแตก | Works | เรื่องหน้าแตก |
ใช้คำสั่งต่อไปนี้เพื่อเปิด/ปิด Flag ความเข้ากันได้ของแอป
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 // ลิงก์ภายใน
- 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:
- ลิงก์เฉพาะ
- เส้นทางที่เชื่อมต่อโดยตรง
- เครือข่าย Stub เช่น Thread
- หลายซับเน็ต (จะแจ้งภายหลัง)
นอกจากนี้ ทั้งที่อยู่แบบมัลติแคสต์ (224.0.0.0/4, ff00::/8) และที่อยู่ IPv4 แบบบรอดแคสต์ (255.255.255.255) จะจัดเป็นที่อยู่เครือข่ายภายใน
รูปภาพที่เป็นของแอป
当面向 SDK 36 或更高版本的应用在搭载 Android 16 或更高版本的设备上提示用户授予照片和视频权限时,如果用户选择限制对所选媒体的访问权限,则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项,这会撤消该应用对这些照片和视频的访问权限。