Google ใช้เทคโนโลยี AI เพื่อแปลเนื้อหาเป็นภาษาที่คุณต้องการ การแปลโดย AI อาจมีข้อผิดพลาด

การเปลี่ยนแปลงลักษณะการทํางาน: แอปทั้งหมด

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

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

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

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

การจำกัดการใช้หน่วยความจำของแอป

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

คุณสามารถตรวจสอบว่าเซสชันของแอปได้รับผลกระทบหรือไม่โดยเรียกใช้ getDescription ใน ApplicationExitInfo หากแอปได้รับผลกระทบ เหตุผลในการออกจะเป็น REASON_OTHER และคำอธิบายจะมีสตริง "MemoryLimiter:AnonSwap" พร้อมกับข้อมูลอื่นๆ นอกจากนี้ คุณยังใช้การทำโปรไฟล์ตามทริกเกอร์กับ TRIGGER_TYPE_ANOMALY เพื่อรับฮีปดัมป์ที่รวบรวมไว้เมื่อถึงขีดจำกัดหน่วยความจำได้ด้วย

เอกสารประกอบจัดการหน่วยความจำของแอปให้ข้อมูลที่จะช่วยคุณวินิจฉัยปัญหาเกี่ยวกับหน่วยความจำของแอปและเพิ่มประสิทธิภาพการใช้ทรัพยากร

ทดสอบลักษณะการทำงานของแอปภายใต้ข้อจำกัดด้านหน่วยความจำ

คุณสามารถใช้ Android Debug Bridge (adb) เพื่อปรับหรือปิดใช้ขีดจำกัดหน่วยความจำในอุปกรณ์ที่กำหนดขีดจำกัดดังกล่าวได้ คำสั่ง Shell am มีคำสั่งย่อย 3 รายการเพื่อปรับขีดจำกัดหน่วยความจำ (คำสั่งเหล่านี้ไม่มีผลกับอุปกรณ์ที่ไม่ได้กำหนดขีดจำกัดหน่วยความจำ)

am memory-limiter ignore <uid>|none|all
am memory-limiter manual <pid> <limit>|max|none
am memory-limiter status

ignore: สั่งให้ตัวจำกัดหน่วยความจำละเว้นบางกระบวนการหรือทั้งหมด การส่ง UID (รหัสผู้ใช้ Android) จะสั่งให้ตัวจำกัดหน่วยความจำละเว้นการบังคับใช้กับกระบวนการทั้งหมดที่เชื่อมโยงกับ UID นั้น นอกจากนี้ คุณยังส่ง all (ละเว้นแอปทั้งหมด) หรือ none (ไม่ละเว้นแอปใดๆ) ได้ด้วย การส่ง none จะลบล้างการเรียกใช้ am memory-limiter ignore ก่อนหน้านี้; หากคุณสั่งให้ตัวจำกัดหน่วยความจำละเว้น UID คุณจะยังคงใช้ขีดจำกัดหน่วยความจำด้วยตนเองกับกระบวนการภายในแอปได้โดยเรียกใช้ am memory-limiter manual
manual: สั่งให้ระบบกำหนดข้อจำกัดหน่วยความจำในกระบวนการด้วย PID (รหัสกระบวนการ) ที่ระบุ ข้อจำกัดของหน่วยความจำจะระบุเป็นจำนวนเต็มของ MB เช่น การส่ง 30 จะระบุว่ากระบวนการถูกจำกัดไว้ที่หน่วยความจำ 30 MB การส่ง max จะนำขีดจำกัดหน่วยความจำทั้งหมดในกระบวนการนั้นออก การส่ง none จะนำขีดจำกัดที่ตั้งค่าด้วยตนเองในกระบวนการออก และคืนค่าขีดจำกัดเริ่มต้นของระบบ (หากมี)
status: รายงานสถานะปัจจุบันของตัวจำกัดหน่วยความจำ สถานะจะรวมขีดจำกัดหน่วยความจำที่กำหนดไว้ในกระบวนการที่มองเห็นได้และมองไม่เห็น

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

Android 17 มีการเปลี่ยนแปลงต่อไปนี้เพื่อปรับปรุงความเป็นส่วนตัวของผู้ใช้

การป้องกัน OTP ทาง SMS

ตั้งแต่ Android 17 เป็นต้นไป Android จะขยายการปกป้องข้อความ SMS ที่มีรหัสผ่านแบบใช้ครั้งเดียว (OTP)

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

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

ในระหว่างการหน่วงเวลา 3 ชั่วโมงนี้ ระบบจะระงับการออกอากาศ SMS_RECEIVED_ACTION และกรองการค้นหาฐานข้อมูลผู้ให้บริการ SMS แอปเหล่านี้จะได้รับข้อความ SMS หลังจากเกิดความล่าช้า การเปลี่ยนแปลงนี้จะมีผลกับแอปทั้งหมด ไม่ว่าจะมีระดับ API เป้าหมายใดก็ตาม

แอปบางแอป เช่น แอปผู้ช่วย SMS เริ่มต้น แอปที่ใช้ร่วมกันของอุปกรณ์ที่เชื่อมต่อ ฯลฯ จะได้รับการยกเว้นจากความล่าช้านี้ แอปทั้งหมดที่อาศัยการอ่านข้อความ SMS เพื่อดึงข้อมูล OTP ควรเปลี่ยนไปใช้ API SMS Retriever หรือ SMS User Consent เพื่อให้ฟังก์ชันการทำงานยังคงใช้งานได้ต่อไป

ความปลอดภัย

Android 17 มีการปรับปรุงความปลอดภัยของอุปกรณ์และแอปดังต่อไปนี้

แผนการเลิกใช้งาน usesClearTraffic

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

โปรดทราบว่าไฟล์การกำหนดค่าการรักษาความปลอดภัยของเครือข่ายใช้ได้ใน API ระดับ 24 ขึ้นไปเท่านั้น หากแอปมีระดับ API ขั้นต่ำต่ำกว่า 24 คุณควรทำทั้ง 2 อย่างต่อไปนี้

ตั้งค่าแอตทริบิวต์ usesCleartextTraffic เป็น true
ใช้ไฟล์การกำหนดค่าเครือข่าย

หากระดับ API ขั้นต่ำของแอปคือ 24 ขึ้นไป คุณสามารถใช้ไฟล์การกำหนดค่าเครือข่ายและไม่จำเป็นต้องตั้งค่า usesCleartextTraffic

จำกัดการให้สิทธิ์ URI โดยนัย

ปัจจุบัน หากแอปเปิด Intent ด้วย URI ที่มีการดำเนินการ ACTION_SEND, ACTION_SEND_MULTIPLE หรือ ACTION_IMAGE_CAPTURE ระบบจะให้สิทธิ์ URI อ่านและเขียนแก่แอปเป้าหมายโดยอัตโนมัติ ตั้งแต่ Android 18 เป็นต้นไป ระบบจะไม่ให้สิทธิ์เหล่านี้โดยอัตโนมัติอีกต่อไป ด้วยเหตุนี้ เราขอแนะนำให้แอปให้สิทธิ์ URI ที่เกี่ยวข้องอย่างชัดเจนแทนที่จะพึ่งพาระบบในการให้สิทธิ์

หากต้องการตรวจหาการใช้งาน Intent เหล่านี้ในแอป ให้ใช้ StrictMode กับ detectImplicitUriPermissionGrant() เพื่อทริกเกอร์การละเมิด

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

หรือจะตรวจสอบข้อยกเว้นที่บันทึกไว้ซึ่งมีข้อความ Please set the grant explicitly in the app ที่ปรากฏขึ้นเมื่อระบบตั้งค่าการให้สิทธิ์โดยนัยก็ได้ คุณตรวจสอบบันทึกเหล่านี้ได้โดยใช้คำสั่ง adb ต่อไปนี้

adb logcat | grep "Please set the grant explicitly in the app"

หากต้องการให้สิทธิ์ที่จำเป็นอย่างชัดแจ้ง ให้เพิ่มแฟล็ก FLAG_GRANT_READ_URI_PERMISSION ลงใน Intent ACTION_SEND และ ACTION_SEND_MULTIPLE ดังนี้

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

รวมทั้งแฟล็ก FLAG_GRANT_READ_URI_PERMISSION และ FLAG_GRANT_WRITE_URI_PERMISSION สำหรับ Intent ACTION_IMAGE_CAPTURE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

ขีดจำกัด Keystore ต่อแอป

应用应避免在 Android 密钥库中创建过多密钥，因为密钥库是设备上所有应用的共享资源。从 Android 17 开始，系统会强制限制应用可以拥有的密钥数量。对于以 Android 17（API 级别 37）或更高版本为目标平台的非系统应用，此限制为 50,000 个键；对于所有其他应用，此限制为 200,000 个键。系统应用的密钥数量上限为 20 万，无论其目标 API 级别为何。

如果应用尝试创建超出限制的密钥，则创建会失败，并显示 KeyStoreException。异常的消息字符串包含有关键限制的信息。如果应用对异常调用 getNumericErrorCode()，则返回值取决于应用的目标 API 级别：

以 Android 17（API 级别 37）或更高版本为目标平台的应用：getNumericErrorCode() 会返回新的 ERROR_TOO_MANY_KEYS 值。
所有其他应用：getNumericErrorCode() 会返回 ERROR_INCORRECT_USAGE。

บล็อกการเข้าชมแบบ Loopback ข้ามโปรไฟล์

ตั้งแต่ Android 17 เป็นต้นไป ระบบจะไม่อนุญาตการรับส่งข้อมูลแบบ Loopback ข้ามโปรไฟล์โดยค่าเริ่มต้นอีกต่อไป การเข้าชมแบบ Loopback ภายในโปรไฟล์เดียวกันจะไม่ได้รับผลกระทบ การเปลี่ยนแปลงนี้มีผลกับแอปทั้งหมดที่ทำงานบน Android 17 ขึ้นไป ไม่ว่าแอปจะกำหนดเป้าหมายเป็นระดับ API ใดก็ตาม

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

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

การคืนค่าระดับการเข้าถึง IME เริ่มต้นหลังจากการหมุน

ตั้งแต่ Android 17 เป็นต้นไป เมื่อการกำหนดค่าของอุปกรณ์เปลี่ยนแปลง (เช่น ผ่านการหมุน) และแอปไม่ได้จัดการการเปลี่ยนแปลงนี้เอง ระบบจะไม่กู้คืนระดับการเข้าถึง IME ก่อนหน้า

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

ตั้งค่าแอตทริบิวต์ android:windowSoftInputMode เป็น stateAlwaysVisible
ขอแป้นพิมพ์เสมือนแบบเป็นโปรแกรมในเมธอด onCreate() ของกิจกรรม หรือเพิ่มเมธอด onConfigurationChanged()

อินพุตจากมนุษย์

Android 17 มีการเปลี่ยนแปลงต่อไปนี้ซึ่งส่งผลต่อวิธีที่แอปโต้ตอบกับอุปกรณ์อินพุตของมนุษย์ เช่น แป้นพิมพ์และทัชแพด

ทัชแพดจะแสดงเหตุการณ์ที่เกี่ยวข้องโดยค่าเริ่มต้นระหว่างการจับภาพเคอร์เซอร์

ตั้งแต่ Android 17 เป็นต้นไป หากแอปขอการจับตัวชี้โดยใช้ View.requestPointerCapture() และผู้ใช้ใช้ทัชแพด ระบบจะจดจำการเคลื่อนไหวของตัวชี้และท่าทางการเลื่อนจากการสัมผัสของผู้ใช้ และรายงานไปยังแอปในลักษณะเดียวกับการเคลื่อนไหวของตัวชี้และปุ่มลูกกลิ้งจากเมาส์ที่จับได้ ในกรณีส่วนใหญ่ วิธีนี้จะช่วยให้แอปที่รองรับเมาส์ที่ถูกจับไม่ต้องเพิ่มตรรกะการจัดการพิเศษสำหรับทัชแพด ดูรายละเอียดเพิ่มเติมได้ในเอกสารประกอบของ View.POINTER_CAPTURE_MODE_RELATIVE

ก่อนหน้านี้ ระบบไม่ได้พยายามจดจำท่าทางสัมผัสจากทัชแพด แต่จะส่งตำแหน่งนิ้วแบบสัมบูรณ์ดิบไปยังแอปในรูปแบบที่คล้ายกับการสัมผัสหน้าจอสัมผัสแทน หากแอปยังคงต้องการข้อมูลสัมบูรณ์นี้ แอปควรเรียกใช้เมธอด View.requestPointerCapture(int) ใหม่ด้วย View.POINTER_CAPTURE_MODE_ABSOLUTE แทน

สื่อ

Android 17 มีการเปลี่ยนแปลงต่อไปนี้เกี่ยวกับลักษณะการทำงานของสื่อ

การเพิ่มความปลอดภัยของเสียงในเบื้องหลัง

从 Android 17 开始，音频框架会对后台音频互动（包括音频播放、音频焦点请求和音量更改 API）施加限制，以确保这些更改是由用户有意发起的。

如果应用在不处于有效生命周期时尝试调用音频 API，音频播放和音量更改 API 会静默失败，而不会抛出异常或提供失败消息。音频焦点 API 失败，结果代码为 AUDIOFOCUS_REQUEST_FAILED。

如需了解详情（包括缓解措施），请参阅后台音频安全加固。

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

Android 17 มีการเปลี่ยนแปลงต่อไปนี้เพื่อปรับปรุงการเชื่อมต่อของอุปกรณ์

การเริ่มจับคู่อีกครั้งโดยอัตโนมัติเมื่อการเชื่อมต่อบลูทูธขาดหาย

Android 17 引入了自主重新配对功能，这是一项系统级增强功能，旨在自动解决蓝牙绑定丢失问题。

以前，如果连接丢失，用户必须手动前往“设置”取消配对外围设备，然后重新配对。此功能以 Android 16 的安全改进为基础，使系统能够在获得用户同意后重新建立绑定。这样一来，用户就无需手动前往“设置”来取消配对和重新配对外围设备。

虽然大多数应用不需要更改代码，但开发者应注意蓝牙堆栈中的以下行为变更：

新的配对上下文：ACTION_PAIRING_REQUEST 现在包含 EXTRA_PAIRING_CONTEXT extra，使应用能够区分标准配对请求和系统发起的自主重新配对尝试。
有条件的密钥更新：只有在重新配对成功且新连接的安全级别达到或超过之前绑定的安全级别时，系统才会替换现有安全密钥。
修改了 intent 时间：现在，仅当自主重新配对尝试失败时，系统才会广播 ACTION_KEY_MISSING intent。如果系统在后台成功恢复绑定，这会减少应用中不必要的错误处理。
用户通知：系统通过新的界面通知和对话框管理重新配对。系统会提示用户确认重新配对尝试，以确保他们知道重新连接。

外围设备制造商和配套应用开发者应验证硬件和应用是否能妥善处理绑定转换。如需测试此行为，请使用以下任一方法模拟远程绑定丢失：

手动从外围设备中移除绑定信息
在“设置”>“已连接的设备”中手动取消配对设备