Android 5.1 memperkenalkan mekanisme untuk memberikan hak istimewa khusus bagi API relevan dengan pemilik aplikasi {i>Universal integrated circuit card<i} (UICC). Tujuan Platform Android memuat sertifikat yang disimpan di UICC dan memberikan izin untuk aplikasi yang ditandatangani oleh sertifikat ini untuk melakukan panggilan ke beberapa API khusus.
Android 7.0 memperluas fitur ini guna mendukung sumber penyimpanan lainnya untuk UICC aturan hak istimewa operator secara drastis meningkatkan jumlah ekspedisi yang dapat menggunakan API. Untuk referensi API, lihat CarrierConfigManager; untuk mendapatkan petunjuk, lihat Operator Konfigurasi.
Operator memiliki kontrol penuh atas UICC, jadi mekanisme ini menyediakan cara yang aman dan fleksibel untuk mengelola aplikasi dari operator jaringan seluler (MNO) dihosting di saluran distribusi aplikasi generik (seperti Google Play) sekaligus mempertahankan hak istimewa khusus di perangkat dan tanpa perlu menandatangani aplikasi dengan sertifikat platform per perangkat atau melakukan prainstal sebagai aplikasi sistem.
Aturan di UICC
Penyimpanan di UICC kompatibel dengan
GlobalPlatform
Spesifikasi Kontrol Akses Elemen Pengaman. ID aplikasi
(AID) pada kartu adalah A00000015141434C00
, dan standar
GET DATA
digunakan untuk mengambil aturan yang disimpan di kartu. Anda dapat memperbarui aturan ini
melalui pembaruan {i>card over the air<i} (OTA).
Hierarki data
Aturan UICC menggunakan hierarki data berikut (huruf dua karakter dan
kombinasi angka dalam tanda kurung
adalah tag objek). Setiap aturan
REF-AR-DO
(E2
) dan terdiri dari rangkaian
REF-DO
dan AR-DO
:
REF-DO
(E1
) berisiDeviceAppID-REF-DO
atau penyambunganDeviceAppID-REF-DO
danPKG-REF-DO
.DeviceAppID-REF-DO
(C1
) menyimpan SHA-1 (20 byte) atau SHA-256 (32 byte) tanda tangan sertifikat.PKG-REF-DO
(CA
) adalah nama paket lengkap didefinisikan dalam manifes, berenkode ASCII, panjang maksimal 127 byte.
AR-DO
(E3
) diperpanjang untuk menyertakanPERM-AR-DO
(DB
), yaitu bit 8 byte mask yang mewakili 64 izin terpisah.
Jika PKG-REF-DO
tidak ada, aplikasi apa pun yang ditandatangani oleh sertifikat
diberi akses; jika tidak, sertifikat dan
nama paket harus
yang cocok.
Contoh aturan
Nama aplikasinya adalah com.google.android.apps.myapp
dan
Sertifikat SHA-1 dalam string hex adalah:
AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4
Aturan pada UICC dalam string hex adalah:
E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070 E30A DB08 0000000000000001
Dukungan file aturan akses
Android 7.0 menambahkan dukungan untuk membaca aturan hak istimewa operator dari akses tersebut aturan file (ARF).
Platform Android mencoba memilih aplikasi aturan akses terlebih dahulu
(ARA) AID A00000015141434C00
. Jika tidak menemukan
AID di UICC, AID akan kembali ke ARF dengan memilih PKCS15 AID
A000000063504B43532D3135
. Android kemudian membaca
access control rules file (ACRF) di 0x4300
dan mencari entri
dengan AID FFFFFFFFFFFF
. Entri dengan AID yang berbeda akan diabaikan, jadi
aturan untuk kasus penggunaan lain
dapat beroperasi berdampingan.
Contoh konten ACRF dalam string hex:
30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10
Contoh konten file kondisi kontrol akses (ACCF):
30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81
Pada contoh di atas, 0x4310
adalah alamat untuk ACCF, yang
berisi hash sertifikat
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
. Aplikasi
yang ditandatangani oleh sertifikat ini
diberi hak istimewa operator.
API yang diaktifkan
Android mendukung API berikut.
Pengelola Telepon
- Metode untuk memungkinkan aplikasi operator meminta verifikasi login/respons pada UICC:
getIccAuthentication
. - Metode untuk memeriksa apakah aplikasi panggilan telah diberikan operator
hak istimewa:
hasCarrierPrivileges
. - Metode untuk mengganti merek dan angka:
- Metode untuk komunikasi UICC langsung:
- Metode untuk menetapkan mode perangkat ke global:
setPreferredNetworkTypeToGlobal
. - Metode untuk mendapatkan identitas perangkat atau jaringan:
- Identitas Peralatan Seluler Internasional (IMEI):
getImei
- Pengidentifikasi Peralatan Seluler (MEID):
getMeid
- {i>Network Access Identifier <i}(NAI):
getNai
- Nomor seri SIM:
getSimSerialNumber
- Identitas Peralatan Seluler Internasional (IMEI):
- Metode untuk mendapatkan konfigurasi operator:
getCarrierConfig
- Metode untuk mendapatkan jenis jaringan bagi transmisi data:
getDataNetworkType
- Metode untuk mendapatkan jenis jaringan bagi layanan suara:
getVoiceNetworkType
- Metode untuk mendapatkan informasi tentang aplikasi SIM UICC (USIM):
- Nomor seri SIM:
getSimSerialNumber
- Informasi kartu:
getUiccCardsInfo
- GID1 (ID grup level1):
getGroupIdLevel1
- String nomor telepon untuk baris 1:
getLine1Number
- Jaringan seluler tanah publik yang dilarang (PLMN):
getForbiddenPlmns
- PLMN rumah yang setara:
getEquivalentHomePlmns
- Nomor seri SIM:
- Metode untuk mendapatkan atau menetapkan nomor pesan suara:
- Metode untuk mengirim kode telepon khusus:
sendDialerSpecialCode
- Metode untuk mereset modem radio:
rebootModem
- Metode untuk mendapatkan atau menetapkan mode pemilihan jaringan:
- Metode untuk meminta pemindaian jaringan:
requestNetworkScan
- Metode untuk mendapatkan atau menetapkan jenis jaringan yang diizinkan/dipilih:
- Metode untuk memeriksa apakah data seluler atau roaming diaktifkan sesuai setelan pengguna:
- Metode untuk memeriksa atau menetapkan koneksi data dengan alasan:
- Metode untuk mendapatkan daftar nomor darurat:
getEmergencyNumberList
- Metode untuk mengontrol jaringan oportunistik:
- Metode untuk menetapkan atau menghapus permintaan pembaruan kekuatan sinyal seluler:
TeleponCallback
TelephonyCallback
memiliki antarmuka dengan metode callback untuk
memberi tahu aplikasi panggilan saat status yang terdaftar berubah:
- Indikator waktu tunggu pesan berubah:
onMessageWaitingIndicatorChanged
- Indikator penerusan panggilan berubah:
onCallForwardingIndicatorChanged
- Penyebab pemutusan panggilan sistem multimedia IP (IMS) berubah:
onImsCallDisconnectCauseChanged
- Status koneksi data yang tepat berubah:
onPreciseDataConnectionStateChanged
- Daftar nomor darurat saat ini telah diubah:
onEmergencyNumberListChanged
- ID langganan data aktif telah diubah:
onActiveDataSubscriptionIdChanged
- Jaringan operator berubah:
onCarrierNetworkChange
- Pendaftaran jaringan atau pembaruan lokasi/perutean/area pelacakan
gagal:
onRegistrationFailed
- Perubahan informasi pemblokiran:
onBarringInfoChanged
- Konfigurasi saluran fisik saat ini berubah:
onPhysicalChannelConfigChanged
SubscriptionManager
- Metode untuk mendapatkan berbagai informasi langganan:
- Metode untuk mendapatkan jumlah langganan aktif:
getActiveSubscriptionInfoCount
- Metode untuk mengelola grup langganan:
- Metode untuk mendapatkan atau menetapkan deskripsi paket hubungan penagihan antara operator dan pelanggan tertentu:
- Metode untuk mengganti sementara rencana hubungan penagihan antara
operator dan pelanggan tertentu akan dianggap tidak berbayar:
setSubscriptionOverrideUnmetered
- Metode untuk mengganti sementara rencana hubungan penagihan antara
operator dan pelanggan tertentu akan dianggap padat:
setSubscriptionOverrideCongested
- Metode untuk memeriksa apakah aplikasi dengan konteks yang diberikan
yang berwenang untuk mengelola langganan tertentu sesuai dengan metadatanya:
canManageSubscription
PengelolaSms
- Metode untuk mengizinkan penelepon membuat pesan SMS masuk baru:
injectSmsPdu
. - Metode untuk mengirim pesan SMS berbasis teks tanpa menulis ke SMS
cloud Anda:
sendTextMessageWithoutPersisting
OperatorConfigManager
- Metode untuk memberi tahu konfigurasi diubah:
notifyConfigChangedForSubId
. - Metode guna mendapatkan konfigurasi operator untuk langganan default:
getConfig
- Metode agar mendapatkan konfigurasi operator untuk langganan yang ditentukan:
getConfigForSubId
Untuk mengetahui petunjuknya, lihat Konfigurasi Operator.
Pengelola Laporan Bug
Metode untuk memulai laporan bug konektivitas, yang merupakan versi khusus dari
laporan bug yang hanya menyertakan informasi untuk proses debug terkait konektivitas
masalah:
startConnectivityBugreport
{i>NetworkStatsManager<i}
- Metode untuk mengkueri ringkasan penggunaan jaringan:
querySummary
- Metode untuk mengkueri histori penggunaan jaringan:
queryDetails
- Metode untuk mendaftarkan atau membatalkan pendaftaran callback penggunaan jaringan:
ImsMmTelManager
- Metode untuk mendaftarkan atau membatalkan pendaftaran callback pendaftaran IMS MmTel:
Manajer ImsRcs
- Metode untuk mendaftarkan atau membatalkan pendaftaran callback pendaftaran RCS IMS:
- Metode untuk mendapatkan status pendaftaran IMS atau jenis transpor:
Pengelola Penyediaan
- Metode untuk mendaftarkan dan membatalkan pendaftaran update penyediaan fitur IMS telepon balik:
- Metode yang terkait dengan status penyediaan untuk kemampuan IMS MmTel atau RCS:
Pengelola Euicc
Metode untuk beralih ke (mengaktifkan) langganan tertentu:
switchToSubscription
CarrierMessagingService
Layanan yang menerima panggilan dari sistem saat SMS dan MMS baru dikirim atau
diterima. Untuk memperluas class ini, deklarasikan layanan dalam file manifes Anda dengan
android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE
izin dan menyertakan filter intent dengan #SERVICE_INTERFACE
tindakan. Metodenya meliputi:
- Metode untuk memfilter pesan SMS masuk:
onFilterSms
- Metode untuk menangkap pesan SMS teks yang dikirim dari perangkat:
onSendTextSms
- Metode untuk menangkap pesan SMS biner yang dikirim dari perangkat:
onSendDataSms
- Metode untuk mencegat pesan SMS panjang yang dikirim dari perangkat:
onSendMultipartTextSms
- Metode untuk mencegat pesan MMS yang dikirim dari perangkat:
onSendMms
- Metode untuk mendownload pesan MMS yang diterima:
onDownloadMms
LayananJasa Ekspedisi
Layanan yang mengekspos fungsi khusus operator ke sistem. Kepada
memperluas class ini, deklarasikan layanan dalam file manifes aplikasi dengan
android.Manifest.permission#BIND_CARRIER_SERVICES
dan
menyertakan filter intent dengan tindakan CARRIER_SERVICE_INTERFACE
.
Jika layanan memiliki binding berumur panjang, setel
android.service.carrier.LONG_LIVED_BINDING
hingga
true
dalam metadata layanan.
Platform mengikat CarrierService
dengan flag khusus agar
proses layanan ekspedisi yang berjalan dalam
bucket aplikasi standby. Tindakan ini mengecualikan aplikasi layanan operator dari
pembatasan aplikasi tidak ada aktivitas dan membuatnya lebih mungkin untuk tetap aktif saat perangkat
memori hampir penuh. Namun, jika aplikasi layanan {i>operator <i}
error karena alasan apa pun,
semua hak istimewa di atas akan hilang hingga aplikasi dimulai ulang dan binding
dibangun kembali. Jadi, sangat penting untuk menjaga kestabilan
aplikasi layanan operator.
Metode di CarrierService
meliputi:
- Untuk mengganti dan menetapkan konfigurasi khusus operator:
onLoadConfig
- Untuk memberi tahu sistem tentang perubahan jaringan operator mendatang yang disengaja dengan
aplikasi operator:
notifyCarrierNetworkChange
Penyedia layanan telepon
API penyedia konten untuk mengizinkan modifikasi (menyisipkan, menghapus, memperbarui, kueri)
ke database telepon. {i>Value field<i} ditentukan di
Telephony.Carriers
; untuk detail selengkapnya, lihat
referensi class Telephony
SaranJaringan Wifi
Saat membuat objek WifiNetworkSuggestion
, gunakan metode berikut
metode untuk menetapkan ID langganan atau grup langganan:
- Metode untuk menetapkan ID langganan:
setSubscriptionId
- Cara untuk menyetel grup langganan:
setSubscriptionGroup
Platform Android
Pada UICC yang terdeteksi, platform membuat objek UICC internal yang
menyertakan aturan hak istimewa operator
sebagai bagian dari UICC.
UiccCarrierPrivilegeRules.java
memuat aturan, mengurainya dari kartu UICC, dan meng-cache-nya di memori. Kapan
diperlukan pemeriksaan hak istimewa, UiccCarrierPrivilegeRules
membandingkan
sertifikat pemanggil dengan aturannya sendiri satu per satu. Jika UICC dihapus,
aturan dihancurkan bersama dengan objek UICC.
Validasi
Untuk memvalidasi penerapan melalui
Compatibility Test Suite (CTS) menggunakan CtsCarrierApiTestCases.apk
,
Anda harus memiliki UICC developer dengan
aturan UICC atau dukungan ARF yang benar.
Minta vendor kartu SIM pilihan Anda untuk menyiapkan UICC developer dengan
ARF yang tepat seperti yang dijelaskan di bagian ini dan menggunakan UICC tersebut untuk menjalankan pengujian. Tujuan
UICC tidak memerlukan layanan seluler aktif untuk lulus uji CTS.
Menyiapkan UICC
Untuk Android 11 dan yang lebih lama, CtsCarrierApiTestCases.apk
adalah
ditandatangani oleh aosp-testkey
, dengan nilai hash
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
.
Mulai Android 12, CtsCarrierApiTestCases.apk
telah
ditandatangani oleh
cts-uicc-2021-testkey
, nilai hash
CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
.
Untuk menjalankan pengujian API operator CTS di Android 12, perangkat harus menggunakan SIM dengan operator CTS hak istimewa yang memenuhi persyaratan yang ditetapkan dalam versi terbaru pihak ketiga Spesifikasi Profil Pengujian GSMA TS.48.
SIM yang sama juga dapat digunakan untuk versi sebelum Android 12.
Mengubah profil SIM CTS
- Tambahkan: Hak istimewa operator CTS di
{i>access rule app master<i} (ARA-M) atau ARF. Kedua tanda tangan harus
yang dienkode dalam aturan hak istimewa operator:
- {i>Hash1<i} (SHA1):
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
- Hash2(SHA256):
CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
- {i>Hash1<i} (SHA1):
- Membuat: File dasar (EF) ADF USIM tidak ada di
TS.48 dan diperlukan untuk CTS:
- EF_MBDN (6FC7), ukuran catatan: 28, nomor catatan: 4
- Isi
- Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF...FF
- Rec2-n: FF...FF
- Isi
- EF_EXT6 (6FC8), ukuran catatan:13, catatan nomor: 1
- Konten: 00FF...FF
- EF_MBI (6FC9), ukuran catatan: 4, catatan nomor: 1
- Konten: Rec1: 01010101
- EF_MWIS (6FCA), ukuran catatan: 5, nomor catatan: 1
- Konten: 0000000000
- Konten: 00FF...FF
- EF_MBDN (6FC7), ukuran catatan: 28, nomor catatan: 4
- Ubah: Tabel layanan USIM: Aktifkan layanan n°47, n°48
- EF_UST (6F38)
- Konten:
9EFFBF1DFFFE0083410310010400406E01
- Konten:
- EF_UST (6F38)
- Ubah: File DF-5GS dan DF-SAIP
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Konten:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Konten:
- DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
- Konten:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Konten:
- DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
- Konten:
A0020000FF…FF
- Konten:
- DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
- Konten:
A0020000FF…FF
- Konten:
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Ubah: Gunakan string nama operator Android CTS
di masing-masing EF yang berisi pengelompokan ini:
- EF_SPN (USIM/6F46)
- Konten:
01416E64726F696420435453FF..FF
- Konten:
- EF_PNN (USIM/6FC5)
- Konten:
Rec1 430B83413759FE4E934143EA14FF..FF
- Konten:
- EF_SPN (USIM/6F46)
Cocokkan dengan struktur profil pengujian
Download dan cocokkan versi terbaru dari struktur profil pengujian umum berikut. Profil ini tidak akan memiliki aturan Hak Istimewa Operator CTS yang dipersonalisasi atau modifikasi lainnya yang tercantum di atas.
Menjalankan pengujian
Untuk memudahkan, CTS mendukung token perangkat yang membatasi
pengujian untuk dijalankan hanya pada perangkat
yang dikonfigurasi dengan token yang sama. CTS API Operator
pengujian mendukung token perangkat sim-card-with-certs
. Misalnya,
token perangkat berikut membatasi pengujian API operator untuk hanya berjalan di perangkat
abcd1234
:
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
Saat menjalankan pengujian tanpa menggunakan token perangkat, pengujian akan berjalan pada semua perangkat.
FAQ
Bagaimana cara memperbarui sertifikat di UICC?
A: Menggunakan mekanisme update OTA kartu yang sudah ada.
Dapatkah UICC berdampingan dengan aturan lain?
A: Tidak masalah jika Anda memiliki aturan keamanan lain di UICC dengan AID yang sama; platform akan memfilternya secara otomatis.
Yang terjadi jika UICC dihapus untuk aplikasi yang mengandalkan sertifikatnya?
A: Aplikasi kehilangan hak istimewanya karena aturan yang terkait dengan UICC dihancurkan saat penghapusan UICC.
Apakah ada batas jumlah sertifikat di UICC?
A: Platform tidak membatasi jumlah sertifikat; tapi karena bersifat linear, terlalu banyak aturan dapat menimbulkan latensi untuk pemeriksaan.
Apakah ada batas jumlah API yang dapat kita dukung dengan metode?
J: Tidak, tetapi kami membatasi cakupannya hanya untuk API terkait operator.
Apakah ada beberapa API yang dilarang menggunakan metode ini? Jika demikian, bagaimana Anda menerapkannya? (yaitu, apakah Anda memiliki pengujian untuk memvalidasi API mana yang didukung dengan metode ini?)
A: Melihat Bagian Kompatibilitas Perilaku API di Kompatibilitas Android Definition Document (CDD). Kami memiliki beberapa tes CTS untuk memastikan bahwa model izin API tidak berubah.
Bagaimana cara kerjanya dengan fitur multi-SIM?
A: SIM default yang ditentukan oleh pengguna digunakan.
Apakah perilaku ini berinteraksi atau tumpang tindih dengan akses SE lain teknologi baru, misalnya SEEK?
A: Sebagai contoh, SEEK menggunakan AID yang sama seperti di UICC. Jadi aturan
berdampingan dan difilter menurut SEEK atau
UiccCarrierPrivileges
.
Kapan waktu yang tepat untuk memeriksa hak istimewa operator?
A: Setelah status SIM dimuat.
Dapatkah OEM menonaktifkan sebagian API operator?
J: Tidak. Kami yakin bahwa API saat ini adalah set minimal, dan kami berencana menggunakan bit mask untuk kontrol perincian yang lebih baik di masa mendatang.
Apakah setOperatorBrandOverride
menggantikan SEMUA formulir lainnya
operator
menamai {i>string<i}? Misalnya, SE13, UICC SPN, atau NITZ berbasis jaringan?
Ya, penggantian merek operator memiliki prioritas tertinggi. Jika disetel, nilai ini akan menggantikan SEMUA bentuk lain string nama operator.
Apa fungsi panggilan metode injectSmsPdu
?
A: Metode ini memfasilitasi pencadangan/pemulihan SMS di cloud. Tujuan
Panggilan injectSmsPdu
mengaktifkan fungsi pemulihan.
Untuk pemfilteran SMS, apakah panggilan onFilterSms
didasarkan pada
Pemfilteran port UDH SMS? Atau, apakah aplikasi operator memiliki akses ke SEMUA SMS masuk?
J: Operator memiliki akses ke semua data SMS.
Ekstensi DeviceAppID-REF-DO
untuk mendukung
32 byte menjadi
tidak kompatibel dengan spesifikasi GP saat ini (yang hanya memungkinkan 0 atau 20 byte), jadi mengapa
apakah Anda memperkenalkan perubahan ini? SHA-1 tidak cukup untuk
menghindari tabrakan? Apakah Anda sudah mengusulkan
perubahan ini ke GP, karena ini bisa
tidak kompatibel dengan ARA-M/ARF yang sudah ada?
A: Untuk memberikan keamanan yang siap menghadapi masa depan, ekstensi ini memperkenalkan SHA-256
untuk DeviceAppID-REF-DO
selain SHA-1, yang saat ini
satu-satunya pilihan di standar GP SEAC. Kami sangat merekomendasikan penggunaan SHA-256.
Jika DeviceAppID
adalah 0 (kosong), apakah Anda menerapkan aturan ke
semua aplikasi perangkat tidak tercakup dalam aturan tertentu?
J: API Operator mengharuskan DeviceAppID-REF-DO
diisi.
Kolom kosong dimaksudkan untuk tujuan pengujian dan tidak direkomendasikan untuk keperluan operasional
deployment.
Menurut spesifikasi Anda, PKG-REF-DO
hanya digunakan oleh
itu sendiri, tanpa DeviceAppID-REF-DO
, seharusnya tidak diterima. Tapi
masih dijelaskan dalam Tabel 6-4 tentang spesifikasi sebagai
definisi REF-DO
. Apakah ini disengaja? Bagaimana kode
berperilaku saat hanya PKG-REF-DO
yang digunakan di REF-DO
?
A: Opsi untuk menetapkan PKG-REF-DO
sebagai nilai tunggal
item di REF-DO
telah dihapus pada versi terbaru.
PKG-REF-DO
hanya boleh terjadi jika dikombinasikan dengan
DeviceAppID-REF-DO
.
Kami berasumsi bahwa kami dapat memberikan akses ke semua izin berbasis operator atau memiliki kontrol yang lebih terperinci. Jika demikian, apa yang mendefinisikan pemetaan antara bit mask dan izin akses yang sebenarnya? Satu izin per kelas? Satu izin per metode? Apakah 64 izin terpisah cukup untuk jangka panjang?
A: Pemberian izin ini ditujukan untuk masa mendatang, dan kami menantikan saran.
Dapatkah Anda menentukan DeviceAppID
untuk Android lebih lanjut
secara spesifik? Ini adalah nilai hash SHA-1 (20 byte) Penayang
sertifikat yang digunakan untuk menandatangani aplikasi yang diberikan, jadi tidak boleh nama tersebut mencerminkan
tujuan? (Nama tersebut dapat membingungkan banyak pembaca karena aturan ini
berlaku untuk semua aplikasi yang ditandatangani dengan sertifikat Penayang yang sama tersebut.)
A: DeviceAppID
yang menyimpan sertifikat didukung oleh
spesifikasi yang ada. Kami mencoba meminimalkan perubahan
spesifikasi untuk menurunkan hambatan bagi
diadopsi. Untuk mengetahui detailnya, lihat Aturan di UICC.