การเปลี่ยนแปลงลักษณะการทำงาน: แอปที่กำหนดเป้าหมายเป็น 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

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

For apps targeting Android 16 (API level 36) or higher and running on an Android 16 or higher device, the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore.

If your app intercepts the back event and you haven't migrated to predictive back yet, update your app to use supported back navigation APIs, or temporarily opt out by setting the android:enableOnBackInvokedCallback attribute to false in the <application> or <activity> tag of your app's AndroidManifest.xml file.

เลิกใช้งานและปิดใช้ 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

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

Prior to targeting Android 16, when scheduleAtFixedRate missed a task execution due to being outside a valid process lifecycle, all missed executions immediately execute when the app returns to a valid lifecycle.

When targeting Android 16, at most one missed execution of scheduleAtFixedRate is immediately executed when the app returns to a valid lifecycle. This behavior change is expected to improve app performance. Test this behavior in your app to check if your app is impacted. You can also test by using the app compatibility framework and enabling the STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS compat flag.

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

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

เลย์เอาต์ที่ปรับเปลี่ยนตามพื้นที่

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

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

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

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

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

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

การไม่สนใจข้อจำกัดด้านการวางแนว ความสามารถในการปรับขนาด และสัดส่วนภาพอาจส่งผลต่อ 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

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

หากต้องการเลือกไม่ใช้กิจกรรมที่เฉพาะเจาะจง ให้ประกาศ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) มีการเปลี่ยนแปลงต่อไปนี้ที่เกี่ยวข้องกับข้อมูลสุขภาพ และการออกกำลังกาย

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

For apps targeting Android 16 (API level 36) or higher, BODY_SENSORS permissions use more granular permissions under android.permissions.health, which Health Connect also uses. As of Android 16, any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND requires the corresponding android.permissions.health permission instead. This affects the following data types, APIs, and foreground service types:

• HEART_RATE_BPM from Health Services on Wear OS
• Sensor.TYPE_HEART_RATE from Android Sensor Manager
• heartRateAccuracy and heartRateBpm from ProtoLayout on Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH where the respective android.permission.health permission is needed in place of BODY_SENSORS

If your app uses these APIs, it should request the respective granular permissions:

• For while-in-use monitoring of Heart Rate, SpO2, or Skin Temperature: request the granular permission under android.permissions.health, such as READ_HEART_RATE instead of BODY_SENSORS.
• For background sensor access: request READ_HEALTH_DATA_IN_BACKGROUND instead of BODY_SENSORS_BACKGROUND.

These permissions are the same as those that guard access to reading data from Health Connect, the Android datastore for health, fitness, and wellness data.

Mobile apps

Mobile apps migrating to use the READ_HEART_RATE and other granular permissions must also declare an activity to display the app's privacy policy. This is the same requirement as Health Connect.

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

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

เจตนาใหม่ในการจัดการการสูญเสียพันธะและการเปลี่ยนแปลงการเข้ารหัส

การจัดการการสูญเสียการเชื่อมโยงที่ดีขึ้นทำให้ 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

For apps targeting Android 16 or higher, MediaStore#getVersion() will now be unique to each app. This eliminates identifying properties from the version string to prevent abuse and usage for fingerprinting techniques. Apps shouldn't make any assumptions around the format of this version. Apps should already handle version changes when using this API and in most cases shouldn't need to change their current behavior, unless the developer has attempted to infer additional information that is beyond the intended scope of this API.

ความตั้งใจที่ปลอดภัยยิ่งขึ้น

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

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

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

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

2. 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>

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

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

เมื่อการบังคับใช้มีผล แอปควรทํางานได้อย่างถูกต้องหากผู้เรียก 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:")

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

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

สิทธิ์เข้าถึงเครือข่ายภายใน

Devices on the LAN can be accessed by any app that has the INTERNET permission. This makes it easy for apps to connect to local devices but it also has privacy implications such as forming a fingerprint of the user, and being a proxy for location.

The Local Network Protections project aims to protect the user's privacy by gating access to the local network behind a new runtime permission.

Release plan

This change will be deployed between two releases, 25Q2 and TBD respectively. It is imperative that developers follow this guidance for 25Q2 and share feedback because these protections will be enforced at a later Android release. Moreover, they will need to update scenarios which depend on implicit local network access by using the following guidance and prepare for user rejection and revocation of the new permission.

Impact

At the current stage, LNP is an opt-in feature which means only the apps that opt in will be affected. The goal of the opt-in phase is for app developers to understand which parts of their app depend on implicit local network access such that they can prepare to permission guard them for the next release.

Apps will be affected if they access the user's local network using:

• Direct or library use of raw sockets on local network addresses (e.g. mDNS or SSDP service discovery protocol)
• Use of framework level classes that access the local network (e.g. NsdManager)

Traffic to and from a local network address requires local network access permission. The following table lists some common cases:

These restrictions are implemented deep in the networking stack, and thus they apply to all networking APIs. This includes sockets created in native or managed code, networking libraries like Cronet and OkHttp, and any APIs implemented on top of those. Trying to resolve services on the local network (i.e. those with a .local suffix) will require local network permission.

Exceptions to the rules above:

• If a device's DNS server is on a local network, traffic to or from it (at port 53) doesn't require local network access permission.
• Applications using Output Switcher as their in-app picker won't need local network permissions (more guidance to come in 2025Q4).

Developer Guidance (Opt-in)

To opt into local network restrictions, do the following:

1. Flash the device to a build with 25Q2 Beta 3 or later.
2. Install the app to be tested.

3. Toggle the Appcompat flag in adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reboot The device

Now your app's access to the local network is restricted and any attempt to access the local network will lead to socket errors. If you are using APIs that perform local network operations outside of your app process (ex: NsdManager), they won't be impacted during the opt-in phase.

To restore access, you must grant your app permission to NEARBY_WIFI_DEVICES.

1. Ensure the app declares the NEARBY_WIFI_DEVICES permission in its manifest.
2. Go to Settings > Apps > [Application Name] > Permissions > Nearby devices > Allow.

Now your app's access to the local network should be restored and all your scenarios should work as they did prior to opting the app in.

Once enforcement for local network protection begins, here is how the app network traffic will be impacted.

Use the following command to toggle-off the App-Compat flag

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errors

Errors arising from these restrictions will be returned to the calling socket whenever it invokes send or a send variant to a local network address.

Example errors:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Local Network Definition

A local network in this project refers to an IP network that utilizes a broadcast-capable network interface, such as Wi-Fi or Ethernet, but excludes cellular (WWAN) or VPN connections.

The following are considered local networks:

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
• Directly-connected routes
• Stub networks like Thread
• Multiple-subnets (TBD)

Additionally, both multicast addresses (224.0.0.0/4, ff00::/8) and the IPv4 broadcast address (255.255.255.255) are classified as local network addresses.

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

When prompted for photo and video permissions by an app targeting SDK 36 or higher on devices running Android 16 or higher, users who choose to limit access to selected media will see any photos owned by the app pre-selected in the photo picker. Users can deselect any of these pre-selected items, which will revoke the app's access to those photos and videos.