Identyfikatory urządzeń

Android 10 zmienia uprawnienia dotyczące aplikacji dzięki czemu wszystkie identyfikatory urządzeń są teraz chronione przez uprawnienia READ_PRIVILEGED_PHONE_STATE. Przed Android 10, trwałe identyfikatory urządzenia (IMEI/MEID, IMSI, SIM i numer seryjny kompilacji) zostały zabezpieczone za pomocą Uprawnienia w czasie działania aplikacji READ_PHONE_STATE. Uprawnienie READ_PRIVILEGED_PHONE_STATE jest dostępne tylko przyznawanych aplikacjom podpisanym kluczem platformy i aplikacjom systemowym z odpowiednimi uprawnieniami.

Więcej informacji o wymaganiach dotyczących nowych uprawnień znajdziesz w Strony w języku Javadoc dla TelephonyManager.java i Build.java.

Ta zmiana dotyczy tych interfejsów API:

• TelephonyManager#getDeviceId
• Menedżer telefonii#getImei
• Menedżer telefonii#getMeid
• TelephonyManager#getSimSerialNumber
• TelephonyManager#getSubskrybenciId
• Kompilacja#getSerial

Dostęp dla aplikacji operatora bez uprawnienia READ_PRIVILEGED_PHONE_STATE

wstępnie załadowane aplikacje operatora, które nie kwalifikują się do READ_PRIVILEGED_PHONE_STATE może wdrożyć jedną z opcji opisanych w tabeli poniżej.

Wszystkie aplikacje operatora mają dostęp do identyfikatorów urządzenia po przeprowadzeniu aktualizacji plik CarrierConfig.xml z haszem certyfikatu podpisywania z aplikacji operatora. Gdy aplikacja operatora wywołuje metodę odczytu z podwyższonymi uprawnieniami informacje, platforma szuka dopasowania certyfikatu podpisywania aplikacji (podpis SHA-1 lub SHA-256 certyfikatu) w CarrierConfig.xml. Jeśli znajdziemy dopasowanie, informacje na ten temat. Jeśli nie zostaną znalezione pasujące wyniki, zostanie wybrany wyjątek zabezpieczeń .

Aby wdrożyć to rozwiązanie, operatorzy MUSZĄ wykonać te czynności:

1. Aktualizuj CarrierConfig.xml haszem certyfikatu podpisywania aplikacji operatora prześlij poprawkę.
2. Poproś OEM o zaktualizowanie kompilacji w wersji QPR1 lub nowszej (zalecane) LUB wymagane poprawki platformy oraz poprawka zawierająca zaktualizował(a) plik CarrierConfig.xml z kroku 1 powyżej.

Implementacja

Zaktualizuj listę dozwolonych uprawnień, aby przyznać READ_PRIVILEGED_PHONE_STATE dla osób z podwyższonymi uprawnieniami które wymagają dostępu do identyfikatorów urządzenia.

Więcej informacji o liście dozwolonych znajdziesz w sekcji Z podwyższonymi uprawnieniami Lista dozwolonych uprawnień.

Aby można było wywołać interfejsy API, których dotyczy problem, aplikacja musi spełniać jeden z tych warunków wymagania:

• Jeśli jest to wstępnie załadowana aplikacja z podwyższonymi uprawnieniami, musi mieć READ_PRIVILEGED_PHONE_STATE uprawnienie zadeklarowane w AndroidManifest.xml. Aplikacja musi też dodać do listy dozwolonych to uprawnienie.
• Aplikacje dostarczane z Google Play wymagają uprawnień operatora. Więcej informacji o przyznawaniu uprawnień operatora u operatora UICC Uprawnienia.
• Aplikacja właściciela urządzenia lub profilu, której przyznano uprawnienia Uprawnienie READ_PHONE_STATE.

Aplikacja, która nie spełnia żadnego z tych wymagań, ma: zachowanie:

• Jeśli aplikacja jest kierowana na okres przed kwartałem i nie ma Przyznano READ_PHONE_STATE uprawnienie, SecurityException jest to obecne zachowanie sprzed kwartału, ponieważ to uprawnienie jest wymagana do wywołania tych interfejsów API.
• Jeśli aplikacja jest kierowana na wcześniejsze kwartały i ma Przyznano uprawnienie READ_PHONE_STATE, otrzymuje wartość pusta dla wszystkich interfejsów API TelephonyManager i Build.UNKNOWN. dla metody Build#getSerial.
• Jeśli aplikacja jest kierowana na Androida 10 lub nowszego i nie spełnia żadnej musi otrzymać wyjątek SecurityException.

Weryfikacja i testowanie

Zgodność Pakiet testów (CTS) obejmuje testy sprawdzające oczekiwany identyfikator urządzenia. działania dostępu dla aplikacji z uprawnieniami operatora właścicieli profili oraz aplikacje, które nie powinny mieć dostępu do urządzenia i identyfikatorów.

Poniższe testy CTS dotyczą tej funkcji.

cts-tradefed run cts -m CtsCarrierApiTestCases -t
    android.carrierapi.cts.CarrierApiTest

cts-tradefed run cts -m CtsTelephonyTestCases -t
    android.telephony.cts.TelephonyManagerTest

cts-tradefed run cts -m CtsTelephony3TestCases

cts-tradefed run cts -m CtsPermissionTestCases -t
    android.permission.cts.TelephonyManagerPermissionTest

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCanGetDeviceIdentifiers

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCanGetDeviceIdentifiers

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCannotGetDeviceIdentifiersWithoutPermission

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCannotGetDeviceIdentifiersWithoutPermission

Najczęstsze pytania

Ile aplikacji można dodać do listy dozwolonych w CarrierConfig.xml w danym okresie (MCK, MNC)?

Nie ma ograniczeń co do liczby haszów certyfikatów zawartych w tablicy.

Jakich parametrów CarrierConfig w usłudze CarrierConfig.xml muszę użyć, aby aplikacja znalazła się na liście dozwolonych?

Użyj tego elementu konfiguracji najwyższego poziomu w określonej CarrierConfig.xml w skonfigurowanych przez Ciebie opcjach AOSP:

<string-array name="carrier_certificate_string_array" num="2">
    <item value="BF02262E5EF59FDD53E57059082F1A7914F284B"/>
    <item value="9F3868A3E1DD19A5311D511A60CF94D975A344B"/>
</string-array>

Czy istnieje podstawowy szablon CarrierConfig, którego mogę użyć?

Użyj tego szablonu. Należy go dodać do odpowiednich zasobów.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<carrier_config>
    <string-array name="carrier_certificate_string_array"
num="1">
        <item value="CERTIFICATE_HASH_HERE"/>
    </string-array>
</carrier_config>

Czy karta SIM operatora musi znajdować się w urządzeniu, aby można było uzyskać dostęp do jego identyfikatorów?

Używana kolumna CarrierConfig.xml jest określana na podstawie Włożona karta SIM. Oznacza to, że jeśli aplikacja operatora X będzie próbowała uzyskać uprawnienia dostępu po włożeniu karty SIM operatora Y, urządzenie nie znajdzie dopasowania do skrótu i zwraca wyjątek bezpieczeństwa.

Na urządzeniach z wieloma kartami SIM operator 1 ma uprawnienia dostępu tylko do karty SIM 1 oraz na odwrót.

Jak operatorzy konwertują certyfikat podpisywania aplikacji na hasz?

Aby przekonwertować certyfikaty podpisywania na hasz przed ich dodaniem do CarrierConfig.xml, wykonaj te czynności:

1. Skonwertuj podpis certyfikatu podpisywania na tablicę bajtów za pomocą toByteArray
2. Użyj formatu MessageDigest, aby przekonwertować tablicę bajtów na hasz typu byte[].

3. Konwertuj hasz z bajta[] na format szesnastkowy. Na przykład: zobacz IccUtils.java.

   List<String> certHashes = new ArrayList<>();
   PackageInfo pInfo; // Carrier app PackageInfo
   MessageDigest md =
   MessageDigest.getInstance("SHA-256");
   for (Signature signature : pInfo.signatures) {
       certHashes.add(bytesToHexString(md.digest(signature.toByteArray()));
   }

4. Jeśli certHashes jest tablicą o rozmiarze 2 z wartością z 12345 i 54321, dodaj poniższe elementy do .

   <string-array name="carrier_certificate_string_array" num="2">
       <item value="12345"/>
       <item value="54321"/>
   </string-array>