Android 5.1 wprowadził mechanizm nadawania specjalnych uprawnień dla interfejsów API odpowiednich dla właścicieli aplikacji Universal Integrated Circuit Card (UICC). Platforma Android ładuje certyfikaty przechowywane w UICC i zezwala aplikacjom podpisanym tymi certyfikatami na nawiązywanie połączeń z kilkoma specjalnymi interfejsami API.
Android 7.0 rozszerzył tę funkcję, aby obsługiwała inne źródła przechowywania dla reguł uprawnień przewoźników UICC, radykalnie zwiększając liczbę operatorów, którzy mogą korzystać z interfejsów API. Aby uzyskać informacje dotyczące interfejsu API, zobacz CarrierConfigManager ; instrukcje znajdziesz w części Konfiguracja operatora .
Operatorzy mają pełną kontrolę nad UICC, więc ten mechanizm zapewnia bezpieczny i elastyczny sposób zarządzania aplikacjami od operatora sieci komórkowej (MNO) hostowanymi w ogólnych kanałach dystrybucji aplikacji (takich jak Google Play) przy zachowaniu specjalnych uprawnień na urządzeniach i bez konieczności podpisywać aplikacje certyfikatem platformy dla poszczególnych urządzeń lub preinstalować jako aplikację systemową.
Regulamin UICC
Przechowywanie w UICC jest zgodne ze specyfikacją GlobalPlatform Secure Element Access Control . Identyfikator aplikacji (AID) na karcie to A00000015141434C00
, a standardowe polecenie GET DATA
służy do pobierania reguł zapisanych na karcie. Możesz zaktualizować te zasady za pomocą aktualizacji kart OTA.
Hierarchia danych
Reguły UICC wykorzystują następującą hierarchię danych (kombinacja dwuznakowej litery i cyfry w nawiasach to znacznik obiektu). Każda reguła to REF-AR-DO
( E2
) i składa się z konkatenacji REF-DO
i AR-DO
:
-
REF-DO
(E1
) zawieraDeviceAppID-REF-DO
lub konkatenacjęDeviceAppID-REF-DO
iPKG-REF-DO
.-
DeviceAppID-REF-DO
(C1
) przechowuje podpis SHA-1 (20 bajtów) lub SHA-256 (32 bajty) certyfikatu. -
PKG-REF-DO
(CA
) to pełna nazwa pakietu zdefiniowana w manifeście, zakodowana w formacie ASCII, o maksymalnej długości 127 bajtów.
-
-
AR-DO
(E3
) jest rozszerzony oPERM-AR-DO
(DB
), który jest 8-bajtową maską bitową reprezentującą 64 oddzielne uprawnienia.
Jeśli nie ma PKG-REF-DO
, każda aplikacja podpisana certyfikatem uzyskuje dostęp; w przeciwnym razie zarówno certyfikat, jak i nazwa pakietu muszą być zgodne.
Przykład reguły
Nazwa aplikacji to com.google.android.apps.myapp
, a certyfikat SHA-1 w postaci ciągu szesnastkowego to:
AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4
Reguła na UICC w łańcuchu szesnastkowym to:
E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070 E30A DB08 0000000000000001
Obsługa plików reguł dostępu
Android 7.0 dodaje obsługę odczytu reguł uprawnień operatora z pliku reguł dostępu (ARF).
Platforma Android najpierw próbuje wybrać aplikację reguły dostępu (ARA) AID A00000015141434C00
. Jeśli nie znajdzie AID w UICC, powraca do ARF, wybierając PKCS15 AID A000000063504B43532D3135
. Następnie Android odczytuje plik reguł kontroli dostępu (ACRF) pod adresem 0x4300
i szuka wpisów z AID FFFFFFFFFFFF
. Wpisy z różnymi AID są ignorowane, więc reguły dla innych przypadków użycia mogą współistnieć.
Przykładowa zawartość ACRF w ciągu szesnastkowym:
30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10
Przykładowa zawartość pliku warunków kontroli dostępu (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
W powyższym przykładzie 0x4310
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
. Aplikacje podpisane tym certyfikatem otrzymują uprawnienia operatora.
Włączone interfejsy API
Android obsługuje następujące interfejsy API.
Menedżer telefonii
- Metoda umożliwiająca aplikacji przewoźnika poproszenie UICC o wyzwanie/odpowiedź:
getIccAuthentication
. - Metoda sprawdzania, czy aplikacji wywołującej przyznano uprawnienia operatora:
hasCarrierPrivileges
. - Metody zastępowania marki i numeru:
- Metody bezpośredniej komunikacji UICC:
- Metoda ustawienia trybu urządzenia na globalny:
setPreferredNetworkTypeToGlobal
. - Metody uzyskiwania tożsamości urządzenia lub sieci:
- Międzynarodowy identyfikator urządzenia mobilnego (IMEI):
getImei
- Identyfikator sprzętu mobilnego (MEID):
getMeid
- Identyfikator dostępu do sieci (NAI):
getNai
- Numer seryjny karty SIM:
getSimSerialNumber
- Międzynarodowy identyfikator urządzenia mobilnego (IMEI):
- Metoda uzyskania konfiguracji przewoźnika:
getCarrierConfig
- Metoda uzyskania typu sieci do transmisji danych:
getDataNetworkType
- Metoda uzyskania typu sieci dla usługi głosowej:
getVoiceNetworkType
- Metody uzyskiwania informacji o aplikacji UICC SIM (USIM):
- Numer seryjny karty SIM:
getSimSerialNumber
- Informacje o karcie:
getUiccCardsInfo
- GID1 (identyfikator grupy poziom1):
getGroupIdLevel1
- Ciąg numeru telefonu dla wiersza 1:
getLine1Number
- Zakazana publiczna naziemna sieć komórkowa (PLMN):
getForbiddenPlmns
- Odpowiednik domu PLMN:
getEquivalentHomePlmns
- Numer seryjny karty SIM:
- Metody uzyskiwania lub ustawiania numeru poczty głosowej:
- Metoda wysłania specjalnego kodu dialera:
sendDialerSpecialCode
- Metoda resetowania radiomodemu:
rebootModem
- Metody uzyskiwania lub ustawiania trybów wyboru sieci:
- Metoda żądania skanowania sieci:
requestNetworkScan
- Metody uzyskiwania lub ustawiania dozwolonych/preferowanych typów sieci:
- Metody sprawdzania, czy mobilna transmisja danych lub roaming są włączone zgodnie z ustawieniami użytkownika:
- Metody sprawdzania lub ustawiania połączenia danych z powodu:
- Metoda uzyskania listy numerów alarmowych:
getEmergencyNumberList
- Metody kontrolowania sieci oportunistycznych:
- Metody ustawiania lub usuwania żądania aktualizacji siły sygnału komórkowego:
Telefonia Oddzwanianie
TelephonyCallback
ma interfejsy z metodą wywołania zwrotnego, które powiadamiają aplikację wywołującą o zmianie zarejestrowanych stanów:
- Zmieniono wskaźnik wiadomości oczekującej:
onMessageWaitingIndicatorChanged
- Zmieniono wskaźnik przekazywania połączeń:
onCallForwardingIndicatorChanged
- Zmieniono przyczynę rozłączenia połączenia systemu multimedialnego IP (IMS):
onImsCallDisconnectCauseChanged
- Zmieniono dokładny stan połączenia danych:
onPreciseDataConnectionStateChanged
- Zmieniono aktualną listę numerów alarmowych:
onEmergencyNumberListChanged
- Zmieniono identyfikator aktywnej subskrypcji danych:
onActiveDataSubscriptionIdChanged
- Zmieniono sieć operatora:
onCarrierNetworkChange
- Rejestracja w sieci lub aktualizacja lokalizacji/trasy/obszaru śledzenia nie powiodła się:
onRegistrationFailed
- Zmiana informacji o zakazie:
onBarringInfoChanged
- Bieżąca konfiguracja kanału fizycznego została zmieniona:
onPhysicalChannelConfigChanged
Menedżer subskrypcji
- Metody uzyskiwania różnych informacji o subskrypcji:
- Metoda uzyskania liczby aktywnych subskrypcji:
getActiveSubscriptionInfoCount
- Metody zarządzania grupami subskrypcji:
- Sposoby uzyskania lub ustawienia opisu planu relacji rozliczeniowych pomiędzy operatorem a konkretnym abonentem:
- Metoda tymczasowego zastąpienia planu relacji rozliczeniowych między operatorem a określonym abonentem, aby można go było uznać za niemierzonego:
setSubscriptionOverrideUnmetered
- Metoda tymczasowego zastąpienia planu relacji rozliczeniowych między operatorem a określonym abonentem w celu uznania za przeciążony:
setSubscriptionOverrideCongested
- Metoda sprawdzenia, czy aplikacja z podanym kontekstem jest uprawniona do zarządzania daną subskrypcją zgodnie z jej metadanymi:
canManageSubscription
Menedżer SMS-ów
- Metoda umożliwiająca dzwoniącemu tworzenie nowych przychodzących wiadomości SMS:
injectSmsPdu
. - Metoda wysyłania wiadomości tekstowej SMS bez zapisywania do dostawcy SMS:
sendTextMessageWithoutPersisting
CarrierConfigManager
- Metoda powiadamiania o zmianie konfiguracji:
notifyConfigChangedForSubId
. - Metoda uzyskania konfiguracji operatora dla domyślnej subskrypcji:
getConfig
- Metoda pobierania konfiguracji przewoźnika dla określonej subskrypcji:
getConfigForSubId
Aby uzyskać instrukcje, zobacz Konfiguracja operatora .
Menedżer raportów błędów
Metoda uruchamiania raportu o błędzie łączności, która jest wyspecjalizowaną wersją raportu o błędzie, która zawiera tylko informacje dotyczące debugowania problemów związanych z łącznością: startConnectivityBugreport
NetworkStatsManager
- Metoda zapytania o podsumowanie użycia sieci:
querySummary
- Metoda zapytania o historię użytkowania sieci:
queryDetails
- Metody rejestracji lub wyrejestrowania wywołania zwrotnego użycia sieci:
ImsMmTelManager
- Metody rejestracji lub wyrejestrowania wywołania zwrotnego rejestracji IMS MmTel:
ImsRcsManager
- Metody rejestracji lub wyrejestrowania wywołania zwrotnego rejestracji IMS RCS:
- Metody uzyskiwania stanu rejestracji IMS lub typu transportu:
Menedżer obsługi administracyjnej
- Metody rejestrowania i wyrejestrowywania wywołań zwrotnych aktualizacji udostępniania funkcji IMS:
- Metody związane ze statusem udostępniania funkcji IMS MmTel lub RCS:
Menedżer Euicc
Metoda przełączenia na (włączenia) danej subskrypcji: switchToSubscription
CarrierMessagingService
Usługa, która odbiera połączenia z systemu, gdy nowe wiadomości SMS i MMS są wysyłane lub odbierane. Aby rozszerzyć tę klasę, zadeklaruj usługę w swoim pliku manifestu z uprawnieniem android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE
i dołącz filtr intencji do akcji #SERVICE_INTERFACE
. Metody obejmują:
- Metoda filtrowania przychodzących wiadomości SMS:
onFilterSms
- Metoda przechwytywania wiadomości tekstowych SMS wysyłanych z urządzenia:
onSendTextSms
- Metoda przechwytywania binarnych wiadomości SMS wysyłanych z urządzenia:
onSendDataSms
- Metoda przechwytywania długich wiadomości SMS wysyłanych z urządzenia:
onSendMultipartTextSms
- Metoda przechwytywania wiadomości MMS wysyłanych z urządzenia:
onSendMms
- Metoda pobierania otrzymanych wiadomości MMS:
onDownloadMms
Usługa Przewoźnika
Usługa udostępniająca systemowi funkcje charakterystyczne dla przewoźnika. Aby rozszerzyć tę klasę, zadeklaruj usługę w pliku manifestu aplikacji z uprawnieniem android.Manifest.permission#BIND_CARRIER_SERVICES
i dołącz filtr intencji do akcji CARRIER_SERVICE_INTERFACE
. Jeśli usługa ma długotrwałe powiązanie, ustaw android.service.carrier.LONG_LIVED_BINDING
na true
w metadanych usługi.
Platforma wiąże CarrierService
ze specjalnymi flagami, aby proces obsługi przewoźnika przebiegał w specjalnej rezerwowej aplikacji . Zwalnia to aplikację usługi operatora z ograniczeń bezczynności aplikacji i zwiększa prawdopodobieństwo, że pozostanie ona aktywna, gdy pamięć urządzenia jest niska. Jeśli jednak aplikacja usługi przewoźnika ulegnie awarii z jakiegokolwiek powodu, utraci wszystkie powyższe uprawnienia do czasu ponownego uruchomienia aplikacji i przywrócenia powiązania. Dlatego bardzo ważne jest, aby aplikacja usługi przewoźnika była stabilna.
Metody w CarrierService
obejmują:
- Aby zastąpić i ustawić konfiguracje specyficzne dla przewoźnika:
onLoadConfig
- Aby poinformować system o zamierzonej zbliżającej się zmianie sieci operatora przez aplikację operatora:
notifyCarrierNetworkChange
Dostawca telefonii
Interfejsy API dostawców treści umożliwiające modyfikacje (wstawianie, usuwanie, aktualizowanie, wysyłanie zapytań) do bazy danych telefonii. Pola wartości są zdefiniowane w Telephony.Carriers
; Aby uzyskać więcej informacji, zapoznaj się z odwołaniem do klasy Telephony
Sugestia dotycząca sieci Wi-Fi
Podczas tworzenia obiektu WifiNetworkSuggestion
użyj następujących metod, aby ustawić identyfikator subskrypcji lub grupę subskrypcji:
- Metoda ustawiania identyfikatora subskrypcji:
setSubscriptionId
- Metoda ustawienia grupy subskrypcji:
setSubscriptionGroup
Platforma Androida
Na wykrytym UICC platforma konstruuje wewnętrzne obiekty UICC, które zawierają reguły uprawnień przewoźnika jako część UICC. UiccCarrierPrivilegeRules.java
ładuje reguły, analizuje je z karty UICC i zapisuje w pamięci podręcznej. Gdy wymagane jest sprawdzenie uprawnień, UiccCarrierPrivilegeRules
porównuje certyfikat osoby dzwoniącej z własnymi regułami jeden po drugim. Jeśli UICC zostanie usunięty, reguły zostaną zniszczone wraz z obiektem UICC.
Walidacja
Aby zweryfikować implementację za pomocą pakietu testów zgodności (CTS) przy użyciu CtsCarrierApiTestCases.apk
, musisz mieć dewelopera UICC z poprawnymi regułami UICC lub obsługą ARF. Poproś wybranego sprzedawcę karty SIM o przygotowanie deweloperskiego UICC z odpowiednim ARF zgodnie z opisem w tej sekcji i użycie tego UICC do przeprowadzenia testów. UICC nie wymaga aktywnej usługi komórkowej, aby przejść testy CTS.
Przygotuj UICC
W przypadku systemu Android 11 i niższych plik CtsCarrierApiTestCases.apk
jest podpisany przez aosp-testkey
z wartością skrótu 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
.
Począwszy od systemu Android 12, CtsCarrierApiTestCases.apk
jest podpisany przez cts-uicc-2021-testkey
, wartość skrótu 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
Aby uruchomić testy CTS Carrier API w systemie Android 12, urządzenie musi korzystać z karty SIM z uprawnieniami CTS CTS, spełniającej wymagania określone w najnowszej wersji specyfikacji profilu testowego GSMA TS.48 innej firmy.
Ta sama karta SIM może być również używana w wersjach starszych niż Android 12.
Modyfikowanie profilu CTS SIM
- Dodaj: uprawnienia przewoźnika CTS w masterze aplikacji reguł dostępu (ARA-M) lub ARF. Oba podpisy muszą być zakodowane w zasadach uprawnień przewoźnika:
-
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
-
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
-
- Utwórz: podstawowe pliki ADF USIM (EF) nieobecne w TS.48 i potrzebne do CTS:
- EF_MBDN (6FC7), rozmiar rekordu: 28, numer rekordu: 4
- Treść
- Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
- Rec2-n: FF…FF
- Treść
- EF_EXT6 (6FC8), rozmiar rekordu: 13, numer rekordu: 1
- Treść: 00FF…FF
- EF_MBI (6FC9), rozmiar rekordu: 4, numer rekordu: 1
- Treść: Rec1: 01010101
- EF_MWIS (6FCA), rozmiar rekordu: 5, numer rekordu: 1
- Treść: 0000000000
- Treść: 00FF…FF
- EF_MBDN (6FC7), rozmiar rekordu: 28, numer rekordu: 4
- Modyfikuj: Tabela usług USIM: Włącz usługi nr 47, nr 48
- EF_UST (6F38)
- Treść:
9EFFBF1DFFFE0083410310010400406E01
- Treść:
- EF_UST (6F38)
- Zmodyfikuj: pliki DF-5GS i DF-SAIP
- DF-5GS — EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Treść:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Treść:
- DF-5GS — EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
- Treść:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Treść:
- DF-5GS — EF SUCI_Calc_Info (USIM/5FC0/4F07)
- Treść:
A0020000FF…FF
- Treść:
- DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
- Treść:
A0020000FF…FF
- Treść:
- DF-5GS — EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Modyfikuj: Użyj ciągu nazwy przewoźnika Android CTS w odpowiednich plikach EF zawierających to oznaczenie:
- EF_SPN (USIM/6F46)
- Treść:
01416E64726F696420435453FF..FF
- Treść:
- EF_PNN (USIM/6FC5)
- Treść:
Rec1 430B83413759FE4E934143EA14FF..FF
- Treść:
- EF_SPN (USIM/6F46)
Dopasowanie struktury profilu testowego
Pobierz i dopasuj najnowszą wersję następujących ogólnych struktur profili testowych. Te profile nie będą miały spersonalizowanej zasady CTS Carrier Privilege ani innych modyfikacji wymienionych powyżej.
Uruchamianie testów
Dla wygody CTS obsługuje token urządzenia, który ogranicza testy do uruchamiania tylko na urządzeniach skonfigurowanych z tym samym tokenem. Testy Carrier API CTS obsługują token urządzenia sim-card-with-certs
. Na przykład następujący token urządzenia ogranicza testy interfejsu API przewoźnika do uruchamiania tylko na urządzeniu abcd1234
:
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
W przypadku uruchamiania testu bez użycia tokena urządzenia test jest uruchamiany na wszystkich urządzeniach.
Często zadawane pytania
W jaki sposób można aktualizować certyfikaty w UICC?
Odp.: użyj istniejącego mechanizmu aktualizacji karty OTA.
Czy UICC może współistnieć z innymi przepisami?
Odp.: Dobrze jest mieć inne zasady bezpieczeństwa w UICC w ramach tego samego AID; platforma odfiltrowuje je automatycznie.
Co się stanie, gdy UICC zostanie usunięty z aplikacji korzystającej z zawartych w nim certyfikatów?
O: Aplikacja traci swoje uprawnienia, ponieważ zasady związane z UICC są niszczone podczas usuwania UICC.
Czy istnieje limit liczby certyfikatów na UICC?
O: Platforma nie ogranicza liczby certyfikatów; ale ponieważ kontrola jest liniowa, zbyt wiele reguł może powodować opóźnienia w sprawdzaniu.
Czy istnieje ograniczenie liczby interfejsów API, które możemy obsługiwać za pomocą tej metody?
O: Nie, ale ograniczamy zakres do interfejsów API związanych z operatorem.
Czy istnieją interfejsy API, których nie wolno używać tej metody? Jeśli tak, jak je egzekwować? (to znaczy, czy masz testy sprawdzające, które interfejsy API są obsługiwane za pomocą tej metody?)
Odp.: Zobacz sekcję Zgodność behawioralna interfejsu API dokumentu definicji zgodności z systemem Android (CDD). Mamy kilka testów CTS, aby upewnić się, że model uprawnień API nie został zmieniony.
Jak to działa z funkcją wielu kart SIM?
O: Używana jest domyślna karta SIM określona przez użytkownika.
Czy to w jakikolwiek sposób wchodzi w interakcję lub pokrywa się z innymi technologiami dostępu SE, na przykład SEEK?
O: Na przykład SEEK używa tego samego AID, co w UICC. Tak więc reguły współistnieją i są filtrowane przez SEEK lub UiccCarrierPrivileges
.
Kiedy warto sprawdzić uprawnienia przewoźnika?
Odp.: po załadowaniu stanu karty SIM.
Czy producenci OEM mogą wyłączyć część interfejsów API przewoźnika?
O: Nie. Uważamy, że obecne interfejsy API to minimalny zestaw i planujemy użyć maski bitowej do dokładniejszej kontroli ziarnistości w przyszłości.
Czy setOperatorBrandOverride
zastępuje WSZYSTKIE inne formy ciągów nazw operatorów? Na przykład SE13, UICC SPN lub sieciowy NITZ?
Tak, nadpisanie marki operatora ma najwyższy priorytet. Gdy jest ustawiona, zastępuje WSZYSTKIE inne formy ciągów nazw operatorów.
Co robi wywołanie metody injectSmsPdu
?
O: Ta metoda ułatwia tworzenie kopii zapasowych/przywracanie wiadomości SMS w chmurze. Wywołanie injectSmsPdu
włącza funkcję przywracania.
Czy w przypadku filtrowania SMS-ów wywołanie onFilterSms
jest oparte na filtrowaniu portów SMS UDH? A może aplikacje operatora mają dostęp do WSZYSTKICH przychodzących SMS-ów?
O: Operatorzy mają dostęp do wszystkich danych SMS.
Rozszerzenie DeviceAppID-REF-DO
do obsługi 32 bajtów wydaje się być niezgodne z obecną specyfikacją GP (która dopuszcza tylko 0 lub 20 bajtów), więc dlaczego wprowadzacie tę zmianę? Czy SHA-1 nie wystarczy, aby uniknąć kolizji? Czy zaproponowałeś już tę zmianę GP, ponieważ może to być wstecznie niezgodne z istniejącym ARA-M/ARF?
O: Aby zapewnić bezpieczeństwo na przyszłość, to rozszerzenie wprowadza SHA-256 dla DeviceAppID-REF-DO
oprócz SHA-1, który jest obecnie jedyną opcją w standardzie GP SEAC. Zdecydowanie zalecamy korzystanie z algorytmu SHA-256.
Jeśli DeviceAppID
ma wartość 0 (puste), czy stosujesz regułę do wszystkich aplikacji urządzenia nieobjętych określoną regułą?
O: Interfejsy API Carrier wymagają wypełnienia DeviceAppID-REF-DO
. Pusta jest przeznaczona do celów testowych i nie jest zalecana w przypadku wdrożeń operacyjnych.
Zgodnie z twoją specyfikacją, PKG-REF-DO
używany sam w sobie, bez DeviceAppID-REF-DO
, nie powinien być akceptowany. Ale nadal jest to opisane w tabeli 6-4 specyfikacji jako rozszerzenie definicji REF-DO
. Czy to jest celowe? Jak zachowuje się kod, gdy w REF-DO
PKG-REF-DO
-DO?
O: Opcja posiadania PKG-REF-DO
jako pozycji o pojedynczej wartości w REF-DO
została usunięta w najnowszej wersji. PKG-REF-DO
powinien występować tylko w połączeniu z DeviceAppID-REF-DO
.
Zakładamy, że możemy przyznać dostęp do wszystkich uprawnień opartych na operatorach lub mieć bardziej szczegółową kontrolę. Jeśli tak, co definiuje mapowanie między maską bitową a rzeczywistymi uprawnieniami? Jedno pozwolenie na klasę? Jedno pozwolenie na metodę? Czy 64 osobne uprawnienia wystarczą na dłuższą metę?
O: Jest to zarezerwowane na przyszłość i czekamy na sugestie.
Czy możesz dokładniej zdefiniować DeviceAppID
dla Androida? To jest wartość skrótu SHA-1 (20 bajtów) certyfikatu wydawcy użytego do podpisania danej aplikacji, więc czy nazwa nie powinna odzwierciedlać tego celu? (Nazwa może być myląca dla wielu czytelników, ponieważ reguła ma wtedy zastosowanie do wszystkich aplikacji podpisanych tym samym certyfikatem wydawcy).
O: Certyfikaty przechowywania DeviceAppID
są obsługiwane przez istniejącą specyfikację. Staraliśmy się zminimalizować zmiany specyfikacji, aby obniżyć barierę adopcji. Aby uzyskać szczegółowe informacje, zobacz Zasady dotyczące UICC .