Perubahan perilaku: semua aplikasi

Platform Android 11 menyertakan perubahan perilaku yang dapat memengaruhi aplikasi Anda. Perubahan perilaku berikut ini berlaku untuk semua aplikasi saat dijalankan di Android 11, terlepas dari targetSdkVersion aplikasi. Sebaiknya uji aplikasi Anda lalu modifikasi sesuai kebutuhan untuk mendukung perubahan ini dengan tepat, jika memungkinkan.

Selain itu, pastikan Anda meninjau daftar perubahan perilaku yang hanya memengaruhi aplikasi yang menargetkan Android 11.

Privasi

Android 11 memperkenalkan banyak perubahan dan pembatasan untuk meningkatkan privasi pengguna. Untuk mempelajari lebih lanjut, lihat halaman Privasi.

Keamanan

Menjalankan enkripsi berbasis file setelah OTA dimulai ulang tanpa kredensial pengguna

Setelah perangkat menerima update OTA dan dimulai ulang, kunci Enkripsi Kredensial yang terletak di penyimpanan yang dilindungi kredensial akan langsung tersedia untuk operasi Enkripsi Berbasis File (FBE). Oleh karena itu, aplikasi Anda dapat melakukan tindakan terkait enkripsi berbasis file sebelum pengguna memasukkan PIN, pola, atau sandi mereka untuk membuka kunci perangkat setelah memulai ulang.

Catatan: Perubahan ini hanya memengaruhi proses mulai ulang perangkat yang terjadi karena update OTA. Jika aplikasi Anda harus selalu "dilanjutkan setelah reboot", lanjutkan ke dukungan Booting Langsung.

Soket SSL menggunakan mesin SSL Conscrypt secara default

Implementasi SSLSocket default Android didasarkan pada Conscrypt. Mulai di Android 11, implementasi tersebut dikembangkan secara internal dari SSLEngine Conscrypt.

Scudo Hardened Allocator

Android 11 menggunakan Scudo Hardened Allocator secara internal untuk alokasi heap layanan. Scudo dapat mendeteksi dan mengurangi beberapa jenis pelanggaran keamanan memori. Jika Anda melihat error terkait Scudo (misalnya Scudo ERROR:) dalam laporan masalah pada native code, baca dokumentasi Pemecahan masalah Scudo.

Statistik penggunaan aplikasi

Agar dapat melindungi pengguna dengan lebih baik, Android 11 menyimpan setiap statistik penggunaan aplikasi pengguna dalam penyimpanan yang dienkripsi dengan kredensial. Oleh karena itu, baik sistem maupun aplikasi apa pun tidak dapat mengakses data tersebut kecuali isUserUnlocked() menampilkan true, yang terjadi setelah salah satu kondisi berikut terpenuhi:

• Pengguna membuka kunci perangkatnya untuk pertama kalinya setelah memulai sistem.
• Pengguna beralih ke akunnya di perangkat.

Jika aplikasi Anda sudah terikat pada instance UsageStatsManager, pastikan apakah Anda memanggil metode pada objek ini setelah pengguna membuka kunci perangkatnya. Jika tidak, API akan menampilkan nilai kosong atau null.

Kamera

Dukungan untuk penggunaan lebih dari satu kamera secara serentak

Android 11 menambahkan API guna membuat kueri dukungan untuk penggunaan lebih dari satu kamera pada satu waktu, termasuk kamera depan dan belakang.

Untuk memeriksa dukungan pada perangkat tempat aplikasi Anda berjalan, gunakan metode berikut:

• getConcurrentCameraIds() menampilkan Set dari kombinasi ID kamera yang dapat melakukan streaming secara serentak dengan kombinasi streaming yang terjamin jika dikonfigurasi dengan proses aplikasi yang sama.
• isConcurrentSessionConfigurationSupported() membuat kueri tentang apakah perangkat kamera dapat mendukung konfigurasi sesi yang sesuai secara serentak atau tidak.

Konektivitas

Perubahan pada Open Mobile API

Mulai di Android 11, Open Mobile API (OMAPI) memiliki fungsi tambahan:

• Mengurai aturan untuk hak istimewa operator.

• Menyesuaikan akses Elemen Pengaman tersemat (eSE) atau menyediakan eSE menggunakan satu atau beberapa hal berikut:

  • Izin hak istimewa sistem
  • ID aplikasi (AID) Access Rule Application Master (ARA-M) yang dapat dikonfigurasi
  • API sistem untuk mereset pembaca OMAPI

• Memberi pembaca indikator yang jelas bagi aplikasi untuk memfilter kemampuan perangkat.

Performa dan proses debug

Proses debug batasan pemanggilan JobScheduler API

Android 11 menawarkan dukungan proses debug untuk aplikasi guna mengidentifikasi potensi pemanggilan JobScheduler API yang telah melampaui batas kapasitas tertentu. Developer dapat menggunakan fasilitas ini untuk mengidentifikasi potensi masalah performa. Untuk aplikasi dengan atribut manifes debuggable yang ditetapkan ke benar, pemanggilan JobScheduler API yang melampaui batas kapasitas akan menampilkan RESULT_FAILURE. Pembatasan ditetapkan agar kasus penggunaan yang sah tidak terpengaruh.

File descriptor sanitizer (fdsan)

Android 10 memperkenalkan fdsan (file descriptor sanitizer). fdsan mendeteksi kesalahan penanganan kepemilikan deskriptor file, seperti use-after-close dan double-close. Mode default untuk fdsan berubah di Android 11. fdsan sekarang akan dibatalkan setelah mendeteksi error; perilaku sebelumnya adalah mencatat log peringatan dan melanjutkan proses. Jika Anda menemukan error karena fdsan di aplikasi Anda, referensikan fdsan documentation.

Aksesibilitas

Pembaca layar memerlukan penetapan tindakan aksesibilitas berbasis klik

Pada versi Android sebelumnya, framework ini mengirimkan peristiwa sentuh ke widget yang tidak menangani tindakan aksesibilitas berbasis klik dengan benar. Biasanya, tampilan ini menangani peristiwa sentuh secara langsung, bukan mendaftarkan pemroses klik.

Untuk membuat perilaku yang lebih konsisten di aplikasi yang menentukan tindakan aksesibilitas dengan benar, Android 11 tidak pernah mengirimkan peristiwa sentuh. Namun, sistem sepenuhnya mengandalkan tindakan aksesibilitas berbasis klik: ACTION_CLICK dan ACTION_LONG_CLICK. Perubahan ini memengaruhi perilaku pembaca layar.

Sistem menangani widget yang menggunakan antarmuka OnClickListener dan OnLongClickListener. Namun, jika aplikasi menggunakan widget yang lebih disesuaikan yang bergantung pada antarmuka OnTouchListener, Anda harus menentukan pengendali kustom untuk tindakan aksesibilitas berbasis klik. Untuk melakukannya, panggil metode replaceAccessibilityAction() untuk setiap tindakan, seperti dalam cuplikan kode berikut:

Kotlin

// Assumes that the widget is designed to select text when tapped and select
// all text when long-tapped. In its strings.xml file, this app has set
// "select" to "Select" and "select_all" to "Select all", respectively.
ViewCompat.replaceAccessibilityAction(
            WIDGET,
            ACTION_CLICK,
            context.getString(R.string.select)
) { view, commandArguments ->
    selectText()
}

ViewCompat.replaceAccessibilityAction(
            WIDGET,
            ACTION_LONG_CLICK,
            context.getString(R.string.select_all)
) { view, commandArguments ->
    selectAllText()
}

Java

// Assumes that the widget is designed to select text when tapped and select
// all text when long-tapped. In its strings.xml file, this app has set
// "select" to "Select" and "select_all" to "Select all", respectively.
ViewCompat.replaceAccessibilityAction(WIDGET, ACTION_CLICK,
        context.getString(R.string.select),
        (view, commandArguments) -> {
            selectText();
        });

ViewCompat.replaceAccessibilityAction(WIDGET, ACTION_LONG_CLICK,
        context.getString(R.string.select_all),
        (view, commandArguments) -> {
            selectAllText();
        });

Catatan: Pada versi Android sebelumnya, Anda juga harus menentukan tindakan aksesibilitas dalam widget kustom agar layanan aksesibilitas lainnya, seperti Tombol Akses, dapat berfungsi sesuai ekspektasi. Untuk memudahkan aplikasi berinteraksi dengan layanan aksesibilitas sistem, kami sangat merekomendasikan agar Anda memperluas widget sistem dari hierarki class UI Android yang paling dalam.

Mendeklarasikan penggunaan tombol aksesibilitas di file metadata

Mulai di Android 11, layanan aksesibilitas tidak dapat mendeklarasikan pengaitan dengan tombol aksesibilitas sistem pada waktu proses. Jika Anda menambahkan AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON ke properti flags objek AccessibilityServiceInfo, framework tidak akan meneruskan peristiwa callback tombol aksesibilitas ke layanan Anda.

Sekarang, Anda dapat mendeklarasikan atribusi layanan aksesibilitas dengan tombol aksesibilitas menggunakan tanda flagRequestAccessibilityButton di file metadata layanan aksesibilitas, biasanya berupa res/raw/accessibilityservice.xml.

Antarmuka pengguna

Perubahan SYSTEM_ALERT_WINDOW

Terdapat beberapa perubahan pada cara aplikasi mendapatkan izin SYSTEM_ALERT_WINDOW. Perubahan tersebut dimaksudkan untuk melindungi pengguna dengan membuat pemberian izin menjadi lebih intensional.

Aplikasi tertentu diberikan izin SYSTEM_ALERT_WINDOW secara otomatis jika diminta

Class aplikasi tertentu mendapatkan izin SYSTEM_ALERT_WINDOW secara otomatis jika diminta. Aplikasi ini tidak perlu mengirimkan ACTION_MANAGE_OVERLAY_PERMISSION untuk mendapatkan izin SYSTEM_ALERT_WINDOW; aplikasi dapat meminta SYSTEM_ALERT_WINDOW secara langsung.

Semua aplikasi yang memiliki ROLE_CALL_SCREENING dan meminta SYSTEM_ALERT_WINDOW akan mendapatkan izin secara otomatis. Jika aplikasi kehilangan ROLE_CALL_SCREENING, izin juga akan hilang.

Intent MANAGE_OVERLAY_PERMISSION selalu mengarahkan pengguna ke layar izin sistem

Mulai dari Android 11, intent ACTION_MANAGE_OVERLAY_PERMISSION selalu membawa pengguna ke layar Setelan level atas di mana pengguna dapat memberikan atau mencabut izin SYSTEM_ALERT_WINDOW untuk aplikasi. Semua data package: dalam intent akan diabaikan.

Pada versi Android sebelumnya, intent ACTION_MANAGE_OVERLAY_PERMISSION dapat menentukan paket, yang akan mengarahkan pengguna ke layar khusus aplikasi untuk mengelola izin. Fungsi ini tidak lagi didukung di Android 11. Sebagai gantinya, pengguna harus memilih aplikasi yang ingin diberi izin atau cabut izinnya terlebih dahulu. Perubahan ini dimaksudkan untuk melindungi pengguna dengan membuat pemberian izin menjadi lebih intensional.

Kompatibilitas aplikasi

Pembatasan antarmuka non-SDK

Android 11 menyertakan daftar terbaru antarmuka non-SDK yang dibatasi berdasarkan kolaborasi dengan developer Android dan pengujian internal terbaru. Jika memungkinkan, kami akan memastikan ketersediaan alternatif publik sebelum membatasi antarmuka non-SDK.

Jika aplikasi Anda tidak menargetkan Android 11, beberapa perubahan ini mungkin tidak langsung memengaruhi Anda. Namun, meskipun saat ini Anda dapat menggunakan antarmuka non-SDK yang merupakan bagian dari daftar abu-abu (bergantung pada API level target aplikasi Anda), penggunaan metode atau kolom non-SDK tetap sangat berisiko merusak aplikasi Anda.

Jika tidak yakin apakah aplikasi Anda menggunakan antarmuka non-SDK atau tidak, Anda dapat menguji aplikasi untuk mencari tahu. Jika aplikasi Anda mengandalkan antarmuka non-SDK, sebaiknya mulailah merencanakan migrasi ke alternatif SDK. Meskipun begitu, kami paham bahwa beberapa aplikasi memiliki kasus penggunaan yang valid untuk menggunakan antarmuka non-SDK. Jika tidak dapat menemukan alternatif penggunaan antarmuka non-SDK untuk fitur dalam aplikasi Anda, sebaiknya minta API publik baru.

Untuk mempelajari perubahan dalam rilis Android ini lebih lanjut, baca Pembaruan pembatasan antarmuka non-SDK di Android 11. Untuk mempelajari antarmuka non-SDK secara umum lebih lanjut, baca Pembatasan antarmuka non-SDK.

Library bersama Maps v1 dihapus

Library bersama Maps v1 telah dihapus sepenuhnya di Android 11. Library ini sebelumnya sudah tidak digunakan lagi dan berhenti berfungsi untuk aplikasi di Android 10. Aplikasi yang sebelumnya mengandalkan library bersama ini untuk perangkat yang menjalankan Android 9 (API level 28) atau yang lebih rendah harus menggunakan Maps SDK untuk Android.

Penting: Setelah melakukan migrasi ke Maps SDK untuk Android, pastikan Anda menghapus referensi ke library bersama Maps v1 dari elemen <uses-library> dalam file manifes aplikasi Anda. Aplikasi tidak dapat lagi menggunakan pemfilteran Google Play dengan library bersama Maps v1 dan elemen <uses-library>.