Izin runtime

Di Android 6.0 dan yang lebih tinggi, model izin aplikasi Android dirancang untuk membuat izin akses lebih mudah dipahami, berguna, dan aman bagi pengguna. Model ini memindahkan Android aplikasi yang memerlukan izin berbahaya (lihat Izin yang terpengaruh) dari model izin waktu penginstalan ke model izin runtime:

  • Izin waktu penginstalan

    (Android 5.1 dan yang lebih lama) Pengguna memberikan izin berbahaya ke aplikasi saat mereka menginstal atau mengupdate aplikasi. Perangkat produsen dan operator dapat melakukan pra-penginstalan aplikasi dengan izin yang telah diberikan sebelumnya tanpa memberi tahu .

  • Izin runtime

    (Android 6.0 hingga 9) Pengguna memberikan izin berbahaya ke aplikasi saat aplikasi sedang berjalan. Saat izin diminta (seperti saat aplikasi diluncurkan atau saat pengguna mengakses fitur) bergantung pada aplikasi, tetapi pengguna memberikan/menolak akses aplikasi ke izin akses yang berbeda. OEM/operator dapat melakukan pra-penginstalan aplikasi, tetapi tidak dapat memberikan izin terlebih dahulu, kecuali jika melalui proses pengecualian. (Lihat Membuat pengecualian.)

    (Android 10) Pengguna melihat peningkatan transparansi dan mengontrol aplikasi mana yang memiliki izin runtime pengenalan aktivitas (AR). Pengguna diminta oleh dialog izin runtime untuk selalu mengizinkan, mengizinkan saat digunakan, atau menolak izin. Pada upgrade OS ke Android 10, izin yang diberikan ke aplikasi akan dipertahankan, tetapi pengguna dapat membuka Setelan dan mengubahnya.

Izin runtime mencegah aplikasi mendapatkan akses ke data pribadi tanpa persetujuan pengguna, dan memberi mereka konteks dan visibilitas tambahan ke dalam jenis izin yang aplikasi mencari, atau telah diizinkan. Model runtime mendorong developer untuk membantu pengguna memahami mengapa aplikasi memerlukan izin yang diminta, dan memberikan transparansi sehingga pengguna dapat membuat keputusan yang lebih baik tentang memberikan atau menolak mereka.

Izin yang terpengaruh

Android 6.0 dan yang lebih tinggi memerlukan izin berbahaya untuk menggunakan model izin runtime. Izin berbahaya adalah izin berisiko lebih tinggi (seperti READ_CALENDAR) yang memberikan meminta aplikasi mengakses data pengguna pribadi, atau mengontrol perangkat, yang dapat menimbulkan berdampak pada pengguna. Untuk melihat daftar izin berbahaya, jalankan perintah:

adb shell pm list permissions -g -d

Android 6.0 dan yang lebih tinggi tidak mengubah perilaku normal izin akses. Ini semua adalah izin akses tidak berbahaya termasuk izin akses normal, sistem, dan izin tanda tangan. Izin normal adalah izin berisiko rendah (seperti SET_WALLPAPER) yang memberikan izin akses aplikasi ke tingkat aplikasi terisolasi fitur dengan risiko minimal terhadap aplikasi lain, sistem, atau pengguna. Seperti pada Android 5.1 dan rilis yang lebih rendah, sistem secara otomatis memberikan izin normal ke aplikasi yang meminta di penginstalan dan tidak meminta persetujuan pengguna. Untuk detail tentang izin, lihat <izin> elemen ini.

Pembatasan ketat dan longgar di Android 10

Selain berbahaya, izin akses dapat dibatasi secara ketat atau dibatasi secara terbatas. Dalam kedua kasus tersebut, izin terbatas juga harus diizinkan. Tidak diizinkan perilaku pembatasan ketat berbeda dengan kebijakan sementara yang tidak diizinkan batasan:

  • (Pembatasan ketat) Aplikasi tidak bisa diberi izin yang tidak telah masuk daftar yang diizinkan.
  • (Pembatasan sementara) Aplikasi tanpa daftar yang diizinkan akan berperilaku sesuai dengan izin khusus yang mereka minta. Perilaku tersebut dijelaskan di hadapan publik dokumentasi untuk izin yang diminta.

Saat menginstal aplikasi, penginstal (seperti Google Play Store) dapat memilih tidak mengizinkan aplikasi dengan izin terbatas. Izin adalah dibatasi oleh platform dan hanya dapat diberikan jika aplikasi memenuhi kriteria khusus sesuai dengan kebijakan platform. Contoh jenis izin yang dibatasi keras termasuk SMS dan izin Log Panggilan.

Pemberian izin terjadi selama penginstalan, dan saat

  • aplikasi sudah diinstal selama upgrade Android 9-ke-10.
  • memberikan izin akses atau aplikasi sudah diinstal lebih dulu.
  • izin diperlukan untuk peran yang sudah ditentukan untuk mengizinkan izin akses.
  • penginstal (seperti Google Play Store) menandai izin tersebut sebagai telah masuk daftar yang diizinkan.

Pengguna tidak dapat mengizinkan izin secara manual.

Persyaratan

Model izin runtime berlaku untuk semua aplikasi, termasuk aplikasi dan aplikasi yang telah diinstal sebelumnya dikirim ke perangkat sebagai bagian dari proses pengaturan. Persyaratan software aplikasi mencakup:

  • Model izin runtime harus konsisten di semua perangkat yang menjalankan Android 6.0 dan lebih tinggi. Hal ini diterapkan oleh pengujian Android Compatibility Test Suite (CTS).
  • Aplikasi harus meminta pengguna untuk memberikan izin aplikasi saat runtime. Untuk mengetahui detailnya, lihat Memperbarui aplikasi. Pengecualian terbatas dapat diberikan untuk aplikasi dan pengendali default yang menyediakan fungsi perangkat dasar yang mendasari operasi perangkat yang diharapkan. (Misalnya, aplikasi Telepon default perangkat untuk menangani ACTION_CALL mungkin memiliki Akses izin telepon.) Untuk mengetahui detailnya, lihat Membuat pengecualian.
  • Aplikasi bawaan yang memiliki izin berbahaya harus menargetkan API level 23 dan mempertahankan model izin runtime. Yaitu, alur UI selama instalasi aplikasi tidak boleh menyimpang dari implementasi AOSP dari PermissionController, pengguna dapat mencabut izin berbahaya dari aplikasi bawaan, sehingga kueri.
  • Aplikasi headless harus menggunakan aktivitas untuk meminta izin atau membagikan UID dengan aplikasi lain yang memiliki izin yang diperlukan. Untuk mengetahui detailnya, lihat Aplikasi headless.

Migrasi izin

Izin yang diberikan untuk aplikasi di Android 5.x tetap diberikan setelah mengupdate ke Android 6.0 atau lebih tinggi, tetapi pengguna dapat mencabut izin akses tersebut kapan saja.

Dalam update Android 9-ke-10, semua izin akses yang dibatasi telah masuk daftar yang diizinkan. Untuk mengetahui detail tentang cara menerapkan izin pemisahan latar depan/latar belakang, lihat perubahan privasi Android 10, dimulai dengan Meminta latar belakang Google Cloud Platform.

Integrasi

Ketika mengintegrasikan model izin runtime aplikasi untuk Android 6.0 dan yang lebih tinggi, Anda harus mengupdate aplikasi bawaan agar berfungsi dengan model baru. Anda juga dapat menentukan pengecualian untuk aplikasi yang merupakan pengendali/penyedia default untuk fungsionalitas inti, menentukan izin khusus, dan menyesuaikan tema yang digunakan di aplikasi PermissionController.

Update aplikasi

Aplikasi pada image sistem dan aplikasi yang telah diinstal lebih dulu tidak secara otomatis diberi akses izin akses. Kami mendorong Anda untuk bekerja sama dengan pengembang aplikasi bawaan (OEM, operator, dan pihak ketiga) untuk melakukan modifikasi aplikasi yang diperlukan menggunakan pedoman kami. Secara khusus, Anda harus memastikan bahwa aplikasi prainstal dimodifikasi untuk menghindari kerusakan dan masalah lain ketika pengguna mencabut izin akses.

Aplikasi bawaan

Di Android 9 dan yang lebih rendah, aplikasi pramuat yang menggunakan izin berbahaya harus menargetkan API level 23 atau yang lebih tinggi, serta mempertahankan model izin AOSP Android 6.0 dan yang lebih tinggi. Misalnya, alur UI selama instalasi aplikasi tidak boleh menyimpang dari implementasi AOSP dari PermissionController. Pengguna bahkan dapat mencabut izin akses berbahaya aplikasi bawaan.

Di Android 6.0 hingga 9, beberapa izin diberikan selama alur penginstalan. Namun, memulai pada 10, alur penginstalan (dilakukan oleh aplikasi Package Installer) adalah fungsi terpisah dari pemberian izin (di Permission Controller).

Aplikasi headless

Hanya aktivitas yang dapat meminta izin. Layanan tidak dapat meminta izin secara langsung.

  • Di Android 5.1 dan yang lebih lama, aplikasi headless dapat meminta izin saat diinstal, atau jika sudah diinstal sebelumnya tanpa menggunakan aktivitas.
  • Di beberapa Pada Android 6.0 dan yang lebih tinggi, aplikasi headless harus menggunakan salah satu metode berikut untuk meminta izin:
    • Tambahkan aktivitas untuk meminta izin. (Ini adalah metode yang direkomendasikan.)
    • Bagikan UID ke aplikasi lain yang memiliki izin yang diperlukan. Gunakan ini metode hanya jika Anda memerlukan platform untuk menangani multi-APK sebagai satu .

Tujuannya adalah untuk menghindari kebingungan pengguna dengan permintaan izin yang muncul di luar konteks.

Menyesuaikan UI PackageInstaller

Jika diinginkan, Anda dapat menyesuaikan tema UI Izin dengan memperbarui tema perangkat default (Theme.DeviceDefault.Settings dan Theme.DeviceDefault.Light.Dialog.NoActionBar) yang digunakan oleh {i>PackageInstaller<i}. Namun, karena konsistensi sangat penting bagi developer aplikasi, Anda tidak dapat menyesuaikan penempatan, posisi, dan aturan terkait kapan Izin UI muncul.

Guna menyertakan string untuk bahasa tambahan, kontribusikan ke AOSP.

Membuat pengecualian

Anda dapat memberikan izin terlebih dahulu ke aplikasi yang merupakan pengendali atau untuk fungsionalitas OS inti yang menggunakan Class DefaultPermissionGrantPolicy.java di PackageManager. Contoh:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

Menentukan izin khusus

Anda dapat menetapkan grup dan izin kustom sebagai normal atau berbahaya dan menambahkan izin khusus OEM/Operator ke izin yang ada grup izin akses Anda, seperti yang bisa Anda lakukan di rilis Android 5.x dan versi sebelumnya.

Di Android 6.0 dan yang lebih baru, jika Anda menambahkan izin berbahaya baru, izin tersebut harus ditangani di dengan cara yang sama seperti izin berbahaya lainnya (diminta selama runtime aplikasi dan dapat dibatalkan oleh pengguna). Khususnya:

  • Anda dapat menambahkan izin baru ke grup saat ini, tetapi Anda tidak dapat mengubah Pemetaan AOSP untuk grup izin berbahaya dan grup izin berbahaya. (Dengan kata lain, Anda tidak dapat menghapus izin dari grup dan menetapkannya ke grup lain).
  • Anda dapat menambahkan grup izin akses baru di aplikasi yang diinstal di perangkat, tetapi Anda tidak dapat menambahkan grup perizinan baru di manifes platform.

Izin pengujian

Android menyertakan pengujian Compatibility Test Suite (CTS) yang memverifikasi izin akses individual dipetakan ke kelompok yang benar. Lulus tes ini adalah persyaratan untuk kompatibilitas Android 6.0 dan yang lebih baru.

Mencabut izin

Di Android 13 dan yang lebih baru, Anda dapat mencabut izin Anda sendiri izin runtime menggunakan Context.revokeSelfPermissionsOnKill(). Pencabutan terjadi secara asinkron dan dipicu jika aman untuk melakukannya tanpa mengganggu pengguna. Saat pencabutan dipicu, semua proses yang berjalan dalam UID panggilan akan dihentikan.

Penting untuk dipahami bahwa mencabut satu izin mungkin tidak tercermin dalam {i>setting<i}, yang memperlakukan izin akses berdasarkan grup. Biasanya, grup izin akses ditampilkan sebagai diberikan selama setidaknya salah satu izin akses dalam grup tersebut diberikan. Jika memastikan bahwa pengguna dapat mengonfirmasi pencabutan di setelan penting bagi Anda, pastikan untuk mencabut setiap izin akses di grup izin. Untuk mempelajari izin akses yang dimiliki grup tertentu, Anda dapat gunakan PackageManager.getGroupOfPlatformPermission dan PackageManager.getPlatformPermissionsForGroup.

Saat sistem mencabut izin yang diminta, sistem juga akan mencabut latar belakang terkait izin akses jika tidak ada izin akses latar depan yang sesuai yang masih diberikan.

Pencabutan tidak dipicu selama proses tetap berada di latar depan, tetapi dapat juga dipicu dengan segera dengan mematikan secara manual semua proses yang berjalan di uid saat ini, untuk menggunakan System.exit(). Namun, sebaiknya biarkan sistem memutuskan kapan akan memicunya.

Setelah pencabutan izin berlaku, Anda dapat memintanya lagi, dan pengguna yang diminta untuk menyetujui atau menolak permintaan tersebut. Anda tidak mungkin meminta izin akses yang memiliki sebelumnya telah ditolak oleh pengguna. Walaupun Anda dianjurkan untuk mencabut izin akses yang Anda tetapi tidak lagi diperlukan, Anda harus berhati-hati agar tidak memberi tahu pengguna pencabutan sampai setelah itu diberlakukan.