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

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

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

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

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

ตัวเลือกการไม่ใช้แบบเต็มหน้าจอจะหยุดให้บริการ

Android 15 enforced edge-to-edge for apps targeting Android 15 (API level 35), but your app could opt-out by setting R.attr#windowOptOutEdgeToEdgeEnforcement to true. For apps targeting Android 16 (API level 36), R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, and your app can't opt-out of going edge-to-edge.

• If your app targets Android 16 (API level 36) and is running on an Android 15 device, R.attr#windowOptOutEdgeToEdgeEnforcement continues to work.
• If your app targets Android 16 (API level 36) and is running on an Android 16 device, R.attr#windowOptOutEdgeToEdgeEnforcement is disabled.

For testing in Android 16 Beta 3, ensure your app supports edge-to-edge and remove any use of R.attr#windowOptOutEdgeToEdgeEnforcement so that your app also supports edge-to-edge on an Android 15 device. To support edge-to-edge, see the Compose and Views guidance.

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

สําหรับแอปที่กําหนดเป้าหมายเป็น 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 โดยค่าเริ่มต้น ซึ่งจะแทนที่แบบอักษรแบบกะทัดรัดด้วยแบบอักษรที่อ่านง่ายกว่ามาก คุณ override การตั้งค่านี้ได้โดยตั้งค่าแอตทริบิวต์ elegantTextHeight เป็น false

Android 16 เลิกใช้งานแอตทริบิวต์ elegantTextHeight และระบบจะไม่สนใจแอตทริบิวต์นี้เมื่อแอปกำหนดเป้าหมายเป็น Android 16 เราจะหยุดให้บริการ "แบบอักษร UI" ที่ควบคุมโดย 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 กำลังเปลี่ยนไปใช้รูปแบบที่คาดหวังให้แอปปรับเปลี่ยนให้เข้ากับการวางแนว ขนาดการแสดงผล และสัดส่วนภาพต่างๆ ข้อจำกัด เช่น การวางแนวแบบคงที่หรือความสามารถในการปรับขนาดที่จำกัด จะขัดขวางการปรับแอปให้เข้ากับอุปกรณ์ ดังนั้นเราขอแนะนำให้ทำให้แอปเป็นแบบปรับขนาดได้เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดีที่สุด

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

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

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

• เกม (ตาม Flag 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) มีการเปลี่ยนแปลงต่อไปนี้ในสแต็กบลูทูธเพื่อปรับปรุงการเชื่อมต่อกับอุปกรณ์ต่อพ่วง

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

As part of the Improved bond loss handling, Android 16 also introduces 2 new intents to provide apps with greater awareness of bond loss and encryption changes.

Apps targeting Android 16 can now:

• Receive an ACTION_KEY_MISSING intent when remote bond loss is detected, allowing them to provide more informative user feedback and take appropriate actions.
• Receive an ACTION_ENCRYPTION_CHANGE intent whenever encryption status of the link changes. This includes encryption status change, encryption algorithm change, and encryption key size change. Apps must consider the bond restored if the link is successfully encrypted upon receiving ACTION_ENCRYPTION_CHANGE intent later.

Adapting to varying OEM implementations

While Android 16 introduces these new intents, their implementation and broadcasting can vary across different device manufacturers (OEMs). To ensure your app provides a consistent and reliable experience across all devices, developers should design their bond loss handling to gracefully adapt to these potential variations.

We recommend the following app behaviors:

• If the ACTION_KEY_MISSING intent is broadcast:

  The ACL (Asynchronous Connection-Less) link will be disconnected by the system, but the bond information for the device will be retained (as described here).

  Your app should use this intent as the primary signal for bond loss detection and guiding the user to confirm the remote device is in range before initiating device forgetting or re-pairing.

  If a device disconnects after ACTION_KEY_MISSING is received, your app should be cautious about reconnecting, as the device may no longer be bonded with the system.

• If the ACTION_KEY_MISSING intent is NOT broadcast:

  The ACL link will remain connected, and the bond information for the device will be removed by the system, same to behavior in Android 15.

  In this scenario, your app should continue its existing bond loss handling mechanisms as in previous Android releases, to detect and manage bond loss events.

วิธีใหม่ในการยกเลิกการจับคู่บลูทูธ

ตอนนี้แอปทั้งหมดที่กำหนดเป้าหมายเป็น 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.

เพิ่มความปลอดภัยให้ Intent

ฟีเจอร์ Intent ที่ปลอดภัยเป็นโครงการริเริ่มด้านความปลอดภัยแบบหลายระยะที่ออกแบบมาเพื่อปรับปรุงความปลอดภัยของกลไกการแก้ไข 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 อาจจํากัด แต่โครงการ Intent ที่ปลอดภัยก็มีแผนงานที่จะให้ผลลัพธ์ที่กว้างขึ้นใน Android รุ่นต่อๆ ไป แผนของเราคือทำให้การแก้ไขความตั้งใจอย่างเข้มงวดเป็นลักษณะการทำงานเริ่มต้นในที่สุด

ฟีเจอร์ Intent ที่ปลอดภัยมีศักยภาพในการช่วยเพิ่มความปลอดภัยของระบบนิเวศ 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>

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

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

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

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

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

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

แผนรุ่น

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

ผลกระทบ

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

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

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

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

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

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

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

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

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

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

3. สลับ Flag 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. ไปที่การตั้งค่า > แอป > [ชื่อแอปพลิเคชัน] > สิทธิ์ > อุปกรณ์ใกล้เคียง > อนุญาต

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

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

ใช้คำสั่งต่อไปนี้เพื่อปิด Flag 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 // ลิงก์ภายใน
• 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:

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

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

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

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