Skip to content

Most visited

Recently visited

navigation

Praktik Terbaik untuk Identifier Unik

Meskipun ada alasan kuat mengapa aplikasi Anda harus mengidentifikasi perangkat bukannya instance dari aplikasi atau pengguna yang terautentikasi pada perangkat, pada kebanyakan aplikasi, tujuan utamanya adalah untuk mengidetifikasi pemasangan tertentu dari aplikasi Anda (bukan perangkat fisik sebenarnya).

Untungnya, mengidentifikasi pemasangan pada Android sangat mudah dengan menggunakan Instance ID atau dengan membuat GUID Anda sendiri pada waktu pemasangan. Dokumen ini menjelaskan panduan untuk memilih identifier yang sesuai untuk aplikasi Anda, berdasarkan kasus penggunaan.

Untuk tinjauan umum tentang izin Android, lihat Izin dan Data Pengguna. Untuk praktik terbaik khusus mengenai penggunaan izin Android, lihat Praktik Terbaik untuk Izin Aplikasi.

Prinsip Penanganan Identifier Android

Kami menyarankan untuk mengikuti prinsip ini ketika menggunakan identifier Android:

#1: Hindari menggunakan identifier perangkat keras. Identifier perangkat keras seperti SSAID (Android ID) dan IMEI bisa dihindari pada banyak kasus penggunaan tanpa membatasi fungsionalitas yang diperlukan.

#2: Hanya gunakan ID Iklan untuk pembuatan profil pengguna atau kasus penggunaan periklanan. Saat menggunakan ID Iklan, selalu patuhi flag Limit Ad Tracking, pastikan identifier tidak bisa terhubung ke informasi identitas pribadi (PII) dan hindari menjembatani setel ulang ID Iklan.

#3: Gunakan Instance ID atau GUID pribadi yang tersimpan jika memungkinkan untuk semua kasus penggunaan lainnya kecuali pencegahan penipuan pembayaran dan telepon. Pada banyak kasus penggunaan non-periklanan, instance ID atau GUID seharusnya mencukupi.

#4: Gunakan API yang sesuai pada kasus penggunaan Anda untuk meminimalkan risiko privasi. Gunakan DRM API API untuk perlindungan materi berharga dan SafetyNet API untuk mencegah penyalahgunaan. Safetynet API adalah cara termudah untuk menentukan apakah perangkat tersebut asli tanpa menyebabkan risiko privasi.

Bagian lain dari panduan ini menguraikan aturan-aturan tersebut dalam konteks development aplikasi Android.

Identifier pada Android 6.0+

Alamat MAC adalah unik secara global, tidak dapat disetel ulang pengguna dan bisa bertahan dari setel ulang pabrik. Biasanya, tidak disarankan menggunakan alamat MAC untuk semua bentuk identifikasi pengguna. Hasilnya, seperti pada Android M, alamat MAC perangkat lokal (misalnya, Wifi dan Bluetooth) tidak tersedia melalui API pihak ketiga. Metode WifiInfo.getMacAddress() dan BluetoothAdapter.getDefaultAdapter().getAddress()akan mengembalikan 02:00:00:00:00:00..

Selain itu, Anda harus mempunyai izin berikut untuk mengakses alamat MAC dari perangkat eksternal terdekat yang terlihat melalui pemindaian Bluetooth dan WiFi:

Metode/Properti Izin yang Diperlukan
WifiManager.getScanResults() ACCESS_FINE_LOCATION atau ACCESS_COARSE_LOCATION
BluetoothDevice.ACTION_FOUND ACCESS_FINE_LOCATION atau ACCESS_COARSE_LOCATION
BluetoothLeScanner.startScan(ScanCallback) ACCESS_FINE_LOCATION atau ACCESS_COARSE_LOCATION

Bekerja dengan ID Iklan

ID Iklan adalah identifier yang bisa disetel ulang pengguna dan cocok untuk kasus penggunaan Periklanan, namun ada beberapa poin penting yang harus diperhatikan saat menggunakannya:

Selalu hormati niat pengguna saat menyetel ulang ID iklan. Jangan menjembatani setel ulang pengguna dengan menggunakan identifier perangkat yang persisten atau sidik jari untuk menautkan ID iklan berikutnya secara bersama tanpa persetujuan pengguna. Kebijakan Konten Developer Google Play menyatakan:

...jika setel ulang, identifier iklan yang baru harus dihubungkan ke identifier iklan sebelumnya atau data yang berasal dari identifier iklan sebelumnya tanpa persetujuan eksplisit dari pengguna.

Selalu perhatikan flag Personalisasi Periklanan yang berhubungan. ID iklan bisa dikonfigurasi sehingga pengguna dapat membatasi jumlah pelacakan yang terkait dengan ID. Selalu gunakan metode AdvertisingIdClient.Info.isLimitAdTrackingEnabled() untuk memastikan bahwa Anda tidak melawan keinginan pengguna. Kebijakan Konten Developer Google Play menyatakan:

...Anda harus mematuhi setelan pengguna ‘Opt out of interest-based advertising’ atau 'Opt out of Ads Personalization'. Jika pengguna sudah mengaktifkan setelan ini, Anda tidak bisa menggunakan identifier iklan guna membuat profil pengguna untuk kepentingan iklan atau untuk menargetkan pengguna dengan iklan terpersonalisasi. Aktivitas yang diizinkan termasuk periklanan kontekstual, pembatasan frekuensi, pelacakan konversi, pelaporan dan keamanan serta deteksi penipuan.

Waspadalah terhadap segala kebijakan keamanan atau privasi yang terkait dengan SDK yang Anda gunakan yang terkait dengan penggunaan ID iklan. Misalnya, jika Anda menggunakan metode Google Analytics SDK mTracker.enableAdvertisingIdCollection(true), pastikan untuk memeriksa dan mematuhi semua kebijakan Analytics SDK yang berlaku.

Juga, ketahuilah bahwa Kebijakan Konten Developer Google Play mengharuskan bahwa ID iklan "tidak boleh terhubung ke informasi identitas pribadi atau terkait dengan identifier perangkat yang persisten (misalnya: SSAID, alamat MAC, IMEI, dll.,) tanpa persetujuan eksplisit dari pengguna.”

Misalnya, anggap saja Anda ingin mengumpulkan informasi untuk mengisi tabel database dengan kolom berikut:

timestamp ad_id account_id clickid

TABEL-01

account_id name dob country

TABEL-02

Dalam contoh ini, kolom ad_id bisa digabungkan ke PII melalui kolom account_id dalam kedua tabel, yang melanggar Kebijakan Konten Developer Google Play, jika Anda tidak mendapat izin secara eksplisit dari pengguna.

Perlu diingat bahwa tautan antara ID Iklan dan PII tidak selalu eksplisit. Dimungkinkan untuk memiliki “identifier-semu” yang terlihat pada PII dan tabel terkunci ID iklan, yang bisa menyebabkan masalah. Misalnya, anggap saja kita mengubah TABEL-01 dan TABEL-02 seperti berikut:

timestamp ad_id clickid dev_model

TABEL-01

timestamp demo account_id dev_model name

TABEL-02

Pada kasus ini, dengan kejadian klik yang cukup jarang, masih mungkin untuk menggabungkan antara TABEL-01 ID Pengiklan dan PII yang ada dalam TABEL-2 menggunakan stempel waktu dari kejadian dan model perangkat.

Meskipun sering kali sulit untuk menjamin bahwa tidak ada identifier-semu dalam kumpulan data, risiko penggabungan paling kentara bisa dicegah dengan menggeneralisasi data yang unik bila memungkinkan. Dalam contoh ini, ini berarti mengurangi akurasi stempel waktu sehingga beberapa perangkat dengan model yang sama tampak untuk setiap stempel waktu.

Solusi lainnya mencakup:

Untuk informasi selengkapnya mengenai bekerja dengan ID Iklan secara bertanggung jawab, lihat artikel pusat bantuan ID Iklan.

Bekerja dengan Instance ID dan GUID

Solusi termudah untuk mengidentifikasi instance aplikasi yang dijalankan pada perangkat adalah dengan menggunakan Instance ID, dan ini merupakan solusi yang disarankan pada kebanyakan kasus penggunaan non-periklanan. Hanya instance aplikasi yang telah ditetapkan yang bisa mengakses identifier, dan itu (relatif) mudah untuk disetel ulang karena hanya bertahan selama aplikasi dipasang.

Hasilnya, Instance ID menyediakan properti privasi yang lebih baik dibandingkan dengan ID perangkat keras tercakup-perangkat yang tidak dapat disetel ulang. Mereka juga dilengkapi dengan sepasang tombol untuk menandatangani pesan (dan tindakan serupa) dan tersedia pada Android, iOS dan Chrome. Lihat dokumen pusat bantuan Apa yang dimaksud dengan Instance ID? untuk informasi selengkapnya.

Pada kejadian ketika Instance ID kurang praktis, globally unique ID (GUID) juga bisa digunakan untuk mengidentifikasi instance aplikasi secara unik. Cara termudah untuk melakukannya adalah dengan membuat GUID Anda sendiri dengan menggunakan kode berikut.

String uniqueID = UUID.randomUUID().toString();

Karena identifier adalah unik secara global, itu bisa digunakan untuk mengidentifikasi instance aplikasi tertentu. Untuk menghindari masalah yang terkait dengan menautkan identifier ke seluruh aplikasi, GUID harus disimpan dalam storage internal bukannya storage (bersama) eksternal. Lihat panduan Opsi Storage untuk informasi selengkapnya.

Memahami Karakteristik Identifier

Sistem Operasi Android menawarkan sejumlah ID dengan karakteristik perilaku yang berbeda dan ID yang harus Anda gunakan bergantung pada bagaimana karakteristik yang mengikutinya bekerja dengan kasus penggunaan Anda: Namun karakteristik itu juga datang dengan dampak privasi, jadi penting untuk memahami bagaimana karakteristik ini ketika bekerja bersama.

Cakupan

Cakupan identifier menjelaskan sistem mana yang bisa mengakses identifier. Cakupan identifier Android biasanya dibagi menjadi tiga kategori:

Semakin luas cakupan yang diberikan kepada sebuah identifier, semakin besar risiko untuk digunakan guna tujuan pelacakan. Sebaliknya, jika identifier hanya bisa diakses oleh instance satu aplikasi, itu tidak dapat digunakan untuk melacak perangkat di seluruh transaksi dalam aplikasi yang berbeda.

Kemampuan Setel Ulang dan ketahanan

Kemampuan setel ulang dan ketahanan mendefinisikan masa aktif identifier dan menjelaskan cara identifier bisa disetel ulang. Pemicu setel ulang biasanya adalah: setel ulang dalam-aplikasi, setel ulang melalui System Settings, setel ulang saat peluncuran, dan setel ulang saat pemasangan. Identifier Android bisa memiliki bermacam-macam masa aktif, namun masa aktif tersebut biasanya terkait dengan cara ID disetel ulang:

Kemampuan setel ulang membuat pengguna bisa membuat ID baru yang terpisah dari semua informasi profil yang ada. Ini penting karena semakin lama, dan semakin andal sebuah identifier bisa bertahan (mis. saat di setel ulang pabrik dll.), semakin besar risiko pengguna mengalami pelacakan jangka panjang. Jika identifier disetel ulang saat pemasangan ulang aplikasi, ini mengurangi ketahanan dan menyediakan sebuah cara agar ID bisa disetel ulang, bahkan jika tidak terdapat kontrol pengguna eksplisit untuk menyetel ulang dari dalam aplikasi atau Setelan Sistem.

Keunikan

Keunikan membentuk kecenderungan bahwa identifier yang identik ada dalam cakupan yang berkaitan. Pada tingkat yang paling tinggi, identifier yang unik secara global tidak akan berbenturan - meskipun pada perangkat/aplikasi lain. Jika tidak, tingkat keunikan bergantung pada ukuran identifier dan sumber acak yang digunakan untuk membuatnya. Misalnya, kemungkinan tabrakan jauh lebih tinggi untuk identifier acak yang ditambahkan tanggal kalender pemasangan (mis., 2015-01-05) dibandingkan identifier yang ditambahkan stempel waktu Unix dari pemasangan (mis., 1445530977).

Secara umum, identifier akun pengguna bisa dianggap unik (misalnya, setiap pasangan perangkat/akun memiliki ID unik). Di sisi lain, semakin tidak unik sebuah identifier dalam populasi (mis., perangkat), semakin besar pula perlindungan privasi karena kurang berguna untuk melacak pengguna individu.

Perlindungan integritas dan non-repudiability

Identifier yang sulit untuk dipalsukan atau digunakan ulang bisa digunakan untuk membuktikan bahwa perangkat atau akun yang terkait memiliki properti tertentu (mis. itu bukan perangkat virtual yang digunakan oleh spammer). Kesulitan saat memalsukan identifier juga memberikan non-repudiability. Jika perangkat menandatangani pesan dengan kunci rahasia, akan sulit untuk mengklaim bahwa perangkat orang lain yang mengirim pesan tersebut. Non-repudiability bisa menjadi sesuatu yang diinginkan pengguna (mis., mengesahkan pembayaran) atau bisa saja properti yang tidak diinginkan (mis., mengirim pesan yang mereka sesali).

Kasus Penggunaan Umum dan Identifier yang Digunakan

Bagian ini menyediakan alternatif penggunaan ID perangkat keras seperti IMEI atau SSAID pada kebanyakan kasus penggunaan. Bergantung pada ID perangkat keras tidak dianjurkan karena pengguna tidak bisa menyetel ulang dan secara umum membatasi kontrol pada koleksi mereka.

Melacak preferensi pengguna yang keluar

Dalam kasus ini, Anda menyimpan status tiap perangkat pada server.

Kami Menyarankan: Instance ID atau GUID.

Mengapa ini Disarankan?

Informasi yang tetap bertahan bahkan saat aplikasi dipasang ulang tidak disarankan karena pengguna mungkin ingin menyetel ulang preferensi mereka dengan memasang ulang aplikasi.

Melacak perilaku pengguna yang keluar

Dalam kasus ini, Anda sudah membuat profil pengguna berdasarkan perilakunya di seluruh aplikasi/sesi yang berbeda pada perangkat yang sama.

Kami Menyarankan: ID Iklan.

Mengapa ini Disarankan?

Penggunaan ID Iklan adalah hal wajib untuk kasus penggunaan Periklanan pada Kebijakan Konten Developer Google Play karena pengguna bisa menyetel ulang.

Membuat analitik pengguna yang keluar/anonim

Dalam hal ini, Anda mengukur statistik penggunaan dan analitik untuk pengguna yang keluar atau anonim.

Kami Menyarankan: Instance ID; jika Instance ID tidak mencukupi, Anda juga bisa menggunakan GUID.

Mengapa ini Disarankan?

Instance ID atau GUID mempunyai cakupan pada aplikasi yang membuatnya, yang mencegahnya dari digunakan untuk melacak pengguna di seluruh aplikasi. Itu juga mudah disetel ulang dengan menghapus data aplikasi atau memasang ulang aplikasi. Sangatlah mudah untuk membuat Instance ID dan GUID:

Ketahuilah bahwa jika Anda sudah memberi tahu pengguna bahwa data yang Anda kumpulkan adalah anonim, Anda harus memastikan Anda tidak menghubungkan identifier ke PII atau identifier lain yang mungkin ditautkan ke PII.

Anda juga bisa menggunakan Google Analytics untuk Aplikasi Seluler, yang menawarkan solusi untuk analitik per-aplikasi.

Melacak konversi pengguna yang keluar

Dalam kasus ini, Anda melacak konversi untuk mendeteksi apakah strategi pemasaran berhasil.

Kami Menyarankan: ID Iklan.

Mengapa ini Disarankan?

Ini adalah kasus penggunaan yang terkait dengan periklanan yang mungkin membutuhkan ID yang tersedia di banyak aplikasi yang berbeda sehingga penggunaan ID Iklan adalah solusi yang paling tepat.

Menangani beberapa pemasangan

Dalam kasus ini, Anda harus mengidentifikasi instance aplikasi yang benar ketika dipasang pada beberapa perangkat untuk pengguna yang sama.

Kami Menyarankan: Instance ID atau GUID.

Mengapa ini Disarankan?

Instance ID didesain secara eksplisit untuk tujuan ini; cakupannya terbatas pada aplikasi sehingga tidak bisa digunakan untuk melacak pengguna di seluruh aplikasi yang berbeda dan itu disetel ulang ketika aplikasi dipasang ulang. Pada kasus yang jarang terjadi ketika Instance ID tidak mencukupi, Anda juga bisa menggunakan GUID.

Pencegahan Penipuan: Membatasi materi gratis / mendeteksi serangan Sybil

Dalam kasus ini, Anda ingin membatasi jumlah materi gratis (mis. artikel) yang bisa dilihat pengguna pada perangkat.

Kami Menyarankan: Instance ID atau GUID.

Mengapa ini Disarankan?

Menggunakan GUID atau Instance ID memaksa pengguna memasang kembali aplikasi agar dapat mengatasi batasan materi, yang merupakan penghalang yang cukup besar untuk banyak orang. Jika perlindungan ini tidak mencukupi, Android menyediakan DRM API yang bisa digunakan untuk membatasi akses ke materi.

Mengelola fungsionalitas operator dan telepon

Dalam kasus ini, aplikasi Anda berinteraksi dengan fungsionalitas telepon dan perpesanan perangkat.

Kami Menyarankan: IMEI, IMSI, dan Line1 (membutuhkan grup izin PHONE di Android 6.0 (API level 23) dan yang lebih tinggi).

Mengapa ini Disarankan?

Memanfaatkan identifier perangkat keras bisa diterima jika itu dibutuhkan untuk fungsionalitas telepon/operator; misalnya, beralih antara operator seluler/slot SIM atau mengirim pesan SMS melalui IP (untuk Line1) - akun pengguna berbasis-SIM. Namun perlu diperhatikan bahwa pada Android 6.0+ identifier ini hanya bisa digunakan melalui izin waktu proses dan pengguna dapat mematikan izin ini sehingga aplikasi Anda bisa menangani pengecualian ini dengan baik.

Mendeteksi penyalahgunaan: Mengidentifikasi serangan DDoS dan bots

Dalam kasus ini, Anda mencoba untuk mendeteksi beberapa perangkat palsu yang menyerang layanan backend.

Kami Menyarankan: Safetynet API.

Mengapa ini Disarankan?

Identifier yang terisolasi hanya sedikit membantu untuk menunjukkan bahwa sebuah perangkat adalah asli. Anda bisa memverifikasi bahwa permintaan datang dari perangkat Android asli (bukannya sebuah emulator atau spoofing kode perangkat lain) menggunakan metode SafetyNet.SafetyNetApi.attest(mGoogleApiClient, nonce) Safetynet API untuk memverifikasi integritas perangkat yang membuat permintaan. Untuk informasi lebih detail, lihat dokumentasi Safetynet API.

Mendeteksi penyalahgunaan: Mendeteksi kredensial berharga yang dicuri

Dalam kasus ini, Anda mencoba mendeteksi satu perangkat yang digunakan beberapa kali dengan kredensial berharga, yang dicuri (mis. untuk melakukan kecurangan pembayaran).

Kami Menyarankan: IMEI/IMSI (membutuhkan grup izin PHONE pada Android 6.0 (API level 23) dan yang lebih tinggi.)

Mengapa ini Disarankan?

Dengan kredensial yang dicuri, perangkat bisa digunakan untuk memonetisasi beberapa kredensial berharga yang dicuri (seperti token kartu kredit). Dalam skenario ini, ID perangkat lunak bisa disetel ulang untuk menghindari deteksi, sehingga identifier perangkat keras dapat digunakan.

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Ikuti Google Developers di WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience. (Dec 2017 Android Platform & Tools Survey)