Perubahan perilaku: Aplikasi yang menargetkan Android 17 atau yang lebih tinggi

Seperti rilis sebelumnya, Android 17 menyertakan perubahan perilaku yang mungkin memengaruhi aplikasi Anda. Perubahan perilaku berikut ini berlaku khusus bagi aplikasi yang menargetkan Android 17 atau yang lebih tinggi. Jika aplikasi Anda menargetkan Android 17 atau yang lebih tinggi, Anda harus memodifikasi aplikasi untuk mendukung perilaku ini, jika berlaku.

Pastikan Anda juga meninjau daftar perubahan perilaku yang memengaruhi semua aplikasi yang berjalan di Android 17, terlepas dari targetSdkVersion aplikasi Anda.

Catatan: Halaman ini mencantumkan beberapa perubahan yang lebih penting. Untuk informasi yang lebih mendetail, lihat catatan rilis Android 17.

Fungsi inti

Android 17 menyertakan perubahan berikut yang mengubah atau memperluas berbagai kemampuan inti sistem Android.

Implementasi MessageQueue baru tanpa kunci

Mulai Android 17, aplikasi yang menargetkan Android 17 (level API 37) atau yang lebih tinggi menerima penerapan bebas kunci baru dari android.os.MessageQueue. Implementasi baru ini meningkatkan performa dan mengurangi frame yang terlewat, tetapi dapat merusak klien yang mencerminkan kolom dan metode pribadi MessageQueue.

Untuk mengetahui informasi selengkapnya, termasuk strategi mitigasi, lihat Panduan perubahan perilaku MessageQueue.

Kolom final statis kini tidak dapat diubah

Aplikasi yang berjalan di Android 17 atau yang lebih tinggi yang menargetkan Android 17 (level API 37) atau yang lebih tinggi tidak dapat mengubah kolom static final. Jika aplikasi mencoba mengubah kolom static final menggunakan refleksi, aplikasi tersebut akan menyebabkan IllegalAccessException. Mencoba mengubah salah satu kolom ini melalui API JNI (seperti SetStaticLongField()) akan menyebabkan aplikasi error.

Aksesibilitas

Android 17 membuat perubahan berikut untuk meningkatkan aksesibilitas.

Dukungan aksesibilitas untuk pengetikan keyboard fisik IME yang kompleks

此功能引入了新的 AccessibilityEvent 和 TextAttribute API，以增强屏幕阅读器针对 CJKV 语言输入的语音反馈。CJKV IME 应用现在可以指示在文本撰写期间是否已选择文本转换候选内容。具有编辑字段的应用可以在发送文本更改无障碍事件时指定文本更改类型。例如，应用可以指定在文本撰写期间发生了文本更改，或者文本更改是由提交导致的。这样做可让屏幕阅读器等无障碍服务根据文本修改的性质提供更精确的反馈。

应用采用量

• IME 应用：在编辑字段中设置正在撰写的文本时，IME 可以使用 TextAttribute.Builder.setTextSuggestionSelected() 来指明是否选择了特定的转换候选对象。

• 具有“编辑字段”权限的应用：维护自定义 InputConnection 的应用可以通过调用 TextAttribute.isTextSuggestionSelected() 来检索候选选择数据。然后，这些应用在调度 TYPE_VIEW_TEXT_CHANGED 事件时应调用 AccessibilityEvent.setTextChangeTypes()。如果应用以 Android 17（API 级别 37）为目标平台，并使用标准 TextView，则默认启用此功能。（也就是说，TextView 将负责从 IME 检索数据，并在向无障碍服务发送事件时设置文本更改类型）。

• 无障碍服务：处理 TYPE_VIEW_TEXT_CHANGED 事件的无障碍服务可以调用 AccessibilityEvent.getTextChangeTypes() 来识别修改的性质，并相应地调整其反馈策略。

Privasi

Android 17 menyertakan perubahan berikut untuk meningkatkan privasi pengguna.

ECH (Encrypted Client Hello) diaktifkan

Android 17 引入了对加密客户端问候 (ECH) 的平台支持。ECH 是一种 TLS 扩展，可通过加密 TLS 握手中的服务器名称指示 (SNI) 来增强用户隐私保护。这种加密有助于防止网络观察者轻松识别您的应用所连接的特定网域。

对于以 Android 17（API 级别 37）或更高版本为目标平台的应用，ECH 用于 TLS 连接。只有当应用使用的网络库（例如 HttpEngine、WebView 或 OkHttp）已集成 ECH 支持，并且远程服务器也支持 ECH 协议时，ECH 才会处于活跃状态。如果无法协商 ECH，客户端会发送一个包含随机内容的 ECH 扩展（一种称为 ECH GREASE 的机制）。如需详细了解 ECH GREASE 的工作原理，请参阅 RFC 9849。

为了让应用能够自定义此行为，Android 17 向网络安全配置文件添加了一个新的 <domainEncryption> 元素。 开发者可以在 <base-config> 或 <domain-config> 标记中使用 <domainEncryption>，以全局或按网域的方式选择 ECH 模式（例如 "enabled" 或 "disabled"）。

如需了解详情，请参阅加密客户端问候文档。

Izin jaringan lokal diperlukan untuk aplikasi yang menargetkan Android 17

Android 17 引入了 ACCESS_LOCAL_NETWORK 运行时权限，以保护用户免遭未经授权的本地网络访问。由于此权限属于现有的 NEARBY_DEVICES 权限组，因此系统不会再次提示已授予其他 NEARBY_DEVICES 权限的用户。这项新要求可防止恶意应用利用不受限制的本地网络访问权限进行隐秘的用户跟踪和指纹识别。通过声明和请求此权限，您的应用可以发现并连接到局域网 (LAN) 中的设备，例如智能家居设备或投屏接收器。

以 Android 17（API 级别 37）或更高版本为目标平台的应用现在可以通过两种方式与 LAN 设备保持通信：采用系统介导的、可保护隐私的设备选择器来跳过权限提示，或者在运行时明确请求此新权限以保持本地网络通信。

如需了解详情，请参阅本地网络权限文档。

注意： 在 Android 16 中，应用可以选择启用本地网络权限。 自 Android 17 起，以 Android 17（API 级别 37）或更高版本为目标平台的应用必须强制执行此项检查。

Menyembunyikan sandi dari perangkat fisik

Jika aplikasi menargetkan Android 17 (level API 37) atau yang lebih tinggi dan pengguna menggunakan perangkat input fisik (misalnya, keyboard eksternal), sistem operasi Android menerapkan setelan show_passwords_physical baru ke semua karakter di kolom sandi. Secara default, setelan tersebut menyembunyikan semua karakter sandi.

Sistem Android menampilkan karakter sandi yang terakhir diketik untuk membantu pengguna melihat apakah mereka salah mengetik sandi. Namun, hal ini tidak terlalu diperlukan dengan keyboard eksternal yang lebih besar. Selain itu, perangkat dengan keyboard eksternal sering kali memiliki layar yang lebih besar, sehingga meningkatkan bahaya seseorang melihat sandi yang diketik.

Jika pengguna menggunakan layar sentuh perangkat, sistem akan menerapkan setelan show_passwords_touch baru.

Perlindungan OTP untuk pesan SMS standar

Mulai Android 17, Android memperluas perlindungan OTP SMS-nya untuk diterapkan pada pesan SMS standar (pesan SMS yang berisi OTP yang tidak menggunakan format WebOTP atau SMS Retriever). Untuk sebagian besar aplikasi yang menargetkan Android 17 (level API 37) atau yang lebih tinggi, pesan SMS ini tidak akan tersedia hingga tiga jam setelah diterima. Penundaan ini dimaksudkan untuk membantu mencegah pembajakan OTP. Selama penundaan tiga jam ini, siaran SMS_RECEIVED_ACTION akan ditahan dan kueri database penyedia SMS akan difilter. Pesan SMS tersedia untuk aplikasi ini setelah penundaan.

Aplikasi tertentu seperti aplikasi asisten SMS default, aplikasi pendamping perangkat terhubung, dll., dikecualikan dari penundaan ini. Semua aplikasi yang mengandalkan pembacaan pesan SMS untuk ekstraksi OTP harus beralih menggunakan SMS Retriever atau SMS User Consent API untuk memastikan fungsi yang berkelanjutan.

Catatan: Perlindungan OTP SMS tambahan untuk pesan format WebOTP dan SMS Retriever berlaku untuk semua aplikasi, terlepas dari level API targetnya. Untuk mengetahui informasi selengkapnya, lihat Perlindungan OTP SMS dalam dokumentasi Perubahan perilaku untuk semua aplikasi.

Keamanan

Android 17 membuat peningkatan berikut pada keamanan perangkat dan aplikasi.

Keamanan Aktivitas

在 Android 17 中，平台继续向“默认安全”架构转变，引入了一系列旨在缓解网络钓鱼、互动劫持和混淆代理攻击等高严重性漏洞的增强功能。此更新要求开发者明确选择启用新的安全标准，以保持应用兼容性和用户保护。

对开发者的主要影响包括：

• BAL 安全加固和改进的选择启用： 我们正在优化后台活动启动 (BAL) 限制，方法是将保护范围扩展到 IntentSender。开发者必须从旧版 MODE_BACKGROUND_ACTIVITY_START_ALLOWED 常量迁移。相反，您应 采用精细控制，例如 MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE，它将 活动启动限制为调用应用可见的场景，从而显著 缩小攻击面。
• 采用工具： 开发者应利用严格模式和更新后的 lint 检查来识别旧版模式，并确保为未来的目标 SDK 要求做好准备。

Mengaktifkan CT secara default

Jika aplikasi menargetkan Android 17 (API level 37) atau yang lebih tinggi, transparansi sertifikat (CT) akan diaktifkan secara default. (Di Android 16, CT tersedia, tetapi aplikasi harus ikut serta.)

DCL—C Native yang Lebih Aman

Jika aplikasi Anda menargetkan Android 17 (API level 37) atau yang lebih tinggi, perlindungan Pemuatan Kode Dinamis (DCL) yang Lebih Aman yang diperkenalkan di Android 14 untuk file DEX dan JAR kini diperluas ke library native.

Semua file native yang dimuat menggunakan System.load() harus ditandai sebagai hanya baca. Jika tidak, sistem akan menampilkan UnsatisfiedLinkError.

Sebaiknya aplikasi menghindari pemuatan kode secara dinamis jika memungkinkan, karena hal itu akan sangat meningkatkan risiko aplikasi disusupi oleh injeksi kode atau modifikasi kode.

Membatasi kolom PII dalam tampilan data CP2

对于以 Android 17（API 级别 Android 17（API 级别 37））及更高版本为目标平台的应用，联系人提供程序 2 (CP2) 会限制数据视图中包含某些个人身份信息 (PII) 的列。启用此变更后，这些列将从数据视图中移除，以增强用户隐私保护。 受限列包括：

• ACCOUNT_NAME
• ACCOUNT_TYPE
• ACCOUNT_TYPE_AND_DATA_SET

如果应用正在使用 ContactsContract.Data 中的这些列，则可以通过与 RAW_CONTACT_ID 联接，改为从 ContactsContract.RawContacts 中提取这些列。

Menerapkan pemeriksaan SQL yang ketat di CP2

对于以 Android 17（API 级别 37）及更高版本为目标平台的应用，当在没有 READ_CONTACTS 权限的情况下访问 ContactsContract.Data 表时，联系人提供程序 2 (CP2) 会强制执行严格的 SQL 查询验证。

在此项更改生效后，如果应用没有 READ_CONTACTS 权限，则在查询 ContactsContract.Data 表时会设置 StrictColumns 和 StrictGrammar 选项。如果查询使用的模式与这些模式不兼容，则会被拒绝并导致抛出异常。

Media

Android 17 menyertakan perubahan berikut pada perilaku media.

Penguatan audio latar belakang

Mulai Android 17, framework audio menerapkan batasan pada interaksi audio di latar belakang, termasuk pemutaran audio, permintaan fokus audio, dan API perubahan volume untuk memastikan bahwa perubahan ini dimulai secara sengaja oleh pengguna.

Beberapa batasan audio berlaku untuk semua aplikasi. Namun, pembatasan lebih ketat jika aplikasi menargetkan Android 17 (level API 37). Jika salah satu aplikasi ini berinteraksi dengan audio saat berada di latar belakang, aplikasi tersebut harus menjalankan layanan latar depan. Selain itu, aplikasi harus memenuhi satu atau kedua persyaratan berikut:

• Layanan latar depan harus memiliki kemampuan saat-sedang-digunakan (WIU).
• Aplikasi harus memiliki izin alarm tepat dan berinteraksi dengan aliran audio USAGE_ALARM.

Untuk mengetahui informasi selengkapnya, termasuk strategi mitigasi, lihat Penguatan audio latar belakang.

Faktor bentuk perangkat

Android 17 menyertakan perubahan berikut untuk meningkatkan pengalaman pengguna di berbagai ukuran dan faktor bentuk perangkat.

Perubahan API platform untuk mengabaikan batasan orientasi, perubahan ukuran, dan rasio aspek pada layar besar (sw>=600dp)

Kami memperkenalkan perubahan Platform API di Android 16 untuk mengabaikan orientasi, rasio aspek, dan batasan perubahan ukuran pada layar besar (sw >= 600dp) untuk aplikasi yang menargetkan API level 36 atau yang lebih tinggi. Developer memiliki opsi untuk tidak ikut serta dalam perubahan ini dengan SDK 36, tetapi opsi tidak ikut serta ini tidak akan lagi tersedia untuk aplikasi yang menargetkan Android 17 (API level 37) atau yang lebih tinggi.

Untuk mengetahui informasi selengkapnya, lihat Batasan pada orientasi dan perubahan ukuran di abaikan.

Konektivitas

Android 17 memperkenalkan perubahan berikut untuk meningkatkan konsistensi dan menyelaraskan dengan perilaku InputStream Java standar untuk soket RFCOMM Bluetooth.

Perilaku BluetoothSocket read() yang konsisten untuk RFCOMM

Untuk aplikasi yang menargetkan Android 17 (API level 37), metode read() dari InputStream yang diperoleh dari BluetoothSocket berbasis RFCOMM kini menampilkan -1 saat soket ditutup atau koneksi terputus.

Perubahan ini membuat perilaku soket RFCOMM konsisten dengan soket LE CoC dan selaras dengan dokumentasi standar InputStream.read(), yang menyatakan bahwa -1 ditampilkan saat akhir streaming tercapai.

Aplikasi yang hanya mengandalkan penangkapan IOException untuk keluar dari loop baca mungkin terpengaruh oleh perubahan ini dan harus memperbarui loop baca BluetoothSocket untuk memeriksa nilai yang ditampilkan secara eksplisit sebesar -1. Hal ini memastikan loop berakhir dengan benar saat perangkat jarak jauh terputus atau soket ditutup. Untuk contoh penerapan yang direkomendasikan, lihat cuplikan kode dalam panduan Mentransfer data Bluetooth.