การเปลี่ยนแปลงลักษณะการทำงาน: แอปที่กำหนดเป้าหมายเป็น 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 或更高版本的设备上运行的应用，系统会默认启用预测性返回系统动画（返回主屏幕、跨任务和跨 activity）。此外，系统不会调用 onBackPressed，也不会再分派 KeyEvent.KEYCODE_BACK。

如果您的应用会拦截返回事件，而您尚未迁移到预测性返回，请更新应用以使用受支持的返回导航 API，或在应用的 AndroidManifest.xml 文件的 <application> 或 <activity> 标记中将 android:enableOnBackInvokedCallback 属性设置为 false，以暂时停用预测性返回。

预测性返回主屏幕动画。

预测性跨 activity 动画。

预测性跨任务动画。

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

以 Android 15（API 级别 35）为目标平台的应用默认将 elegantTextHeight TextView 属性设置为 true，从而将紧凑型字体替换为可读性更高的字体。您可以通过将 elegantTextHeight 属性设置为 false 来替换此设置。

Android 16 弃用了 elegantTextHeight 属性，当您的应用以 Android 16 为目标平台后，系统会忽略该属性。由这些 API 控制的“界面字体”即将停用，因此您应调整所有布局，以确保阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语文本的呈现效果一致且不受未来变化的影响。

针对以 Android 14（API 级别 34）及更低版本为目标平台的应用，或针对以 Android 15（API 级别 35）为目标平台且通过将 elegantTextHeight 属性设置为 false 替换默认值的应用，

elegantTextHeight 行为。

以 Android 16（API 级别 36）为目标平台的应用，或以 Android 15（API 级别 35）为目标平台但未通过将 elegantTextHeight 属性设置为 false 来替换默认值的应用，其

elegantTextHeight 行为。

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

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>

สำคัญ: การเลือกไม่ใช้นี้เป็นแบบชั่วคราวและจะไม่มีผลเมื่อกำหนดเป้าหมายเป็น API ระดับ 37 ใน Android รุ่นต่อๆ ไป กล่าวคือ สำหรับแอปที่กำหนดเป้าหมายเป็น API ระดับ 37 ระบบจะไม่สนใจข้อจำกัดด้านการวางแนว ความสามารถในการปรับขนาด และสัดส่วนการแสดงผลบนจอแสดงผลที่มีขนาดอย่างน้อย sw600dp

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

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 还引入了 2 个新 intent，以便应用更好地了解键值对丢失和加密更改。

以 Android 16 为目标平台的应用现在可以：

• 在检测到远程键盘连接丢失时接收 ACTION_KEY_MISSING intent，以便提供更具信息量的用户反馈并采取适当的措施。
• 每当链接的加密状态发生变化时，都会收到 ACTION_ENCRYPTION_CHANGE intent。这包括加密状态更改、加密算法更改和加密密钥大小更改。如果应用在稍后收到 ACTION_ENCRYPTION_CHANGE intent 时成功加密了链接，则必须将该绑定视为已恢复。

适应不同的 OEM 实现

虽然 Android 16 引入了这些新 intent，但其实现和广播可能会因不同的设备制造商 (OEM) 而异。为了确保您的应用在所有设备上都能提供一致且可靠的体验，开发者应设计其绑定丢失处理机制，以妥善适应这些潜在的变化。

我们建议您采用以下应用行为：

• 如果广播 ACTION_KEY_MISSING intent：

  系统会断开 ACL（异步无连接）链接，但会保留设备的配对信息（如此处所述）。

  您的应用应将此 intent 用作检测配对丢失的主要信号，并在发起设备忘记或重新配对之前引导用户确认远程设备是否在范围内。

  如果设备在收到 ACTION_KEY_MISSING 后断开连接，您的应用应谨慎重新连接，因为设备可能已不再与系统绑定。

• 如果未广播 ACTION_KEY_MISSING intent：

  ACL 链接将保持连接状态，系统会移除设备的配对信息，与 Android 15 中的行为相同。

  在这种情况下，您的应用应继续使用与之前的 Android 版本相同的现有配对丢失处理机制，以检测和管理配对丢失事件。

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

现在，以 Android 16 为目标平台的所有应用都可以使用 CompanionDeviceManager 中的公共 API 解除蓝牙设备配对。如果配套设备作为 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>

หมายเหตุ: คุณสามารถระบุแอตทริบิวต์ในแท็ก <application> และในแท็กคอมโพเนนต์ เช่น <activity>, <activity-alias>, <receiver>, <service>, <provider> และแอตทริบิวต์ในคอมโพเนนต์เพื่อลบล้างสิ่งที่อยู่ในแท็ก <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 เราจึงบล็อก 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 ที่ถูกบล็อก โปรดรายงานข้อบกพร่องและมอบหมายให้ [e-mail]

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

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)

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

การดำเนินการเครือข่ายระดับต่ำของแอป	ต้องมีสิทธิ์เข้าถึงเครือข่ายภายใน
การเชื่อมต่อ TCP ขาออก	ใช่
ยอมรับการเชื่อมต่อ TCP ขาเข้า	ใช่
การส่ง UDP แบบ Unicast, Multicast, Broadcast	ใช่
การรับ UDP แบบ Unicast, Multicast, Broadcast ขาเข้า	ใช่

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

หมายเหตุ: การเข้าชมที่มาจาก Android WebView ซึ่งต้องใช้การเข้าถึงเครือข่ายในเครื่องจะรับสถานะสิทธิ์มาจากแอปโฮสต์

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

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

หมายเหตุ: สถานการณ์การแคสต์สื่อหลายสถานการณ์ขึ้นอยู่กับการเข้าถึงเครือข่าย LAN และจะได้รับผลกระทบจากการเปลี่ยนแปลงนี้ อย่างไรก็ตาม ไม่ใช่ทุกแอปที่เสนอการแคสต์จะต้องขอสิทธิ์ใหม่ เราจะจัดเตรียม API และคำแนะนำในอนาคตสำหรับการจัดการสถานการณ์การแคสต์ในไตรมาสที่ 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. ไปที่การตั้งค่า > แอป > [ชื่อแอปพลิเคชัน] > สิทธิ์ > อุปกรณ์ที่อยู่ใกล้เคียง > อนุญาต

หมายเหตุ: ใน Android รุ่นต่อๆ ไป ฟีเจอร์นี้จะได้รับการปกป้องโดยสิทธิ์ใหม่ในกลุ่มสิทธิ์เข้าถึงอุปกรณ์ที่อยู่ใกล้เคียง

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

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

สิทธิ์	คำขอ LAN ขาออก	คำขออินเทอร์เน็ตขาออก/ขาเข้า	คำขอ LAN ขาเข้า
ให้สิทธิ์	Works	Works	Works
ไม่ได้รับสิทธิ์	เรื่องหน้าแตก	Works	เรื่องหน้าแตก

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