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

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

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

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

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

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

Android 17 มีการจำกัดหน่วยความจำของแอปตาม RAM ทั้งหมดของอุปกรณ์ เพื่อสร้างสภาพแวดล้อมที่เสถียรและกำหนดได้มากขึ้นสำหรับแอปและ ผู้ใช้ Android ใน Android 17 มีการกำหนดขีดจำกัดอย่างรอบคอบเพื่อสร้างพื้นฐานของระบบ โดยมุ่งเป้าไปที่ปัญหาหน่วยความจำรั่วไหลที่รุนแรงและค่าผิดปกติอื่นๆ ก่อนที่จะทำให้ระบบไม่เสถียรในวงกว้าง ส่งผลให้ 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 (Process ID) ที่ระบุ ข้อจำกัดด้านหน่วยความจำจะระบุเป็นจำนวนเต็ม หน่วยเป็น MB เช่น การส่ง 30 จะระบุว่ากระบวนการนี้จำกัด หน่วยความจำไว้ที่ 30 MB การส่ง max จะนำข้อจำกัดด้านหน่วยความจำทั้งหมดในกระบวนการนั้นออก การส่ง none จะนำข้อจำกัดที่ตั้งค่าด้วยตนเองในกระบวนการออก และคืนค่า ขีดจำกัดเริ่มต้นของระบบ (หากมี)

status

รายงานสถานะปัจจุบันของตัวจำกัดหน่วยความจำ สถานะประกอบด้วย ขีดจำกัดหน่วยความจำที่กำหนดไว้สำหรับกระบวนการที่มองเห็นได้และมองไม่เห็น

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

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

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

Beginning with Android 17, Android is expanding its protection for SMS messages containing one-time passwords (OTP).

In previous versions of Android, this protection was primarily focused on the SMS Retriever format. Delivery of messages containing an SMS retriever hash was delayed for most apps for three hours. However, certain apps (like the default SMS handler) were exempt from the delay, and the app that owned the hash was also exempted.

Beginning with Android 17, the protection is also applied to WebOTP format messages. If an app has permission to read SMS messages but is not the intended recipient of a WebOTP message (as determined by domain verification), the message is not accessible to the app until three hours after the message's receipt. This change is intended to improve user security by ensuring that only apps associated with the domain mentioned in the message can programmatically read the verification code.

During this three hour delay, the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtered. The SMS message is available to these apps after the delay. This change applies to all apps, regardless of their target API level.

Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.

ความปลอดภัย

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 สำหรับ 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);

ขีดจำกัดของที่เก็บคีย์ต่อแอป

Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.

If an app attempts to create keys beyond the limit, the creation fails with a KeyStoreException. The exception's message string contains information about the key limit. If the app calls getNumericErrorCode() on the exception, the return value depends on what API level the app targets:

  • Apps targeting Android 17 (API level 37) or higher: getNumericErrorCode() returns the new ERROR_TOO_MANY_KEYS value.
  • All other apps: getNumericErrorCode() returns ERROR_INCORRECT_USAGE.

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

ตั้งแต่ 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 มีการเปลี่ยนแปลงลักษณะการทำงานของสื่อต่อไปนี้

การปิดช่องโหว่ของเสียงเบื้องหลัง

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

If the app tries to call audio APIs while the app is not in a valid lifecycle, the audio playback and volume change APIs fail silently without throwing an exception or providing a failure message. The audio focus API fails with the result code AUDIOFOCUS_REQUEST_FAILED.

For more information, including mitigation strategies, see Background audio hardening.

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

Android 17 มีการเปลี่ยนแปลงต่อไปนี้เพื่อเพิ่มประสิทธิภาพการเชื่อมต่ออุปกรณ์

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

Android 17 ขอแนะนำการจับคู่ใหม่ด้วยตัวเอง ซึ่งเป็นการปรับปรุงระดับระบบที่ออกแบบมาเพื่อแก้ไขการสูญเสียการเชื่อมต่อ Bluetooth โดยอัตโนมัติ

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

แม้ว่าแอปส่วนใหญ่จะไม่ต้องมีการเปลี่ยนแปลงโค้ด แต่นักพัฒนาแอปควรทราบถึงการเปลี่ยนแปลงลักษณะการทำงานต่อไปนี้ในสแต็ก Bluetooth

  • บริบทการจับคู่ใหม่: ตอนนี้ ACTION_PAIRING_REQUEST มีส่วนเพิ่มเติม EXTRA_PAIRING_CONTEXT ซึ่งช่วยให้แอปแยกแยะระหว่างคำขอการจับคู่มาตรฐานกับความพยายามในการจับคู่ใหม่ที่ระบบเริ่มต้นเองได้
  • การอัปเดตคีย์แบบมีเงื่อนไข: ระบบจะแทนที่คีย์ความปลอดภัยที่มีอยู่ก็ต่อเมื่อการจับคู่ใหม่สำเร็จและการเชื่อมต่อใหม่มีระดับความปลอดภัยเท่ากับหรือสูงกว่าการเชื่อมต่อก่อนหน้า
  • การกำหนดเวลา Intent ที่แก้ไข: ตอนนี้ระบบจะออกอากาศ Intent ACTION_KEY_MISSING ก็ต่อเมื่อความพยายามในการจับคู่ใหม่ด้วยตัวเองล้มเหลว ซึ่งจะช่วยลดการจัดการข้อผิดพลาดที่ไม่จำเป็นในแอปหากระบบกู้คืนการเชื่อมต่อในเบื้องหลังได้สำเร็จ
  • การแจ้งเตือนผู้ใช้: ระบบจะจัดการการจับคู่ใหม่ผ่านการแจ้งเตือนและกล่องโต้ตอบ UI ใหม่ ระบบจะแจ้งให้ผู้ใช้ยืนยันความพยายามในการจับคู่ใหม่เพื่อให้ผู้ใช้ทราบถึงการเชื่อมต่อใหม่

ผู้ผลิตอุปกรณ์ต่อพ่วงและนักพัฒนาแอปที่ใช้ร่วมกันควรตรวจสอบว่าฮาร์ดแวร์และแอปจัดการการเปลี่ยนการเชื่อมต่อได้อย่างราบรื่น หากต้องการทดสอบลักษณะการทำงานนี้ ให้จำลองการสูญเสียการเชื่อมต่อระยะไกลโดยใช้วิธีใดวิธีหนึ่งต่อไปนี้

  • นำข้อมูลการเชื่อมต่อออกจากอุปกรณ์ต่อพ่วงด้วยตนเอง
  • ยกเลิกการจับคู่อุปกรณ์ด้วยตนเองในส่วนการตั้งค่า > อุปกรณ์ที่เชื่อมต่อ