แพลตฟอร์ม 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เพื่อรับ Heap Dump ที่รวบรวมไว้เมื่อถึง
ขีดจำกัดหน่วยความจำได้ด้วย
เอกสารประกอบเรื่องการจัดการหน่วยความจำของแอปมีข้อมูล ที่จะช่วยคุณวินิจฉัยปัญหาหน่วยความจำของแอปและเพิ่มประสิทธิภาพการใช้ทรัพยากร
ทดสอบลักษณะการทำงานของแอปภายใต้ข้อจำกัดด้านหน่วยความจำ
คุณสามารถใช้ Android Debug Bridge (adb) เพื่อปรับหรือปิดใช้
ขีดจำกัดหน่วยความจำในอุปกรณ์ที่กำหนดขีดจำกัดดังกล่าว คำสั่ง Shell am มีคำสั่งย่อย 3 รายการสำหรับปรับขีดจำกัดหน่วยความจำ (คำสั่งเหล่านี้ไม่มีผลกับอุปกรณ์ที่ไม่ได้กำหนดขีดจำกัดหน่วยความจำ)
am memory-limiter ignore <uid>|none|allam memory-limiter manual <pid> <limit>|max|noneam memory-limiter status
ignoreสั่งให้ตัวจำกัดหน่วยความจำละเว้นกระบวนการบางอย่างหรือทั้งหมด การส่ง UID (รหัสผู้ใช้ Android) จะสั่งให้ตัวจำกัดหน่วยความจำ ละเว้นการบังคับใช้กับกระบวนการทั้งหมดที่เชื่อมโยงกับ UID นั้น นอกจากนี้ คุณยังส่ง
all(ละเว้นแอปทั้งหมด) หรือnone(ไม่ละเว้นแอปใดๆ) ได้ด้วย การส่งnoneจะลบล้างการเรียกใช้am memory-limiter ignoreก่อนหน้านี้หากสั่งให้ตัวจำกัดหน่วยความจำละเว้น UID คุณจะยังคงใช้ขีดจำกัดหน่วยความจำด้วยตนเองกับกระบวนการภายในแอปได้โดยเรียกใช้
am memory-limiter manualmanualสั่งให้ระบบกำหนดข้อจำกัดด้านหน่วยความจำกับกระบวนการที่มี PID (รหัสกระบวนการ) ที่ระบุ ข้อจำกัดด้านหน่วยความจำจะระบุเป็นจำนวนเต็มของ MB เช่น การส่ง
30จะระบุว่ากระบวนการถูกจำกัดหน่วยความจำไว้ที่ 30 MB การส่งmaxจะนำขีดจำกัดหน่วยความจำทั้งหมดในกระบวนการนั้นออก การส่งnoneจะนำขีดจำกัดที่ตั้งค่าด้วยตนเองในกระบวนการออก ซึ่งจะคืนค่าขีดจำกัดเริ่มต้นของระบบ (หากมี)statusรายงานสถานะปัจจุบันของตัวจำกัดหน่วยความจำ สถานะนี้รวมถึงขีดจำกัดหน่วยความจำที่กำหนดไว้ในกระบวนการที่มองเห็นและมองไม่เห็น
ความเป็นส่วนตัว
Android 17 มีการเปลี่ยนแปลงต่อไปนี้เพื่อปรับปรุงความเป็นส่วนตัวของผู้ใช้
การป้องกัน OTP ทาง SMS
从 Android 17 开始,Android 将扩大对包含一次性密码 (OTP) 的短信的保护范围。
在之前的 Android 版本中,此保护主要侧重于 SMS Retriever 格式。对于大多数应用,包含 SMS Retriever 哈希的消息的递送延迟了 3 小时。不过,某些应用(例如默认短信处理程序)不受此延迟的影响,拥有哈希的应用也不受此延迟的影响。
从 Android 17 开始,此保护也适用于 WebOTP 格式的消息。如果应用有权读取短信,但不是 WebOTP 消息的预期接收者(由网域验证确定),则该应用在收到消息后 3 小时内无法访问该消息。此变更旨在提高用户安全性,确保只有与消息中提及的网域关联的应用才能以编程方式读取验证码。
在这 3 小时的延迟期间,系统会保留 SMS_RECEIVED_ACTION 广播,并过滤 短信提供商 数据库查询。延迟结束后,这些应用即可使用短信。此变更适用于
所有应用,无论其目标 API 级别如何。
某些应用(例如默认短信助理应用、关联设备配套应用等)不受此延迟的影响。所有依赖于读取短信 来提取 OTP 的应用都应过渡到使用 SMS Retriever 或 SMS User Consent API,以确保功能持续可用。
ความปลอดภัย
Android 17 มีการปรับปรุงความปลอดภัยของอุปกรณ์และแอป ดังต่อไปนี้
แผนการเลิกใช้งาน usesClearTraffic
我们计划在未来的版本中弃用 usesCleartextTraffic 元素。需要建立未加密 (HTTP) 连接的应用应迁移为使用网络安全配置文件,该文件可让您指定应用需要与哪些网域建立明文连接。
请注意,网络安全配置文件仅在 API 级别 24 及更高版本中受支持。如果您的应用的最低 API 级别低于 24,您应执行以下两项操作:
- 将
usesCleartextTraffic属性设置为true - 使用网络配置文件
如果应用的最低 API 级别为 24 或更高,您可以使用网络配置文件,而无需设置 usesCleartextTraffic。
จำกัดการให้สิทธิ์ URI โดยนัย
目前,如果应用启动的 intent 具有 URI,且该 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标志添加到ACTION_SEND和
ACTION_SEND_MULTIPLEintent:
Kotlin
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)
Java
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
对于
ACTION_IMAGE_CAPTURE intent,请同时添加FLAG_GRANT_READ_URI_PERMISSION 和
FLAG_GRANT_WRITE_URI_PERMISSION 标志:
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);
ขีดจำกัดของที่เก็บคีย์ต่อแอป
แอปควรหลีกเลี่ยงการสร้างคีย์จำนวนมากเกินไปใน Android Keystore เนื่องจากเป็นทรัพยากรที่แชร์สำหรับแอปทั้งหมดในอุปกรณ์ ตั้งแต่ Android 17 เป็นต้นไป ระบบจะบังคับใช้ขีดจํากัดจํานวนคีย์ที่แอปเป็นเจ้าของได้ โดยจำกัดไว้ที่ 50,000 คีย์สำหรับแอปที่ไม่ใช่ระบบที่กำหนดเป้าหมายเป็น Android 17 (ระดับ API 37) ขึ้นไป และ 200,000 คีย์สำหรับแอปอื่นๆ ทั้งหมด แอปของระบบมีขีดจำกัดคีย์อยู่ที่ 200,000 คีย์ ไม่ว่าแอปจะกำหนดเป้าหมายเป็นระดับ API ใดก็ตาม
หากแอปพยายามสร้างคีย์เกินขีดจำกัด การสร้างจะไม่สำเร็จและมีข้อความ KeyStoreException แสดงขึ้น สตริงข้อความของข้อยกเว้นมีข้อมูลเกี่ยวกับขีดจำกัดของคีย์
หากแอปเรียกใช้ getNumericErrorCode() ใน
ข้อยกเว้น ค่าที่ส่งคืนจะขึ้นอยู่กับระดับ API ที่แอปกำหนดเป้าหมาย
- แอปที่กำหนดเป้าหมายเป็น Android 17 (API ระดับ 37) ขึ้นไป:
getNumericErrorCode()จะแสดงค่าERROR_TOO_MANY_KEYSใหม่ - แอปอื่นๆ ทั้งหมด:
getNumericErrorCode()คืนค่า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.POINTER_CAPTURE_MODE_ABSOLUTE 调用新的 View.requestPointerCapture(int) 方法。
สื่อ
Android 17 มีการเปลี่ยนแปลงลักษณะการทำงานของสื่อต่อไปนี้
การปิดช่องโหว่ของเสียงเบื้องหลัง
ตั้งแต่ Android 17 เป็นต้นไป เฟรมเวิร์กเสียงจะบังคับใช้ข้อจำกัดในการโต้ตอบเสียงในเบื้องหลัง ซึ่งรวมถึงการเล่นเสียง คำขอโฟกัสเสียง และ API การเปลี่ยนระดับเสียง เพื่อให้มั่นใจว่าผู้ใช้เป็นผู้เริ่มการเปลี่ยนแปลงเหล่านี้โดยเจตนา
หากแอปพยายามเรียกใช้ Audio API ขณะที่แอปไม่ได้อยู่ในวงจรที่ถูกต้อง
API การเล่นเสียงและการเปลี่ยนระดับเสียงจะทำงานไม่สำเร็จโดยไม่มีการแจ้งเตือน
ข้อยกเว้นหรือแสดงข้อความว่าไม่สำเร็จ API โฟกัสเสียงล้มเหลวโดยมีรหัสผลลัพธ์ AUDIOFOCUS_REQUEST_FAILED
ดูข้อมูลเพิ่มเติม รวมถึงกลยุทธ์การลดความเสี่ยงได้ที่การปิดช่องโหว่เสียงในเบื้องหลัง
การเชื่อมต่อ
Android 17 มีการเปลี่ยนแปลงต่อไปนี้เพื่อเพิ่มประสิทธิภาพการเชื่อมต่ออุปกรณ์
การจับคู่ใหม่โดยอัตโนมัติเมื่อการเชื่อมต่อบลูทูธขาดหายไป
Android 17 ขอแนะนำการจับคู่ใหม่ด้วยตัวเอง ซึ่งเป็นการปรับปรุงระดับระบบที่ออกแบบมาเพื่อแก้ไขการสูญเสียการเชื่อมต่อ Bluetooth โดยอัตโนมัติ
ก่อนหน้านี้ หากการเชื่อมต่อขาดหายไป ผู้ใช้ต้องไปที่การตั้งค่าเพื่อยกเลิกการจับคู่และจับคู่กับอุปกรณ์ต่อพ่วงอีกครั้งด้วยตนเอง ฟีเจอร์นี้สร้างขึ้นจากการปรับปรุงความปลอดภัยของ Android 16 โดยอนุญาตให้ระบบสร้างการเชื่อมต่อใหม่ในเบื้องหลังโดยไม่กำหนดให้ผู้ใช้ไปที่การตั้งค่าเพื่อยกเลิกการจับคู่และจับคู่กับอุปกรณ์ต่อพ่วงอีกครั้งด้วยตนเอง
แม้ว่าแอปส่วนใหญ่จะไม่ต้องมีการเปลี่ยนแปลงโค้ด แต่นักพัฒนาแอปควรทราบถึงการเปลี่ยนแปลงลักษณะการทำงานต่อไปนี้ในสแต็ก Bluetooth
- บริบทการจับคู่ใหม่: ตอนนี้
ACTION_PAIRING_REQUESTมีส่วนเพิ่มเติมEXTRA_PAIRING_CONTEXTซึ่งช่วยให้แอปแยกแยะระหว่างคำขอการจับคู่มาตรฐานกับความพยายามในการจับคู่ใหม่ที่ระบบเริ่มต้นเองได้ - การอัปเดตคีย์แบบมีเงื่อนไข: ระบบจะแทนที่คีย์ความปลอดภัยที่มีอยู่ก็ต่อเมื่อการจับคู่ใหม่สำเร็จและการเชื่อมต่อใหม่มีระดับความปลอดภัยเท่ากับหรือสูงกว่าการเชื่อมต่อก่อนหน้า
- การกำหนดเวลา Intent ที่แก้ไข: ตอนนี้ระบบจะออกอากาศ Intent
ACTION_KEY_MISSINGก็ต่อเมื่อความพยายามในการจับคู่ใหม่ด้วยตัวเองล้มเหลว ซึ่งจะช่วยลดการจัดการข้อผิดพลาดที่ไม่จำเป็นในแอปหากระบบกู้คืนการเชื่อมต่อในเบื้องหลังได้สำเร็จ - การแจ้งเตือนผู้ใช้: ระบบจะจัดการการจับคู่ใหม่ผ่านการแจ้งเตือนและกล่องโต้ตอบ UI ใหม่ ระบบจะแจ้งให้ผู้ใช้ยืนยันความพยายามในการจับคู่ใหม่เพื่อให้ผู้ใช้ทราบถึงการเชื่อมต่อใหม่
ผู้ผลิตอุปกรณ์ต่อพ่วงและนักพัฒนาแอปที่ใช้ร่วมกันควรตรวจสอบว่าฮาร์ดแวร์และแอปจัดการการเปลี่ยนการเชื่อมต่อได้อย่างราบรื่น หากต้องการทดสอบลักษณะการทำงานนี้ ให้จำลองการสูญเสียการเชื่อมต่อระยะไกลโดยใช้วิธีใดวิธีหนึ่งต่อไปนี้
- นำข้อมูลการเชื่อมต่อออกจากอุปกรณ์ต่อพ่วงด้วยตนเอง
- ยกเลิกการจับคู่อุปกรณ์ด้วยตนเองในส่วนการตั้งค่า > อุปกรณ์ที่เชื่อมต่อ