Historia zmian w dokumencie definicji zgodności z Androidem

Android 14

26 czerwca 2024 r.

2. Typy urządzeń

  • 2.2.1 Sprzęt:

    Zobacz wersję

    • [7.6.1/H-1-1] MUSI obsługiwać tylko jeden interfejs ABI (tylko 64-bitowy lub 32-bitowy).

    Zobacz wersję

    Zacznij nowe wymagania

    Jeśli implementacje urządzeń mobilnych obsługują język Vulkan:

  • 2.4.1 Sprzęt:

    Zobacz wersję

    Zacznij nowe wymagania

    Jeśli implementacje na zegarkach obsługują interfejs Vulkan:

  • 2.5.1 Sprzęt:

    Zobacz wersję

    Zacznij nowe wymagania

    Jeśli implementacje urządzeń z Androidem obsługują język Vulkan:

3. Oprogramowanie

  • 3.2.2 Parametry kompilacji:

    W przypadku parametru ODM_SKU:

    Zobacz wersję

    Wartość tego pola MUSI być zakodowana jako 7-bitowy kod ASCII i pasuje do wyrażenia regularnego ^([0-9A-Za-z.,_-]+)$.

5. Zgodność multimediów

  • 5.1.3 Informacje o kodekach audio:

    Dodano szczegóły formatu/kodeka Vorbis:

    Zobacz wersję

    Dekodowanie: obsługa treści mono, stereo, 5.0 i 5.1 z częstotliwościami próbkowania 8000, 12 000, 16000, 24 000 i 48 000 Hz.
    Kodowanie: obsługa treści mono i stereo z częstotliwościami próbkowania 8000, 12 000, 0, 0, 0, 1

7. Zgodność sprzętu

9. Zgodność modelu zabezpieczeń

  • 9.7. Funkcja zabezpieczeń:

    Zmieniono numerację [C-SR-1] na [C-SR-7], aby usunąć powielone treści, i usunęliśmy ją [C-SR-8]:

    Zobacz wersję

    • [C-SR-1] Zdecydowanie ZALECANE jest zachowanie danych jądra, które po zainicjowaniu są zapisywane jako tylko do odczytu (np. __ro_after_init).

    • [C-SR-2] Zdecydowanie ZALECANE jest użycie losowego układu kodu jądra i pamięci oraz unikanie narażenia na ryzyko wystąpienia randomizacji (np. CONFIG_RANDOMIZE_BASE z entropią programu rozruchowego przez /chosen/kaslr-seed Device Tree node lub EFI_RNG_PROTOCOL).

    • [C-SR-3] Zdecydowanie ZALECANE jest włączenie integralności przepływu sterowania (CFI) w jądrze, co zapewnia dodatkową ochronę przed atakami polegającymi na ponownym użyciu kodu (np. CONFIG_CFI_CLANG i CONFIG_SHADOW_CALL_STACK).

    • [C-SR-4] Zdecydowanie ZALECANE jest, aby nie wyłączać funkcji Control-Flow Integrity (CFI), stosów wywołań cieni (SCS) ani Integer Overflow Sanitization (IntSan) w komponentach, które mają tę funkcję włączoną.

    • [C-SR-5] Zdecydowanie ZALECANE jest włączenie CFI, SCS i IntSan w przypadku wszelkich dodatkowych komponentów w przestrzeni użytkownika zapewniających bezpieczeństwo, jak opisano w CFI i IntSan.

    • [C-SR-6] Zdecydowanie ZALECANE jest włączenie inicjowania stosu w jądrze, co zapobiega używaniu niezainicjowanych zmiennych lokalnych (CONFIG_INIT_STACK_ALL lub CONFIG_INIT_STACK_ALL_ZERO). Ponadto implementacje urządzeń NIE POWINNY zakładać wartości używanej przez kompilator do inicjowania zasobów lokalnych.

    • [C-SR-7] Zdecydowanie ZALECANE jest włączenie inicjowania stosu w jądrze, co zapobiega używaniu niezainicjowanych alokacji sterty (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). NIE POWINNO SIĘ przyjmować wartości używanej przez jądro do inicjowania tych alokacji.

  • 9.11. Klucze i dane logowania:

    Zobacz wersję

    • [C-1-6] MUSI obsługiwać jeden z tych formatów:
      • IKeymasterDevice 3.0,
      • IKeymasterDevice 4.0,
      • IKeymasterDevice 4.1,
      • IKeyMintDevice w wersji 1 lub
      • IKeyMintDevice w wersji 2.

  • 9.11.1. Bezpieczny ekran blokady, uwierzytelnianie i urządzenia wirtualne:

    Zobacz wersję

    • [C-8-3] NIE MOGĄ udostępniać interfejsu API do zmiany stanu blokady aplikacji innych firm.

    Zobacz wersję

    • [C-12-4] MUSI wywołać TrustManagerService.revokeTrust()
      • po maksymalnie 24 godzinach od przyznania zaufania,
      • po 8-godzinnym okresie bezczynności lub
      • Jeśli implementacje nie korzystają z szyfrowanych ani dokładnych danych z zakresu zgodnie z definicją w artykule [C-12-5], bazowe połączenie z zbliżonym urządzeniem fizycznym zostaje utracone.
    • [C-12-5] Implementacje, które wymagają bezpiecznego i dokładnego zakresu, aby spełniać wymagania standardu [C-12-4] MUSZĄ korzystać z jednego z tych rozwiązań:
      • Implementacje korzystające z UWB:
        • MUSI spełniać wymagania dotyczące zgodności, certyfikacji, dokładności i kalibracji w przypadku UWB opisane w 7.4.9.
        • MUSI używać jednego z trybów zabezpieczeń P-STS wymienionych w 7.4.9.
      • Implementacje z wykorzystaniem sieci wykrywania okolic Wi-Fi (NAN):
        • MUSI spełniać wymagania dotyczące dokładności podane w artykule 2.2.1 [7.4.2.5/H-SR-1], musi mieć przepustowość 160 MHz (lub większą) i wykonać czynności konfiguracyjne pomiaru opisane w artykule Kalibracja obecności.
        • MUSI używać bezpiecznego LTF zgodnie z definicją w IEEE 802.11az.

8 kwietnia 2024 r.

2. Typy urządzeń

  • 2.2.1 Sprzęt:

    Zobacz wersję

    Zacznij nowe wymagania

    Jeśli implementacje urządzeń mobilnych zadeklarują FEATURE_BLUETOOTH_LE:

    • [7.4.3/H-1-3] MUSI mierzyć i kompensować przesunięcie Rx, aby mediana BLE RSSI wynosiła -50 dBm +/-15 dB w odległości 1 m od urządzenia referencyjnego transmitującego z częstotliwości ADVERTISE_TX_POWER_HIGH.
    • [7.4,3/H-1-4] MUSI mierzyć i kompensować przesunięcie sygnału, aby mediana BLE RSSI wynosiła -50 dBm +/-15 dB podczas skanowania z urządzenia referencyjnego umieszczonego w odległości 1 m i przesyłania z prędkości ADVERTISE_TX_POWER_HIGH.

  • 2.2.5 Model zabezpieczeń:

    Zobacz wersję

    Jeśli implementacje urządzeń mobilnych obsługują interfejs System API HotwordDetectionService lub inny mechanizm wykrywania słów-kluczy bez wskazania dostępu do mikrofonu, to:

    • [9.8/H-1-6] W przypadku każdego udanego wyniku słowa-klucza NIE MOŻNA zezwalać na przesyłanie z usługi wykrywania słów-kluczy więcej niż 100 bajtów danych, z wyjątkiem danych audio przekazywanych przez HotwordAudioStream.

    Zobacz wersję

    Zmień [9.8/H-1-13] na:

    • [9.8/H-SR-3] Zdecydowanie ZALECANE jest ponowne uruchomienie procesu hostowania usługi wykrywania słów-kluczy co najmniej raz na godzinę lub co 30 zdarzeń związanych ze sprzętem, w zależności od tego, co nastąpi wcześniej.

    Zobacz wersję

    Usunęliśmy wymagania [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].

  • 2.2.7.2. Aparat:

    Zobacz wersję

    Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.U dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

    • [7.5/H-1-3] MUSI obsługiwać właściwość android.info.supportedHardwareLevel jako FULL lub lepszą w przypadku tylnej głównej kamery oraz LIMITED lub lepszej dla przedniej kamery głównej.

  • 2.3.2 Multimedia:

    Zobacz wersję

    Jeśli modele telewizorów nie mają wbudowanego wyświetlacza, ale obsługują zewnętrzny wyświetlacz podłączony przez HDMI,:

    • [5.8/T-0-1] MUSI ustawić tryb wyjścia HDMI na najwyższą rozdzielczość dla wybranego formatu piksela, który obsługuje częstotliwość odświeżania 50 Hz lub 60 Hz na wyświetlaczu zewnętrznym. Zależy to od częstotliwości odświeżania wideo w regionie, w którym sprzedawane jest urządzenie. MUSI ustawić tryb wyjścia HDMI, aby wybrać maksymalną rozdzielczość, jaką można obsługiwać przy częstotliwości odświeżania 50 Hz lub 60 Hz.

3. Oprogramowanie

5. Zgodność multimediów

  • 5.3.8 Dolby Vision:

    Zobacz wersję

    Jeśli implementacje urządzeń zadeklarują obsługę dekodera Dolby Vision za pomocą HDR_TYPE_DOLBY_VISION:

    • [C-1-3] MUSI ustawić identyfikator ścieżki zgodnych wstecznie warstw podstawowych (jeśli występują), aby był taki sam jak identyfikator ścieżki połączonej warstwy Dolby Vision.

7. Zgodność sprzętu

  • 7.1.1.1. Rozmiar i kształt ekranu:

    Zobacz wersję

    Jeśli implementacje urządzeń obsługują ekrany o rozmiarze UI_MODE_TYPE_NORMAL i używają fizycznych wyświetlaczy z zaokrąglonymi rogami do renderowania tych ekranów:

    • [C-1-1] W przypadku każdego wyświetlacza należy spełnić co najmniej jeden z tych warunków:
      • Jeśli w każdym rogu wyświetlacza logicznego zakotwiczona jest ramka o wymiarach 1518 na 1518 dp, na ekranie widoczny jest co najmniej 1 piksel.

  • 7.4.3 Bluetooth:

    Zobacz wersję

    Przywróciliśmy te wymagania:

    Jeśli implementacje urządzenia zadeklarują FEATURE_BLUETOOTH_LE:

    • [C-SR-2] Zdecydowanie ZALECANE są pomiary i skompensowanie przesunięcia Rx w celu zapewnienia, że mediana BLE RSSI wynosi -60 dBm +/-10 dB w odległości 1 m od urządzenia referencyjnego transmitującego w trybie ADVERTISE_TX_POWER_HIGH, w którym urządzenia są zorientowane w „równoległych płaszczyznach” z ekranami skierowanymi w tym samym kierunku.

    • [C-SR-3] Zdecydowanie ZALECANE są pomiary i skompensowanie przesunięcia teksu, dzięki czemu mediana BLE RSSI wynosi -60 dBm +/-10 dB podczas skanowania z urządzenia referencyjnego znajdującego się w odległości 1 m i transmisji w ADVERTISE_TX_POWER_HIGH, gdzie urządzenia są zorientowane w taki sposób, że znajdują się w „płaszczyznach równoległych” z ekranami skierowanymi w tym samym kierunku.

    Zobacz wersję

    Przeniesiono wymagania [C-10-3] i [C-10-4] do 2.2.1. Urządzenie.

    • [C-10-3] MUSI mierzyć i kompensować przesunięcie Rx, aby mediana BLE RSSI wynosiła -55 dBm +/-10 dB w odległości 1 m od urządzenia referencyjnego transmitującego z częstotliwości ADVERTISE_TX_POWER_HIGH.
    • [C-10-4] MUSI mierzyć i kompensować przesunięcie sygnału, aby mediana BLE RSSI wynosiła -55 dBm +/-10 dB podczas skanowania z urządzenia referencyjnego umieszczonego w odległości 1 m i przesyłania z odległości ADVERTISE_TX_POWER_HIGH.

20 listopada 2023 r.

2. Typy urządzeń

  • 2.2.1 Sprzęt:

    Zobacz wersję

    Jeśli implementacje na urządzeniach mobilnych deklarują obsługę dowolnego 64-bitowego interfejsu ABI (z 32-bitowym ABI lub bez):

  • 2.2.7.2. Aparat:

    Zobacz wersję

    • [7.5/H-1-13] MUSI obsługiwać LOGICAL_MULTI_CAMERA w przypadku głównego tylnego aparatu, jeśli jest więcej niż 1 tylny aparat RGB.

  • 2.3.2 Multimedia:

    Zobacz wersję

    • [5.8/T-0-1] MUSI ustawić tryb wyjścia HDMI na najwyższą rozdzielczość dla wybranego formatu SDR lub HDR, który obsługuje częstotliwość odświeżania 50 Hz lub 60 Hz w przypadku wyświetlacza zewnętrznego.

      MUSI ustawić tryb wyjścia HDMI, aby wybrać maksymalną rozdzielczość, jaką można obsługiwać przy częstotliwości odświeżania 50 Hz lub 60 Hz.

  • 2.4.5 Model zabezpieczeń:

    Zobacz wersję

    • [9/W-0-1] MUSI zadeklarować android.hardware.security.model.compatible feature.

6. Zgodność narzędzi i opcji dla programistów

  • 6.1. Narzędzia dla programistów:

    Zobacz wersję

    • [C-0-12] MUSI napisać LMK_KILL_OCCURRED_FIELD_NUMBER Atom w

    Zobacz wersję

    • [C-0-13] Aby wyświetlić, TRZEBA zaimplementować polecenie powłoki dumpsys gpu --gpuwork

9. Zgodność modelu zabezpieczeń

  • 9.7. Funkcje zabezpieczeń:

    Zobacz wersję

    Jeśli implementacje urządzeń korzystają z jądra systemu Linux, które może obsługiwać SELinux:

    Zobacz wersję

    Jeśli implementacje urządzeń korzystają z jądra innego niż Linux lub Linux bez SELinux:

4 października 2023 roku

2. Typy urządzeń

  • 2.2. Wymagania dotyczące urządzenia przenośnego:

    Zobacz wersję

    Implementacje na urządzeniach z Androidem zaliczamy do urządzeń mobilnych, jeśli spełniają wszystkie te kryteria:

    • mieć fizyczny, przekątny ekran o przekątnej 4 cali 3,3 cala (lub 2,5 cala w przypadku implementacji na poziomie interfejsu API 29 lub starszym) na 8 cali.

    Zacznij nowe wymagania

    • muszą mieć interfejs wprowadzania na ekranie dotykowym,

  • 2.2.1 Sprzęt:

    Zobacz wersję

    Implementacje na urządzeniach mobilnych:

    Jeśli implementacje urządzeń mobilnych obsługują obracanie ekranu za pomocą oprogramowania, umożliwiają one:

    • [7.1.1.1/H-1-1]* Ekran logiczny udostępniany aplikacjom innych firm MUSI mieć co najmniej 2 cale od krótszej krawędzi i 2,7 cala od dłuższej. Urządzenia wysłane z wykorzystaniem interfejsu Android API na poziomie 29 lub starszym mogą zostać zwolnione z tego wymogu.

    Jeśli implementacje urządzeń mobilnych nie obsługują programowego obracania ekranu:

    • [7.1.1.1/H-2-1]* Ekran logiczny udostępniany aplikacjom innych firm MUSI mieć co najmniej 2,7 cala od krótszej krawędzi. Urządzenia wysłane z wykorzystaniem interfejsu Android API na poziomie 29 lub starszym mogą zostać zwolnione z tego wymogu.

    Zacznij nowe wymagania

    • [7.1.1.1/H-0-3]* MUSI mapować każdy wyświetlacz UI_MODE_NORMAL dostępny dla aplikacji innych firm na nieprzesłonięty fizyczny obszar wyświetlacza, który jest co najmniej 2,2 cala od krótszej krawędzi i 3,4 cala od dłuższej krawędzi.

    • [7.1.1.3/H-0-1]* MUSI ustawić wartość DENSITY_DEVICE_STABLE na 92% lub więcej od rzeczywistej, fizycznej gęstości odpowiedniego wyświetlacza.

    Jeśli implementacje na urządzeniach mobilnych zadeklarują android.hardware.audio.output i android.hardware.microphone:

    • [5.6/H-1-1] MUSI mieć średni czas oczekiwania w obie strony w obie strony wynoszący 300 milisekund lub mniej niż 5 pomiarów przy średnim odchyleniu bezwzględnym mniejszym niż 30 ms dla następujących ścieżek danych: „głośnik do mikrofonu”, przejściówka z zapętlaniem się USB 3,5 mm (jeśli jest obsługiwana).

    • Średni czas oczekiwania na połączenie [5,6/H-1-2] przez dotknięcie wynosi 300 milisekund lub mniej w przypadku co najmniej 5 pomiarów między głośnikiem a mikrofonem.

    Jeśli implementacje urządzeń mobilnych zawierają co najmniej jeden czujnik haptyczny:

    Jeśli implementacje urządzeń mobilnych obejmują co najmniej 1 automatyczny rezonator rezonansowy do zwykłych obciążeń 7.10 , to:

    • [7.10/H] NALEŻY umieścić urządzenie wykonawcze w pobliżu miejsca, w którym zazwyczaj jest trzymany lub dotykany dłońmi.

    • [7.10/H] MUSISZ przesunąć element haptyczny w osi X (lewo-prawo) w naturalnej orientacji pionowej .

    Jeśli implementacje urządzeń mobilnych są uniwersalne aktywatorem haptycznym, który jest wyposażone w liniowy rezonator rezonansowy (LRA), z osią X:

    • [7,10/H] Częstotliwość rezonansowa LRA na osi X powinna być mniejsza niż 200 Hz.

  • 2.2.2 Multimedia:

    Zobacz wersję

    Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać poniższe formaty kodowania wideo i udostępniać je aplikacjom innych firm:

    • [5.2/H-0-3] AV1

    Implementacje na urządzeniach mobilnych MUSZĄ obsługiwać poniższe formaty dekodowania wideo i udostępniać je aplikacjom innych firm:

    • [5.3/H-0-6] AV1

  • 2.2.3 Oprogramowanie:

    Zobacz wersję

    Jeśli implementacje urządzeń obejmujące klawisz nawigacyjny funkcji ostatnich, zgodnie z opisem w sekcji 7.2.3, zmieniają interfejs:

    • [3.8.3/H-1-1] MUSI zaimplementować funkcję przypinania ekranu i udostępnić użytkownikowi menu ustawień umożliwiające przełączenie funkcji.

    Jeśli implementacje urządzeń mobilnych obsługują interfejsy API ControlsProviderService i Control oraz umożliwiają aplikacjom innych firm publikowanie elementów sterujących urządzeń, to:

    • [3.8.16/H-1-6] Implementacje urządzeń MUSZĄ dokładnie odzwierciedlać preferencje użytkownika w następujący sposób:
      • Jeśli urządzenie ustawiło config_supportsMultiWindow=true, a aplikacja deklaruje metadane META_DATA_PANEL_ACTIVITY w deklaracji ControlsProviderService, w tym nazwę KomponentName poprawnej aktywności (zgodnie z definicją interfejsu API), aplikacja MUSI umieścić tę aktywność w tej przydatności użytkownika.
      • Jeśli aplikacja nie deklaruje metadanych META_DATA_PANEL_ACTIVITY, MUSI wyrenderować określone pola zgodnie z interfejsem API ControlsProviderService, a także wszystkie określone pola udostępnione przez interfejsy API Control.
    • [3.8.16/H-1-7] Jeśli aplikacja deklaruje metadane META_DATA_PANEL_ACTIVITY, MUSI przekazać wartość ustawienia zdefiniowanego w [3.8.16/H-1-5] za pomocą EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS podczas uruchamiania umieszczonej aktywności.

    Jeśli implementacje urządzeń umożliwiają użytkownikom nawiązywanie jakichkolwiek połączeń,

  • 2.2.4 Wydajność i moc:

    Zobacz wersję

    Implementacje na urządzeniach mobilnych:

    • [8.5/H-0-1] MUSI udostępniać informacje o zainteresowaniu użytkownika w menu Ustawienia , aby wyświetlić wszystkie aplikacje z aktywnymi usługami na pierwszym planie lub zadaniami inicjowanymi przez użytkownika, w tym czas trwania działania każdej z tych usług od momentu uruchomienia zgodnie z opisem w dokumentacji pakietu SDK. i możliwość zatrzymania aplikacji uruchomionej przez pakiet SDK i określonej możliwości zainicjowanej przez użytkownika w przypadku danej usługi na pierwszym planie i opisanej przez użytkownika usługi i każdej aplikacji zainicjowanej przez użytkownika.
      • Niektóre aplikacje MOGĄ zostać zwolnione z zatrzymywania lub wyświetlania na liście zgodnie z opisem w dokumentacji pakietu SDK.

    • [8.5/H-0-2]MUSI udostępniać informacje o konieczności zatrzymania aplikacji uruchomionej na pierwszym planie lub zadania inicjowanego przez użytkownika.

  • 2.2.5 Model zabezpieczeń:

    Zobacz wersję

    Jeśli implementacje urządzenia zadeklarują obsługę android.hardware.telephony, będą to:

    • [9.5/H-1-1] NIE MOŻE ustawiać UserManager.isHeadlessSystemUserMode na true.

    Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jednego agenta zaufania, który implementuje systemowy interfejs API TrustAgentService:

    • [9.11.1/H-1-1] MUSI prosić użytkownika o zastosowanie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) częściej niż raz na 72 godziny.

    Jeśli dla implementacji na urządzeniach mobilnych UserManager.isHeadlessSystemUserMode ustawisz wartość true,

    • [9.5/H-4-1] NIE MOŻE obejmować obsługi kart eUICC ani kart eSIM z możliwością nawiązywania połączeń.
    • [9.5/H-4-2] NIE MOŻE deklarować obsługi android.hardware.telephony.

    Jeśli implementacje urządzeń mobilnych obsługują interfejs System API HotwordDetectionService lub inny mechanizm wykrywania słów-kluczy bez informacji o dostępie do mikrofonu:

    • [9.8/H-1-1] MUSI mieć pewność, że usługa wykrywania słów-kluczy może przesyłać dane tylko do systemu ContentCaptureService, lub wbudowanej usługi rozpoznawania mowy na urządzeniu, utworzonej przez SpeechRecognizer#createOnDeviceSpeechRecognizer().
    • [9.8/H-1-6] NIE MOŻESZ zezwalać na przesyłanie więcej niż 100 bajtów danych (z wyłączeniem strumieni audio) z usługi wykrywania słów-kluczy w przypadku każdego udanego wyniku dla słowa-klucza.

    • [9.8/H-1-15] MUSI mieć pewność, że strumienie audio dostarczane po dobrych wynikach słów-kluczy są przesyłane w jedną stronę z usługi wykrywania słów-kluczy do usługi interakcji głosowej.

    Jeśli implementacje urządzeń obejmują aplikację, która korzysta z interfejsu System API HotwordDetectionService lub podobnego mechanizmu do wykrywania słów-kluczy bez wskazania użycia mikrofonu, aplikacja:

    • [9.8/H-2-3] NIE MOŻE przesyłać z usługi wykrywania słów-kluczy, danych dźwiękowych, danych, które mogą zostać użyte do całkowitego lub częściowego odtworzenia dźwięku, ani treści audio niezwiązanych z samym słowem-kluczem, z wyjątkiem usługi ContentCaptureService i usługi rozpoznawania mowy dostępnej na urządzeniu.

    Jeśli implementacje urządzeń mobilnych obsługują interfejs System API VisualQueryDetectionService lub inny mechanizm wykrywania zapytań bez wskazania mikrofonu lub aparatu, to:

    • [9.8/H-3-1] MUSI mieć pewność, że usługa wykrywania zapytań może przesyłać dane tylko do systemu, ContentCaptureService lub usługi rozpoznawania mowy na urządzeniu (utworzonej przez SpeechRecognizer#createOnDeviceSpeechRecognizer()).
    • [9.8/H-3-2] NIE MOŻE zezwalać na przesyłanie żadnych informacji dźwiękowych ani wideo poza VisualQueryDetectionService z wyjątkiem usługi ContentCaptureService lub usługi rozpoznawania mowy działającej na urządzeniu.
    • [9.8/H-3-3] MUSI wyświetlać w interfejsie systemu powiadomienie, gdy urządzenie wykryje zamiar skorzystania z aplikacji Asystent cyfrowy (np.przez wykrywanie obecności użytkownika za pomocą aparatu).
    • [9.8/H-3-4] MUSI wyświetlać wskaźnik mikrofonu i pokazywać w interfejsie użytkownika od razu po wykryciu zapytania.
    • [9.8/H-3-5] NIE MOŻE zezwalać aplikacji instalowanej przez użytkownika na udostępnianie usługi wizualnego wykrywania zapytań.

  • 2.2.7.1. Multimedia:

    Zobacz wersję

    Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.T dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

    Zacznij nowe wymagania

    Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.U dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

    • [5.1/H-1-1] MUSI reklamować maksymalną liczbę sesji sprzętowego dekodera wideo, które można uruchomić jednocześnie w dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-2] MUSI obsługiwać 6 instancji sprzętowych sesji dekodera wideo 8-bitowego (SDR) (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków działających jednocześnie z 3 sesjami w rozdzielczości 1080p przy 30 kl./s i 3 sesjami przy 4K, chyba że: Kodeki AV1 są wymagane tylko do obsługi rozdzielczości 1080p, ale są wymagane do obsługi 6 instancji przy 1080p30 kl./s.
    • [5.1/H-1-3] MUSI reklamować maksymalną liczbę sesji kodera wideo na sprzęcie, które można uruchomić jednocześnie przy użyciu dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-4] MUSI obsługiwać 6 instancji sprzętowych sesji kodera wideo 8-bitowego (SDR) (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków działających jednocześnie z 4 sesjami w rozdzielczości 1080p przy 30 klatkach na sekundę i 2 sesjami przy rozdzielczości 4K przy 30 kl./s, za wyjątkiem Kodeki AV1 są wymagane tylko do obsługi rozdzielczości 1080p, ale są wymagane do obsługi 6 instancji przy 1080p30 kl./s.
    • [5.1/H-1-5] MUSI reklamować maksymalną liczbę sesji kodera i dekodera, które można jednocześnie uruchomić w dowolnej kombinacji kodeków za pomocą metod CodecCapabilities.getMaxSupportedInstances() i VideoCapabilities.getSupportedPerformancePoints().
    • [5.1/H-1-6] MUSI obsługiwać 6 instancji sprzętowego dekodera wideo 8-bitowego (SDR) i sprzętowych sesji kodera wideo (AVC, HEVC, VP9, AV1 lub nowszego) w dowolnej kombinacji kodeków pracujących jednocześnie z 3 sesjami w rozdzielczości 4K przy 30 kl./s (z wyjątkiem 0 sesji z rozdzielczością AV1, z których maks. 2) Kodeki AV1 są wymagane tylko do obsługi rozdzielczości 1080p, ale są wymagane do obsługi 6 instancji przy 1080p30 kl./s.
    • [5.1/H-1-19] MUSI obsługiwać 3 instancje sprzętowego dekodera wideo 10-bitowego (HDR) i sprzętowych sesji kodera wideo (AVC, HEVC, VP9, AV1 lub nowszego) w dowolnej kombinacji kodeków pracującej jednocześnie z rozdzielczością 4K przy 30 kl./s (chyba że w formacie AGLR1) skonfigurowany jest maksymalnie 1 format wejściowy z wykorzystaniem co najmniej 1 sesji kodera. Generowanie metadanych HDR przez koder nie jest wymagane, jeśli kodowanie odbywa się z platformy GL. Sesje kodeka AV1 są wymagane tylko do obsługi rozdzielczości 1080p, nawet jeśli to wymaganie wymaga rozdzielczości 4K.
    • [5.1/H-1-7] Opóźnienie inicjowania kodeka musi wynosić 40 ms lub mniej w przypadku sesji kodowania 1080p lub mniejszej w przypadku wszystkich sprzętowych koderów wideo, gdy są wczytane. Wczytywanie w tym miejscu jest definiowane jako równoczesna sesja transkodowania w rozdzielczości 1080p do 720p przy użyciu sprzętowych kodeków wideo i inicjowanie nagrywania audio-wideo w jakości 1080p. W przypadku kodeka Dolby Vision czas oczekiwania na inicjowanie kodeka MUSI wynosić maksymalnie 50 ms.
    • [5.1/H-1-8] Opóźnienie inicjowania kodeka musi wynosić 30 ms lub mniej w przypadku sesji kodowania audio 128 kb/s lub mniejszej w przypadku wszystkich koderów audio, gdy są wczytane. Wczytywanie w tym miejscu jest definiowane jako równoczesna sesja transkodowania w rozdzielczości 1080p do 720p przy użyciu sprzętowych kodeków wideo i inicjowanie nagrywania audio-wideo w jakości 1080p.
    • [5.1/H-1-9] MUSI obsługiwać 2 wystąpienia sesji bezpiecznego sprzętowego dekodera wideo (AVC, HEVC, VP9, AV1 lub nowsze) w dowolnej kombinacji kodeków uruchomionej jednocześnie z rozdzielczością 4K przy 30 kl./s (z wyjątkiem AV1) zarówno w przypadku treści 8-bitowych (SDR), jak i 10-bitowych w technologii HDR. Sesje kodeka AV1 są wymagane tylko do obsługi rozdzielczości 1080p, nawet jeśli to wymaganie wymaga rozdzielczości 4K.
    • [5.1/H-1-10] MUSI obsługiwać 3 wystąpienia sesji niezabezpieczonego sprzętowego dekodera wideo1 oraz 1 instancję bezpiecznego sprzętowego dekodera wideo Sesje kodeka AV1 są wymagane tylko do obsługi rozdzielczości 1080p, nawet jeśli to wymaganie wymaga rozdzielczości 4K.
    • [5.1/H-1-11] MUSI obsługiwać bezpieczny dekoder dla każdego sprzętowego dekodera AVC, HEVC, VP9 lub AV1 na urządzeniu.
    • [5.1/H-1-12] Opóźnienie inicjowania kodeka musi wynosić 40 ms lub mniej w przypadku sesji dekodowania wideo 1080p lub krótszej w przypadku wszystkich sprzętowych dekoderów wideo, gdy są wczytane. Wczytywanie w tym miejscu jest definiowane jako równoczesna sesja transkodowania w rozdzielczości 1080p do 720p przy użyciu sprzętowych kodeków wideo i inicjowanie odtwarzania audio-wideo 1080p. W przypadku kodeka Dolby Vision czas oczekiwania na inicjowanie kodeka MUSI wynosić maksymalnie 50 ms.
    • [5.1/H-1-13] Opóźnienie inicjowania kodeka musi wynosić 30 ms lub mniej w przypadku sesji dekodowania dźwięku 128 kb/s lub mniejszej w przypadku sesji dekodowania dźwięku dla wszystkich dekoderów audio, gdy są wczytane. Wczytywanie w tym miejscu jest definiowane jako równoczesna sesja transkodowania w rozdzielczości 1080p do 720p z użyciem sprzętowych kodeków wideo wraz z inicjowaniem odtwarzania dźwięku i obrazu 1080p.
    • [5.1/H-1-14] MUSI obsługiwać dekoder sprzętowy AV1 (Main 10, poziom 4.1 i ziarnistość).
    • [5.1/H-1-15] MUSI mieć co najmniej jeden sprzętowy dekoder wideo obsługujący rozdzielczość 4K60.
    • [5.1/H-1-16] MUSI mieć co najmniej jeden koder sprzętowy obsługujący rozdzielczość 4K60.
    • W trakcie wczytywania sesji wideo 4K przy 60 klatkach na sekundę w ciągu 10 sekund NIE WOLNO upuścić więcej niż 1 klatki (tj. mniej niż 0,167%).
    • [5.3/H-1-2] W ciągu 10 sekund NIE WOLNO upuścić więcej niż 1 klatki podczas zmiany rozdzielczości w trakcie sesji wideo z 60 klatkami na sekundę podczas wczytywania sesji 4K.
    • [5.6/H-1-1] Czas oczekiwania na tonację wynosi 80 milisekund lub mniej.
    • [5.6/H-1-2] Opóźnienie transmisji danych w obie strony musi wynosić 80 milisekund lub mniej na co najmniej 1 obsługiwanej ścieżce danych.
    • [5.6/H-1-3] MUSI obsługiwać >=24-bitowy dźwięk w przypadku wyjścia stereo 3,5 mm, jeśli jest dostępny, oraz dźwięk przez USB, jeśli jest obsługiwany przez całą ścieżkę danych, aby zapewnić małe opóźnienie i strumieniowanie. W przypadku konfiguracji z małym opóźnieniem aplikacja powinna używać AAudio w trybie wywołania zwrotnego z małym czasem oczekiwania. W przypadku konfiguracji strumieniowego przesyłania danych aplikacja powinna użyć ścieżki Java AudioTrack. Zarówno w konfiguracji z krótkim czasem oczekiwania, jak i z przesyłaniem strumieniowym, ujście wyjścia HAL powinno akceptować jako docelowy format wyjściowy AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT lub AUDIO_FORMAT_PCM_FLOAT.
    • [5.6/H-1-4] MUSI obsługiwać więcej niż 4 kanały urządzeń audio USB (służą one do odtwarzania utworów przez kontrolery DJ-ów).
    • [5.6/H-1-5] MUSI obsługiwać urządzenia MIDI zgodne z klasą i zadeklarować flagę funkcji MIDI.
    • [5.6/H-1-9] MUSI obsługiwać co najmniej 12-kanałowy miksowanie. Sugeruje to możliwość otwarcia ścieżki audio z maską 7.1.4 kanału i poprawnego przestrzeliwania lub redukcji wszystkich kanałów do formatu stereo.
    • [5.6/H-SR] Zdecydowanie ZALECANE jest obsługa miksu 24-kanałowego z co najmniej obsługą masek 9.1.6 i 22.2.
    • [5.7/H-1-2] MUSI obsługiwać język MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL z poniższymi możliwościami odszyfrowywania treści.
    Minimalny rozmiar próbki 4 MiB
    Minimalna liczba próbek podrzędnych – H264 lub HEVC 32
    Minimalna liczba próbek podrzędnych – VP9 9
    Minimalna liczba próbek podrzędnych – AV1 288
    Minimalny rozmiar bufora próbki podrzędnego 1 MiB
    Minimalny rozmiar ogólnego bufora kryptograficznego 500 KiB
    Minimalna liczba równoczesnych sesji 30
    Minimalna liczba kluczy na sesję 20
    Minimalna łączna liczba kluczy (wszystkie sesje) 80
    Minimalna łączna liczba kluczy DRM (wszystkie sesje) 6
    Rozmiar wiadomości 16 KiB
    Odszyfrowane klatki na sekundę 60 kl./s
    • [5.1/H-1-17] MUSI mieć co najmniej 1 sprzętowy dekoder obrazów obsługujący profil podstawowy AVIF.
    • [5.1/H-1-18] MUSI obsługiwać koder AV1, który koduje w rozdzielczości do 480p przy 30 kl./s i 1 Mb/s.
    • [5.12/H-1-1] MUSI [5.12/H-SR] Zdecydowanie zalecamy korzystanie z funkcji Feature_HdrEditing w przypadku wszystkich koderów AV1 i HEVC dostępnych na urządzeniu.
    • [5.12/H-1-2] MUSI obsługiwać format kolorów RGBA_1010102 w przypadku wszystkich koderów AV1 i HEVC dostępnych na urządzeniu.
    • [5.12/H-1-3] MUSI reklamować obsługę rozszerzenia EXT_YUV_target w przypadku próbek z tekstur YUV zarówno w 8-, jak i 10-bitowych.
    • [7.1.4/H-1-1] MUSI mieć co najmniej 6 nakładek sprzętowych w komponencie sprzętowym jednostki przetwarzania danych (DPU), z których co najmniej 2 mogą wyświetlać 10-bitową treść wideo.

    Jeśli implementacje na urządzeniach mobilnych zwracają wartość android.os.Build.VERSION_CODES.U dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS i obejmują obsługę sprzętowego kodera AVC lub HEVC, to:

    • [5.2/H-2-1] MUSI spełniać minimalny cel jakości określony przez krzywe zniekształcenia szybkości kodera wideo w przypadku sprzętowych kodeków AVC i HEVC, zgodnie z definicją w następnej dokumentacji.

  • 2.2.7.2. Aparat:

    Zobacz wersję

    Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.U dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

    • [7,5/H-1-1] MUSI mieć główny tylny aparat o rozdzielczości co najmniej 12 megapikseli, która umożliwia nagrywanie filmów z prędkością 4 k/s przy 30 kl./s. Główny tylny aparat to tylny aparat z najniższym identyfikatorem.
    • [7.5/H-1-2] MUSI mieć główny przedni aparat o rozdzielczości co najmniej 6 megapikseli i obsługiwać nagrywanie wideo w rozdzielczości 1080p przy 30 kl./s. Główny aparat przedni to ten z najniższym identyfikatorem.
    • [7.5/H-1-3] MUSI obsługiwać właściwość android.info.supportedHardwareLevel jako FULL lub lepszą w przypadku obu aparatów głównych.
    • [7.5/H-1-4] MUSI obsługiwać CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME w obu głównych aparatach.
    • [7.5/H-1-5] MUSI mieć opóźnienie na zapis JPEG w aparacie 2 < 1000 900 ms w przypadku rozdzielczości 1080p, zgodnie z testem wydajności kamery CTS w warunkach oświetleniowych ITS (3000 K) dla obu aparatów głównych.
    • [7.5/H-1-6] MUSI mieć opóźnienie na uruchomienie kamery2 (od otwarcia kamery do pierwszej klatki podglądu) < 500 ms, zgodnie z pomiarem wydajności kamery CTS w warunkach oświetleniowych ITS (3000 K) w przypadku obu aparatów głównych.
    • [7.5/H-1-8] MUSI obsługiwać aparaty CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW i android.graphics.ImageFormat.RAW_SENSOR dla głównego tylnego aparatu.
    • [7.5/H-1-9] MUSI mieć tylny aparat główny obsługujący rozdzielczość 720p lub 1080p przy 240 kl./s.
    • [7.5/H-1-10] MUSI mieć co najmniej ZOOM_RATIO < 1,0 dla aparatów głównych, jeśli kamera RGB jest skierowana w tę samą stronę.
    • [7.5/H-1-11] MUSI zaimplementować równoczesne przesyłanie strumieniowe z przodu w głównych aparatach.
    • [7.5/H-1-12] MUSI obsługiwać CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION zarówno główny, jak i główny tylny aparat.
    • [7.5/H-1-13] MUSI obsługiwać LOGICAL_MULTI_CAMERA aparatów głównych, jeśli więcej niż 1 kamera RGB jest skierowana w tę samą stronę.
    • [7.5/H-1-14] MUSI obsługiwać STREAM_USE_CASE zarówno w przypadku głównego, jak i głównego tylnego aparatu.
    • [7.5/H-1-15] MUSI obsługiwać Bokeh i rozszerzenia trybu nocnego do aparatów głównych przez rozszerzenie CameraX i Camera2.
    • [7.5/H-1-16] MUSI obsługiwać funkcję DYNAMIC_RANGE_TEN_BIT dla głównych aparatów.
    • [7.5/H-1-17] MUSI obsługiwać tryb Control_SCENE_MODE_FACE_PRIORITY i wykrywanie twarzy (STATISTICS_FACE_DETECT_MODE_SIMPLE lub STATISTICS_FACE_DETECT_MODE_FULL) w przypadku aparatów głównych.

  • 2.2.7.3 Sprzęt:

    Zobacz wersję

    Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.U dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

    • [7.1.1.1/H-2-1] MUSI mieć rozdzielczość co najmniej 1080p.
    • [7.1.1.3/H-2-1] MUSI mieć gęstość ekranu co najmniej 400 dpi.
    • [7.1.1.3/H-3-1] MUSI mieć wyświetlacz HDR, który obsługuje średnio co najmniej 1000 nitów.
    • [7.6.1/H-2-1] MUSI mieć co najmniej 8 GB pamięci fizycznej.

  • 2.2.7.4 Skuteczność:

    Zobacz wersję

    Jeśli implementacje urządzeń mobilnych zwracają wartość android.os.Build.VERSION_CODES.U dla android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, to:

    • [8.2/H-1-1] MUSI zapewniać wydajność sekwencyjnego zapisu na poziomie co najmniej 150 MB/s.
    • [8.2/H-1-2] MUSI zapewniać wydajność zapisu przy losowym połączeniu z szybkością co najmniej 10 MB/s.
    • [8.2/H-1-3] MUSI zapewniać wydajność sekwencyjnego odczytu co najmniej 250 MB/s.
    • [8.2/H-1-4] MUSI zapewnić prędkość odczytu z szybkością losowej co najmniej 100 MB/s.
    • [8.2/H-1-5] MUSI zapewnić równoległą wydajność sekwencyjnego odczytu i zapisu przy wydajności 2-krotnej odczytu i 1-krotnego zapisu na poziomie co najmniej 50 MB/s.

  • 2.3.2 Multimedia:

    Zobacz wersję

    Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać następujące formaty kodowania wideo i udostępniać je aplikacjom innych firm:

    • [5.2/T-0-3] AV1

    Implementacje na urządzeniach telewizyjnych MUSZĄ obsługiwać następujące formaty dekodowania wideo i udostępniać je aplikacjom innych firm:

  • 2.4.5 Model zabezpieczeń:

    Zobacz wersję

    Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej jednego agenta zaufania, który implementuje systemowy interfejs API TrustAgentService:

    • [9.11.1/W-1-1] MUSI prosić użytkownika o zastosowanie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) częściej niż raz na 72 godziny.

  • 2.5.1 Sprzęt:

    Zobacz wersję

    Jeśli implementacje urządzeń obejmują obsługę radia AM/FM i udostępniają tę funkcję jakimkolwiek aplikacjom:

    • [7.4.10/A-0-1] MUSI zadeklarować obsługę FEATURE_BROADCAST_RADIO.

    Kamera zewnętrzna to kamera, która obrazuje sceny poza wdrożeniem urządzenia, np. tylny.

    Implementacje na urządzeniach motoryzacyjnych:

    • POWINIEN zawierać co najmniej jedną kamerę zewnętrzną.

    Jeśli implementacje urządzeń w samochodach obejmują kamerę w widoku zewnętrznym, w przypadku takiego aparatu:

    • [7.5/A-1-1] NIE MOŻE mieć kamer widoku zewnętrznego dostępnych za pomocą interfejsów API aparatu Androida, chyba że są one zgodne z wymaganiami dotyczącymi podstawowych urządzeń.
    • [7.5/A-SR-1] Zdecydowanie ZALECANE jest, aby nie obracać obrazu ani wyświetlać odbicia lustrzanego w poziomie.
    • [7.5/A-SR-2] Zdecydowanie ZALECANE jest rozdzielczość co najmniej 1,3 megapiksela.
    • POWINNY być sprzęt o stałej ostrości lub EDOF (rozszerzona głębia ostrości).
    • W sterowniku aparatu MOŻE być zaimplementowany sprzętowy autofokus lub programowy autofokus.

    Jeśli implementacje urządzeń samochodowych obejmują co najmniej 1 kamerę z zewnątrz i wczytują usługę systemu widoku zewnętrznego (EVS), w przypadku takiego aparatu:

    • [7.5/A-2-1] NIE MOŻE odwzorowywać podglądu z aparatu w poziomie ani obracać go.

    Implementacje na urządzeniach motoryzacyjnych:

    • MOŻE zawierać co najmniej 1 kamerę, która jest dostępna dla aplikacji innych firm.

    Jeśli implementacje urządzeń samochodowych obejmują co najmniej jedną kamerę i udostępniają ją aplikacjom innych firm, to:

    • [7.5/A-3-1] MUSI zgłosić flagę funkcji android.hardware.camera.any.
    • [7.5/A-3-2] NIE MOŻE deklarować kamery jako kamery systemowej.
    • MOŻE obsługiwać zewnętrzne kamery opisane w sekcji 7.5.3.
    • MOŻE zawierać funkcje (takie jak autofokus itp.) dostępne dla tylnych aparatów zgodnie z opisem w sekcji 7.5.1.

    Tylny aparat oznacza kamerę skierowaną do świata, która może znajdować się w dowolnym miejscu i być skierowana na zewnątrz kabiny pojazdu.

    Przedni aparat oznacza kamerę dla użytkownika, która może znajdować się w dowolnym miejscu w pojeździe i być skierowana do wnętrza kabiny pojazdu. Umożliwia robienie zdjęć użytkownika, np. podczas rozmów wideo lub w podobnych aplikacjach.

    Implementacje na urządzeniach motoryzacyjnych:

    • [7.5/A-SR-1] Zdecydowanie ZALECANE jest dodanie co najmniej jednej kamery skierowaną na świat.
    • MOŻE zawierać co najmniej 1 kamerę skierowanym do użytkownika.
    • [7.5/A-SR-2] Zdecydowanie ZALECANE jest umożliwienie jednoczesnego transmitowania treści z wielu kamer.

    Jeśli implementacje urządzeń motoryzacyjnych obejmują co najmniej jeden aparat skierowany w stronę świata, to w przypadku takiego aparatu:

    • [7.5/A-1-1] musi być zorientowany tak, aby długi wymiar kamery był zgodny z płaszczyzną X-Y osi czujnika samochodowego Androida.
    • [7.5/A-SR-3] Zdecydowanie ZALECANE jest użycie sprzętu o stałej ostrości lub EDOF (rozszerzonej głębi ostrości).
    • [7.5/A-1-2] MUSI mieć główny aparat skierowany do świata, czyli kamerę skierowaną na świat, o najniższym identyfikatorze.

    Jeśli implementacje urządzeń motoryzacyjnych obejmują co najmniej 1 aparat skierowany do użytkownika, to w przypadku takiego aparatu:

    • [7.5/A-2-1] Główny aparat skierowany do użytkownika MUSI być aparatem o najniższym identyfikatorze.
    • MOŻE być zorientowane w taki sposób, aby długi wymiar aparatu był zgodny z płaszczyźnią X-Y osi czujnika samochodowego Androida.

    Jeśli implementacje urządzeń motoryzacyjnych obejmują aparat, który jest dostępny przez interfejs API android.hardware.Camera lub android.hardware.camera2, to:

    • [7.5/A-3-1] MUSI być zgodny z podstawowymi wymaganiami dotyczącymi aparatu podanymi w sekcji 7.5.

    Jeśli implementacje urządzeń z Androidem obejmują aparat, który jest niedostępny za pomocą interfejsu API android.hardware.Camera lub android.hardware.camera2, oznacza to, że:

    • [7.5/A-4-1] MUSI być dostępny w usłudze Extended View System.

    Jeśli implementacje urządzeń w samochodach obejmują co najmniej 1 aparat dostępny przez usługę Extended View System Service, taki aparat:

    • [7.5/A-5-1] NIE MOŻE obracać obrazu z kamery ani wyświetlać jego odbicia lustrzanego w poziomie.
    • [7.5/A-SR-4] Zdecydowanie zalecana rozdzielczość to co najmniej 1,3 megapiksela.

    Jeśli implementacje urządzeń samochodowych obejmują co najmniej 1 aparat, który jest dostępny zarówno przez usługę Extended View System Service, jak i android.hardware.Camera lub interfejs API android.hardware.Camera2, wtedy w przypadku takiego aparatu:

    • [7.5/A-6-1] MUSI zgłosić ten sam identyfikator aparatu.

    Jeśli implementacje urządzeń motoryzacyjnych udostępniają zastrzeżony interfejs API aparatu:

    • [7.5/A-7-1] MUSISZ wdrożyć taki interfejs API aparatu za pomocą interfejsu API android.hardware.camera2 lub interfejsu Extended View System API.

  • 2.5.3 Oprogramowanie:

    Zobacz wersję

    Implementacje na urządzeniach motoryzacyjnych:

    • [3.8/A-0-1] NIE MOŻE zezwalać na uruchamianie działań użytkownikom z pełnym dostępem, którzy nie są obecnymi użytkownikami na pierwszym planie, na uruchamianie działań i korzystanie z interfejsu użytkownika na wyświetlaczu.

  • 2.5.5 Model zabezpieczeń:

    Zobacz wersję

    Jeśli implementacje na urządzeniach motoryzacyjnych zadeklarują android.hardware.microphone:

    • [9.8.2/A-1-1] MUSI wyświetlać wskaźnik mikrofonu, gdy aplikacja uzyskuje dostęp do danych dźwiękowych z mikrofonu, ale nie wtedy, gdy do mikrofonu uzyskują dostęp tylko funkcje HotwordDetectionService, SOURCE_HOTWORD lub ContentCaptureService lub aplikacje pełniące role wymienione w sekcji 9.1 z identyfikatorem CDD [C-4-X].
    • [9.8.2/A-1-2] NIE MOŻE ukrywać wskaźnika mikrofonu w aplikacjach systemowych, które mają widoczne interfejsy użytkownika lub mają bezpośrednią interakcję z użytkownikiem.
    • [9.8.2/A-1-3] MUSI zapewniać użytkownikowi możliwość przełączania mikrofonu w aplikacji Ustawienia.

    Jeśli implementacje na urządzeniach motoryzacyjnych zadeklarują android.hardware.camera.any, będą one wyglądać tak:

    • [9.8.2/A-2-1] MUSI wyświetlać wskaźnik aparatu, gdy aplikacja uzyskuje dostęp do danych kamery, ale nie wtedy, gdy dostęp do kamery uzyskuje tylko aplikacje pełniące role zgodnie z artykułem 9.1 Uprawnienia z identyfikatorem CDD [C-4-X][C-3-X]

    • [9.8.2/A-2-3] MUSI zapewniać użytkownikowi możliwość przełączania aparatu w aplikacji Ustawienia.
    • [9.8.2/A-2-4] MUSI wyświetlać ostatnie i aktywne aplikacje z użyciem aparatu w takiej postaci, w jakiej pochodzą z PermissionManager.getIndicatorAppOpUsageData(), wraz ze wszystkimi powiązanymi komunikatami o atrybucji.

    Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej 1 agenta zaufania, który implementuje systemowy interfejs API TrustAgentService:

    • [9.11.1/A-1-1] MUSI prosić użytkownika o użycie jednej z zalecanych podstawowych metod uwierzytelniania (np. kodu PIN, wzoru, hasła) częściej niż co 336 godzin.

3. Oprogramowanie

  • 3.1. Zgodność z zarządzanym interfejsem API:

    Zobacz wersję

    Implementacje na urządzeniach:

    • [C-0-8] NIE MOŻE obsługiwać aplikacji kierowanych na poziom API niższy niż 23.

  • 3.2.3.5 Warunkowe intencje aplikacji:

    Zobacz wersję

    Jeśli implementacje na urządzeniach zgłaszają android.hardware.nfc.uicc lub android.hardware.nfc.ese:

  • 3.3.1 Interfejsy binarne aplikacji:

    Zobacz wersję

    Implementacje na urządzeniach:

    • [C-0-12] MUSI eksportować symbole funkcji podstawowej Vulkan 1.0 Vulkan 1.1 oraz rozszerzenia VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 i VK_KHR_get_physical_device_properties2 za pomocą biblioteki libvulkan.so. Pamiętaj, że chociaż MUSZĄ być obecne wszystkie symbole, w sekcji 7.1.4.2 szczegółowo opisano wymagania dotyczące pełnego wdrożenia poszczególnych funkcji.

  • 3.8.6 Motywy:

    Zobacz wersję

    Jeśli implementacje urządzeń obejmują wyjście ekranu lub wideo:

    • [C-1-5] MUSI generować dynamiczne palety kolorów przy użyciu stylów motywów kolorystycznych wymienionych w dokumentacji Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (patrz android.theme.customization.theme_styles), czyli TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD i MONOCHROMATIC.

  • 3.8.8 Przełączanie aktywności:

    Zobacz wersję

    Jeśli implementacje urządzeń obejmujące klawisz nawigacyjny funkcji ostatnich zgodnie z opisem w sekcji 7.2.3 zmieniają interfejs:

    • [C-1-2] MUSI włączyć przypinanie ekranu i umożliwiać użytkownikowi włączenie funkcji w menu ustawień.

  • 3.9.2 Obsługa profili zarządzanych:

    Zobacz wersję

    Jeśli implementacje urządzenia zadeklarują android.software.managed_users:

    • [C-1-10] MUSI upewnić się, że zrzut ekranu jest zapisany w profilu służbowym i ma okienko topActivity z fokusem (tym, z którym użytkownik korzystał jako ostatnia podczas wszystkich aktywności) i należy do aplikacji profilu służbowego.
    • [C-1-11] NIE MOŻE przechwytywać żadnej innej zawartości ekranu (paska systemu, powiadomień ani profilu osobistego) z wyjątkiem aplikacji profilu służbowego okna/okna podczas zapisywania zrzutu ekranu w profilu służbowym, aby nie zostały zapisane w profilu służbowym.

  • 3.9.5 Zasady rozwiązywania problemów z zasadami dotyczącymi urządzeń: nowa sekcja

    Zobacz wersję

    Jeśli implementacje urządzeń rejestrują android.software.device_admin lub android.software.managed_users, oznacza to, że:

    • [C-1-1] MUSI rozwiązywać konflikty z zasadami dotyczącymi urządzeń zgodnie z dokumentacją AOSP.

5. Zgodność multimediów

  • 5.1.4 Kodowanie obrazu:

    Zobacz wersję

    Implementacje na urządzeniu MUSZĄ obsługiwać kodowanie obrazów:

    • [C-0-4] AVIF
      • Urządzenia muszą obsługiwać profil BITRATE_MODE_CQ i profil podstawowy.

  • 5.1.5 Dekodowanie obrazu:

    Zobacz wersję

    Implementacje na urządzeniu MUSZĄ obsługiwać dekodowanie tego kodowania obrazu:

    [C-0-7] AVIF (profil podstawowy)

  • 5.1.6 Szczegóły kodeków graficznych:

    Zobacz wersję

    Format/kodek Szczegóły Obsługiwane typy plików/formaty kontenerów
    JPEG Podstawowy+progresywny JPEG (.jpg)
    GIF GIF (.gif)
    PNG PNG (.png),
    BMP BMP (.bmp),
    WebP WebP (.webp)
    Nieprzetworzony ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
    HEIF Obraz, kolekcja obrazów, sekwencja obrazów HEIF (.heif), HEIC (.heic)
    AVIF (profil podstawowy) Obraz, kolekcja obrazów, profil podstawowy sekwencji obrazów Kontener HEIF (.avif)

  • 5.1.8 Lista kodeków wideo:

    Zobacz wersję

    Format/kodek Szczegóły Obsługiwane typy plików i kontenerów
    H.263
    • 3GPP (.3GPP)
    • MPEG-4 (MP4)
    • matroska (.mkv, tylko dekodowanie)
    H.264 AVC Szczegółowe informacje znajdziesz w sekcji 5.2 i 5.3
    • 3GPP (.3GPP)
    • MPEG-4 (MP4)
    • MPEG-2 TS (.ts, brak możliwości przewijania)
    • matroska (.mkv, tylko dekodowanie)
    H.265 HEVC Więcej informacji znajdziesz w sekcji 5.3.
    • MPEG-4 (MP4)
    • matroska (.mkv, tylko dekodowanie)
    MPEG-2 Profil główny
    • MPEG2-TS (.ts, bez możliwości przewijania)
    • MPEG-4 (.mp4, tylko dekodowanie)
    • matroska (.mkv, tylko dekodowanie)
    MPEG-4 SP
    • 3GPP (.3GPP)
    • MPEG-4 (MP4)
    • matroska (.mkv, tylko dekodowanie)
    VP8 Szczegółowe informacje znajdziesz w sekcjach 5.2 i 5.3
    VP9 Więcej informacji znajdziesz w sekcji 5.3.
    AV1 Szczegółowe informacje znajdziesz w sekcjach 5.2 i 5.3
    • MPEG-4 (MP4)
    • Matroska (.mkv, tylko dekodowanie)

  • 5.1.10. Charakterystyka kodeka multimediów:

    Zobacz wersję

    Jeśli implementacje urządzenia obsługują kodeki wideo:

    • [C-2-1] Wszystkie kodeki wideo MUSZĄ publikować dane o możliwej do osiągnięcia liczbie klatek w następujących rozmiarach, jeśli dany kodek jest obsługiwany:
    SD (niska jakość) SD (wysoka jakość) HD – 720p HD – 1080p UHD
    Rozdzielczość wideo
    • 176 x 144 piks. (H263, MPEG2, MPEG4)
    • 352 x 288 pikseli (koder MPEG4, H263, MPEG2)
    • 320 x 180 piks. (VP8, VP8)
    • 320 x 240 piks. (inne)
    • 704 x 576 piks. (H263)
    • 640 x 360 piks. (VP8, VP9)
    • 640 x 480 piks. (koder MPEG4)
    • 720 x 480 piks. (inne, AV1)
    • 1408 x 1152 piks. (H263)
    • 1280 x 720 piks. (inne, AV1)
    		 1920 x 1080 piks. (inne niż MPEG4 i AV1) 3840 x 2160 piks. (HEVC, VP9, AV1)

  • 5.2. Kodowanie wideo:

    Zobacz wersję

    Jeśli implementacje urządzeń obsługują koder wideo i udostępniają go aplikacjom innych firm, umożliwiają one:

    • W dwóch oknach przesuwanych NIE POWINNO być o ponad 15% wyższe niż szybkość transmisji bitów między interwałami wewnątrzklatki (I-frame).
    • Szybkość transmisji bitów NIE POWINNO przekraczać 100% w przesuwanym oknie o długości 1 sekundy.

    Jeśli implementacje urządzeń obsługują dowolny koder wideo i udostępniają go aplikacjom innych firm oraz ustaw
    MediaFormat.KEY_BITRATE_MODE na BITRATE_MODE_VBR tak, aby koder działał w trybie zmiennej szybkości transmisji bitów, to o ile nie wpływa to na minimalną jakość, zostanie poprzedzona zakodowana szybkość transmisji bitów :

    • [C-5-1] MUSI NIE POWINNY znajdować się w jednym oknie przesuwnym o więcej niż 15% szybkości transmisji bitów między interwałami w obrębie ramki (I-frame).
    • [C-5-2] MUSI NIE POWINNO przekraczać 100% szybkości transmisji bitów w oknie przesuwającym się o długości 1 sekundy.

    Jeśli implementacje urządzeń obsługują dowolny koder wideo i udostępniają go aplikacjom innych firm oraz ustaw w MediaFormat.KEY_BITRATE_MODE wartość BITRATE_MODE_CBR w celu działania kodera w trybie stałej szybkości transmisji bitów, to szybkość transmisji będzie zakodowana:

    • [C-6-1] MUSI Zdecydowanie zalecamy nie przekraczać docelowej szybkości transmisji bitów o więcej niż 15% w oknie przesuwanym o długości 1 sekundy.

  • 5.2.1 H.263:

    Zobacz wersję

    Jeśli implementacje urządzeń obsługują kodery H.263 i udostępniają je aplikacjom innych firm, muszą one:

    • [C-1-1] MUSI obsługiwać rozdzielczość QCIF (176 x 144) przy użyciu profilu podstawowego poziomu 45. Rozdzielczość SQCIF jest opcjonalna.
    • MUSI obsługiwać dynamicznie konfigurowane szybkości transmisji bitów dla obsługiwanego kodera.

  • 5.2.5 H.265:

    Zobacz wersję

    Jeśli implementacje urządzeń obsługują kodek H.265:

    • [C-1-1] MUSI obsługiwać profil główny poziomu 3 w rozdzielczości do 512 x 512.
    • POWINNO obsługiwać profile kodowania HD zgodnie z informacjami w tej tabeli.
    • Zdecydowanie zalecamy korzystanie z profilu [C-SR-1] do obsługi profilu SD 720 x 480 i profili kodowania HD zgodnie z poniższą tabelą, jeśli jest wyposażony w koder sprzętowy.

  • 5.2.6 AV1: nowa sekcja

    Zobacz wersję

    Jeśli implementacje urządzeń obsługują kodek AV1, wówczas:

    • [C-1-1] MUSI obsługiwać profil główny, w tym treści 8- i 10-bitowe.

    • [C-1-2] MUSI publikować dane dotyczące wydajności, np. tworzyć raporty z danymi o wydajności za pomocą interfejsów API getSupportedFrameRatesFor() lub getSupportedPerformancePoints(), aby uzyskać informacje o obsługiwanych rozdzielczościach podanych w tabeli poniżej.

    • [C-1-3] MUSI akceptować metadane HDR i przesyłać je do strumienia bitowego

    Jeśli koder AV1 ma przyspieszanie sprzętowe, to:

    • [C-2-1] MUSI obsługiwać profil kodowania HD1080p włącznie z tymi w tabeli:
    SD HD – 720p HD – 1080p UHD
    Rozdzielczość wideo 720 x 480 piks. 1280 x 720 piks. 1920 x 1080 piks. 3840 x 2160 piks.
    Liczba klatek w filmie 30 klatek/s 30 klatek/s 30 klatek/s 30 klatek/s
    Szybkość transmisji wideo 5 Mb/s 8 Mb/s 16 Mb/s 50 Mb/s

  • 5.3.2 H.263:

    Zobacz wersję

    Jeśli implementacje urządzeń obsługują dekodery H.263:

    • [C-1-1] MUSI obsługiwać profil Baseline Level 30 (rozdzielczości CIF, QCIF i SQCIF przy 30 kl./s 384 kb/s) i na poziomie 45 (rozdzielczości QCIF i SQCIF przy 30 kl./s 128 kb/s).

  • 5.3.9. AV1:

    Zobacz wersję

    Jeśli implementacje urządzeń obsługują kodek AV1:

    • [C-1-1] MUSI obsługiwać profil 0, w tym treści 10-bitowe.

    Jeśli implementacje urządzeń obsługują kodek AV1 i udostępniają go aplikacjom innych firm, to:

    • [C-1-1] MUSI obsługiwać profil główny, w tym treści 8- i 10-bitowe.

    Jeśli implementacje urządzeń obsługują kodek AV1 za pomocą dekodera z akceleracją sprzętową:

    • [C-2-1] MUSI być w stanie dekodować profile dekodowania wideo w rozdzielczości co najmniej 720p HD z poniższej tabeli, jeśli wysokość wskazana za pomocą metody Display.getSupportedModes() jest równa lub większa niż 720p.
    • [C-2-2] MUSI być w stanie dekodować profile dekodowania wideo w rozdzielczości co najmniej 1080p HD z poniższej tabeli, jeśli wysokość wskazana za pomocą metody Display.getSupportedModes() jest równa lub większa niż 1080p.
    SD HD – 720p HD – 1080p UHD
    Rozdzielczość wideo 720 x 480 piks. 1280 x 720 piks. 1920 x 1080 piks. 3840 x 2160 piks.
    Liczba klatek w filmie 30 klatek/s 30 klatek/s 30 klatek/s 30 klatek/s
    Szybkość transmisji wideo 5 Mb/s 8 Mb/s 16 Mb/s 50 Mb/s

    Jeśli implementacje urządzeń obsługują profil HDR za pomocą interfejsów Media API, to:

    • [C-3-1] MUSI obsługiwać wyodrębnianie i wyświetlanie metadanych HDR z strumienia bitowego lub kontenera.
    • [C-3-2] MUSI prawidłowo wyświetlać treści HDR na ekranie urządzenia lub w standardowym porcie wyjściowym wideo (np. HDMI).

  • 5.4.2 Nagrywanie w celu rozpoznawania głosu:

    Zobacz wersję

    Jeśli implementacje urządzenia zadeklarują android.hardware.microphone:

    • Należy ustawić czułość sygnału wejściowego dźwięku w taki sposób, aby źródło sygnału sinusoidalnego 1000 Hz/3 dB odtwarzane przy poziomie ciśnienia akustycznego 90 dB (SPL) (mierzonego w odległości 30 cm od mikrofonu obok mikrofonu) daje idealną odpowiedź RMS 2500 dla każdego źródła o paśmie 2500 bitów i próbkowaniu 3-bitowym w zakresie 1770 pkt.

  • 5.5.2 Efekty dźwiękowe:

    Zobacz wersję

    Jeśli implementacje urządzenia zadeklarują funkcję android.hardware.audio.output:

    • [C-1-4] MUSI obsługiwać efekty dźwiękowe ze zmiennoprzecinkowym wejściem i wyjściem.
    • [C-1-5] MUSI mieć pewność, że efekty dźwiękowe obsługują wiele kanałów, odpowiadająca FCC_LIMIT.

  • 5.6. Opóźnienie dźwięku:

    Zobacz wersję

    Jeśli implementacje urządzeń deklarują użycie funkcji android.hardware.audio.output, Zdecydowanie ZALECANE jest spełnienie lub przekroczenie tych wymagań:

    • [C-SR-4] Sygnatura czasowa wyjścia zwracana przez funkcje AudioTrack.getTimestamp i AAudioStream_getTimestamp ma dokładność z dokładnością do +/- 1 ms.

    • [C-SR-4] Czasy oczekiwania w obie strony na podstawie sygnatur czasowych zwracanych przez funkcję AAudioStream_getTimestamp ZALECANE są nie więcej niż 30 ms od zmierzonego czasu oczekiwania w przypadku operatora AAUDIO_PERFORMANCE_MODE_NONE i AAUDIO_PERFORMANCE_MODE_LOW_LATENCY w przypadku głośników, przewodowych i bezprzewodowych zestawów słuchawkowych.

7. Zgodność sprzętu

  • 7.1. Wygląd i grafika:

    Zobacz wersję

    Android ma urządzenia, które automatycznie dostosowują zasoby aplikacji i układy interfejsu użytkownika pod kątem urządzenia, aby zapewnić prawidłowe działanie aplikacji innych firm na różnych konfiguracjach sprzętowych. Na różnych wyświetlaczach i konfiguracjach sprzętowych. Wyświetlacz zgodny z Androidem to ekran, na którym są zaimplementowane wszystkie zachowania i interfejsy API opisane w artykule Omówienie zgodności ekranu dla deweloperów aplikacji na Androida, tę sekcję (7.1) i jej podsekcje, a także wszelkie dodatkowe funkcje charakterystyczne dla poszczególnych typów urządzeń opisane w sekcji 2 tej dokumentu CD. Na wyświetlaczach zgodnych z Androidem, na których mogą działać wszystkie aplikacje innych firm na Androida, implementacje urządzeń MUSZĄ prawidłowo implementować te interfejsy API i działania zgodnie z opisem w tej sekcji.

    Zacznij nowe wymagania

    Implementacje na urządzeniach:

    • [C-0-1] Domyślnie MUSI renderować aplikacje innych firm tylko na wyświetlaczach zgodnych z Androidem.

    Jednostki, do których odnoszą się wymagania w tej sekcji, są zdefiniowane w następujący sposób:

    • fizyczny rozmiar przekątnej. Wyrażona w calach odległość między dwoma przeciwległymi rogami oświetlonej części wyświetlacza.
    • gęstość punktów na cal (dpi). Liczba pikseli nałożonych na liniową, poziomą lub pionową rozpiętość 1”, wyrażona w pikselach na cal (ppi lub dpi). Jeśli podane są wartości dpi i dpi, wartości dpi zarówno w poziomie, jak i w pionie muszą mieścić się w wymienionym zakresie.
    • format obrazu. Stosunek liczby pikseli dłuższego wymiaru do krótszego wymiaru ekranu. Na przykład przy rozmiarze 480 x 854 piksele będzie to 854/480 = 1, 779, czyli w przybliżeniu „16:9”.
    • piksel niezależny od gęstości (dp). Wirtualna jednostka A jest znormalizowana do ekranu o rozdzielczości 160 dpi o gęstości 160 dpi. Dla pewnej liczby pikseli d i liczby p liczba dp niezależnych od gęstości jest obliczana w następujący sposób: piksele = dps * (gęstość/160) dp = (160 / d) * p .

  • 7.1.1.1. Rozmiar i kształt ekranu:

    Zobacz wersję

    Jeśli implementacje urządzeń obsługują ekrany o rozmiarze UI_MODE_TYPE_NORMALi zawierają zgodne z Androidem korzystają z fizycznych wyświetlaczy z zaokrąglonymi rogami, do renderowania takich ekranów:

    • [C-1-1] MUSI upewnić się, że w przypadku każdego wyświetlacza musi być spełniony co najmniej jeden z tych wymagań:
    • Promień zaokrąglonych rogów nie przekracza 38 dp.

    • Jeśli w każdym rogu logicznego wyświetlacza zakotwiczone jest pole o wymiarach 15 x 15 dp, na ekranie widoczny jest co najmniej 1 piksel.

    • POWINIEN uwzględnić opcję przejścia użytkownika na tryb wyświetlania z prostokątnymi narożnikami.

    Zacznij nowe wymagania

    Jeśli implementacje urządzeń obsługują tylko konfigurację klawiatury NO_KEYS i zamierzają zgłaszać obsługę konfiguracji w trybie interfejsu użytkownika UI_MODE_TYPE_NORMAL, to:

    • [C-4-1] MUSI mieć rozmiar co najmniej 596 dp x 384 dp, z wyłączeniem wszelkich wycięć w wyświetlaczu.

    Jeśli implementacje urządzeń obejmują składane wyświetlacze zgodne z Androidem lub zawiasy umieszczone między wieloma panelami i udostępniają takie wyświetlacze do renderowania aplikacji innych firm:

    Jeśli urządzenia są wyposażone w składany wyświetlacz zgodny z Androidem lub składany zawias między kilkoma panelami, a zawias lub zawias przecina pełnoekranowe okno aplikacji:

    • [C-3-1] MUSI zgłaszać do aplikacji położenie, granice i stan zawiasu lub zawinięcia za pomocą rozszerzeń lub interfejsów API pomocniczych.

    Jeśli implementacje urządzeń obejmują co najmniej jeden składany obszar wyświetlacza zgodny z Androidem lub zawias między kilkoma panelami zgodnymi z Androidem i udostępniają takie obszary aplikacji aplikacjom:

    • [C-4-1] MUSI zaimplementować prawidłową wersję poziomu interfejsu Window Manager Extensions API zgodnie z opisem w następnej dokumentacji.

  • 7.1.1.2. Współczynnik proporcji ekranu: usunięty

  • 7.1.1.3 Gęstość ekranu:

    Zobacz wersję

    Implementacje na urządzeniach:

    • Implementacje na urządzeniach POWINIEN zdefiniować standardową gęstość platformy Androida, która jest liczbowo najbliższa fizycznej gęstości ekranu, chyba że taka gęstość sprowadza raportowany rozmiar ekranu poniżej obsługiwanego minimum. Jeśli standardowa gęstość platformy Androida, która jest najbliższa gęstości fizycznej i fizycznej, powoduje, że rozmiar ekranu jest mniejszy niż najmniej obsługiwany obsługiwany rozmiar ekranu (320 dp), implementacje urządzeń POWINNY zgłaszać kolejną najniższą standardową gęstość platformy.

    Zacznij nowe wymagania

    • MUSI zdefiniować standardową gęstość platformy Androida, która jest liczbowo najbliższa fizycznej gęstości ekranu, lub wartość, która byłaby mapowana na te same kątowe pomiary pola widzenia na urządzeniu mobilnym.

    Jeśli implementacje urządzeń zapewniają istnieje możliwość zmiany rozmiaru wyświetlacza urządzenia, istnieje możliwość zmiany rozmiaru wyświetlacza:

    • [C-1-1] Rozmiar wyświetlacza NIE MOŻE być skalowany NIE MOŻE skalować wyświetlacza w zależności od tego, co nastąpi wcześniej, lub jego gęstość natywna DENSITY_DEVICE_STABLE nie może być większa niż 320 dp (odpowiednik kwalifikatora zasobu sw320dp).
    • [C-1-2] Rozmiar wyświetlacza NIE MOŻE być skalowany NIE MOŻE skalować wyświetlacza mniejszego niż 0,85 raza gęstości natywnej DENSITY_DEVICE_STABLE.

  • 7.1.4.2 Vulkan:

    Zobacz wersję

    Jeśli implementacje urządzeń obejmują obsługę interfejsu Vulkan w wersji 1.0 lub nowszej,:

    • [C-1-3] MUSI w pełni wdrożyć interfejs API Vulkan w wersji 1.0 Vulkan 1.1 w przypadku każdego wymienionego interfejsu API VkPhysicalDevice.

    • [C-1-5] NIE MOŻE wyliczać warstw dostarczanych przez biblioteki poza pakietem aplikacji ani udostępniać innych sposobów śledzenia lub przechwytywania interfejsu Vulkan API, chyba że aplikacja ma atrybut android:debuggable ustawiony jako true lub metadane com.android.graphics.injectLayers.enable ustawione na true .

    • POWINNO obsługiwać atrybuty VkPhysicalDeviceProtectedMemoryFeatures i VK_EXT_global_priority.

    • [C-SR-5] Zdecydowanie ZALECANE jest działanie funkcji VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory i VK_EXT_global_priority.

    • [C-SR-6] Zdecydowanie ZALECANE jest użycie narzędzia SkiaVk z HWUI.

    Jeśli implementacje urządzeń obejmują obsługę interfejsu Vulkan 1.1 i zadeklarujesz któreś z flag funkcji Vulkan opisanych tutaj , będą one:

    • [C-SR-7] Zdecydowanie ZALECANE jest udostępnienie rozszerzenia VK_KHR_external_fence_fd aplikacjom innych firm oraz umożliwienie aplikacji eksportowania ładunku ogrodzenia do i importowania ładunku ogrodzenia z deskryptorów plików POSIX w sposób opisany tutaj.

  • 7.3.10. Czujniki biometryczne:

    Zobacz wersję

    Jeśli urządzenia są wyposażone w kilka czujników biometrycznych:

    • [C-7-1] MUSI być zablokowany, gdy dane biometryczne są zablokowane (czyli gdy są wyłączone do momentu odblokowania urządzenia za pomocą podstawowego uwierzytelniania) lub gdy blokada jest ograniczona czasowo (tj. biometria jest tymczasowo wyłączona do czasu oczekiwania użytkownika na określony czas), ze względu na zbyt dużą liczbę nieudanych prób, blokowane są też wszystkie inne dane biometryczne niższej klasy biometrycznej. W przypadku blokady biometrycznej z ograniczeniami czasowymi czas do ponowienia weryfikacji biometrycznej MUSI być maksymalnym czasem wycofywania wszystkich danych biometrycznych w przypadku ograniczonego czasowo blokady.

    • [C-SR-12] Są Zdecydowanie ZALECANE, gdy dane biometryczne są zablokowane (czyli gdy są wyłączone, dopóki użytkownik nie odblokuje urządzenia za pomocą podstawowego uwierzytelniania) lub gdy blokada jest ograniczona czasowo (tj. biometria jest tymczasowo wyłączona, dopóki użytkownik nie przeczeka określonego czasu), ze względu na zbyt dużą liczbę nieudanych prób. Może też zablokować wszystkie inne klasy biometryczne. W przypadku blokady biometrycznej Zdecydowanie zalecamy, aby czas do ponowienia weryfikacji biometrycznej był maksymalnym czasem do ponowienia w przypadku wszystkich danych biometrycznych w przypadku ograniczenia czasowego.

    • [C-7-2] MUSI wymagać od użytkownika wykonania zalecanego podstawowego uwierzytelniania (np. kodu PIN, wzoru, hasła), aby zresetować licznik blokady urządzenia biometrycznego. Urządzenia biometryczne klasy 3 MOGĄ zresetować licznik blokady w przypadku zablokowanej metody biometrycznej tej samej lub niższej klasy. Urządzenia biometryczne klasy 2 lub klasy 1 NIE MOGĄ mieć możliwości dokończenia operacji resetowania blokady w przypadku biometrii.

    Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 1 (dawniej Wygoda), muszą:

    • [C-1-12] W przypadku urządzeń [C-1-12] współczynnik akceptacji podszywania się pod inne osoby musi być większy niż 40% gatunków używanych przy użyciu instrumentów atakujących (PAI), zgodnie z pomiarami protokołów testów biometrycznych Androida.

    • [C-SR-13] Zdecydowanie ZALECANE jest, aby odsetek przypadków podszywania się pod inne osoby i ich akceptacji nie przekraczał 30% gatunków używanych przy użyciu instrumentów atakujących (PAI), zgodnie z pomiarami protokołów testów biometrycznych Androida.

    • [C-SR-14] Zdecydowanie ZALECANE jest podanie klasy biometrycznej czujnika biometrycznego i powiązanego z nim ryzyka jego włączenia.

    • [C-SR-17] Zdecydowanie ZALECANE jest wdrożenie nowych interfejsów AIDL (takich jak IFace.aidl i IFingerprint.aidl).

    Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 2 (wcześniej słabe), muszą one:

    • [C-SR-15] Zdecydowanie ZALECANE jest, aby odsetek przypadków podszywania się pod inne osoby i ich akceptacji nie przekroczył 20% gatunków używanych przy użyciu instrumentów atakujących (PAI), zgodnie z pomiarami protokołów testów biometrycznych Androida.

    • [C-2-3] MUSI przeprowadzić dopasowywanie biometryczne w odizolowanym środowisku wykonawczym poza środowiskiem wykonawczym Androida i przestrzenią jądra, np. w zaufanym środowisku TEE (Trusted Execution Environment, TEE), lub w układzie z bezpiecznym kanałem w odizolowanym środowisku wykonawczym albo na chronionej maszynie wirtualnej spełniającej wymagania podane w artykule 9.17.
    • [C-2-4] MUSI mieć zaszyfrowane i uwierzytelnione kryptograficznie wszystkie dane umożliwiające identyfikację, tak aby nie można było ich pozyskać, odczytać ani zmienić poza wyodrębnionym środowiskiem wykonawczym lub za pomocą układu z bezpiecznym kanałem do izolowanego środowiska wykonawczego zgodnie z wytycznymi dotyczącymi wdrażania na stronie projektu Android Open Source lub w sekcji chronionej maszyny wirtualnej kontrolowanej przez hipernadzorcę1.
    • [C-2-5] W przypadku urządzeń biometrycznych z użyciem aparatu i uwierzytelniania biometrycznego lub rejestracji:
      • MUSI obsługiwać kamerę w trybie, który uniemożliwia odczyt i zmienianie klatek kamery poza wyodrębnionym środowiskiem wykonawczym, lub układowi z bezpiecznym kanałem prowadzącym do wyodrębnionego środowiska wykonawczego lub w chronionej maszynie wirtualnej sterowanej przez hipernadzorcę, która spełnia wymagania określone w artykule 9.17.
      • W przypadku rozwiązań RGB z jedną kamerą ramki kamery MOGĄ być odczytywane poza izolowanym środowiskiem wykonawczym na potrzeby operacji takich jak podgląd w celu rejestracji, ale NIE WOLNO ich zmieniać.
    • [C-2-7] NIE MOŻE zezwalać na niezaszyfrowany dostęp do możliwych do zidentyfikowania danych biometrycznych ani do żadnych danych pochodzących z nich (takich jak wektory dystrybucyjne) do procesora aplikacji, poza kontekstem TEE ani chronionej maszyny wirtualnej sterowanej przez hipernadzorcę, która spełnia wymagania określone w artykule 9.17. Uaktualnienie urządzeń z Androidem w wersji 9 lub starszej nie jest zwolnione z obowiązku spełnienia wymogów pakietu C-2-7.

    Jeśli implementacje urządzeń chcą traktować czujnik biometryczny jako klasę 3 (wcześniej Silne), muszą one:

    • [C-SR-16] Zdecydowanie ZALECANE jest, aby odsetek przypadków podszywania się pod inne osoby i ich akceptacji nie przekraczał 7% gatunków używanych przy użyciu instrumentów atakujących (PAI), zgodnie z pomiarami protokołów testów biometrycznych Androida.

  • 7.3.13. IEEE 802.1.15.4 (UWB)

    Zobacz wersję

    Jeśli implementacje urządzeń obejmują obsługę standardu 802.1.15.4 i udostępniają tę funkcję aplikacji innej firmy:

    • [C-1-2] MUSI zgłosić flagę funkcji sprzętowej android.hardware.uwb.
    • [C-1-3] MUSI obsługiwać wszystkie poniższe zbiory konfiguracji (wstępnie zdefiniowane kombinacje parametrów FIRA UCI) zdefiniowane w implementacji AOSP.
      • CONFIG_ID_1: zdefiniowany przez FiRa zakres pojedynczego typu STATIC STS DS-TWR, tryb odroczenia, odstęp 240 ms.
      • CONFIG_ID_2: zdefiniowany przez FiR pomiar zakresu STATIC STS DS-TWR jeden do wielu, tryb odroczenia, odstęp 200 ms. Typowy przypadek użycia: smartfon współpracuje z wieloma urządzeniami.
      • CONFIG_ID_3: taki sam jak CONFIG_ID_1, ale dane o kącie dotarcia (AoA) nie są raportowane.
      • CONFIG_ID_4: działa tak samo jak CONFIG_ID_1, z tym że włączony jest tryb zabezpieczeń P-STS.
      • CONFIG_ID_5: działa tak samo jak CONFIG_ID_2, z tym że włączony jest tryb zabezpieczeń P-STS.
      • CONFIG_ID_6: działa tak samo jak CONFIG_ID_3, z tym że włączony jest tryb zabezpieczeń P-STS.
      • CONFIG_ID_7: działa tak samo jak CONFIG_ID_2, ale włączony jest tryb indywidualnego klucza kontrolera P-STS.
    • [C-1-4] MUSI zapewniać dostępność dla użytkownika umożliwiającą włączanie i wyłączanie opcji UWB.
    • [C-1-5] MUSI wymuszać, aby aplikacje korzystające z opcji UWB miały uprawnienie UWB_RANGING (w ramach grupy uprawnień NEARBY_DEVICES).

    Zaliczenie odpowiednich testów zgodności i certyfikatów określonych przez organizacje standardowe, w tym FIRA, CCC i CSA, pomaga zapewnić prawidłowe działanie standardu 802.1.15.4.

  • 7.4.1 Telefonia:

    Zobacz wersję

    Termin „telefonia” używany w interfejsach API Androida, a ten dokument odnosi się w szczególności do sprzętu do nawiązywania połączeń głosowych i wysyłania SMS-ówlub udostępniania danych komórkowych przez komórkową sieć danych (np. GSM, CDMA, LTE, NR) GSM lub CDMA. Urządzenie obsługujące „Połączenia telefoniczne” może oferować niektóre lub wszystkie usługi połączeń, wiadomości i transmisji danych odpowiednio do swoich potrzeb.

    przez sieć GSM lub CDMA. Mimo że przełączanie pakietów w tych połączeniach głosowych nie jest możliwe, do celów Androida są one uważane za niezależne od wszelkich transmisji danych, które mogą być realizowane w tej samej sieci. Innymi słowy,funkcje „telefonii” i interfejsy API w Androidzie odnoszą się wyłącznie do połączeń głosowych i SMS-ów. Na przykład urządzenia, które nie mogą nawiązywać połączeń ani wysyłać i odbierać SMS-ów, nie są uznawane za urządzenia telefoniczne, niezależnie od tego, czy korzystają z sieci komórkowej do przesyłania danych.

  • 7.4.2 IEEE 802.11 (Wi-Fi)

    Zobacz wersję

    Jeśli implementacje urządzeń obejmują obsługę standardu 802.11 i udostępniają funkcjonalność aplikacji innej firmy:

    • [C-1-4] MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251 lub ff02::fb) przez cały czas działania, także wtedy, gdy ekran nie jest w stanie aktywnym, chyba że usunięcie lub odfiltrowanie pakietów jest konieczne, aby zmieścić się w przepisach obowiązujących na danym rynku. Dotyczy implementacji na urządzeniach z Androidem TV, nawet w stanie zasilania w trybie czuwania.

  • 7.4.3 Bluetooth:

    Zobacz wersję

    Jeśli implementacje na urządzeniach zadeklarują funkcję FEATURE_BLUETOOTH_LE:

    • [C-SR-2] Zdecydowanie ZALECANE są pomiary i skompensowanie przesunięcia Rx w celu zapewnienia, że mediana BLE RSSI wynosi -60 dBm +/-10 dB w odległości 1 m od urządzenia referencyjnego transmitującego w trybie ADVERTISE_TX_POWER_HIGH, gdzie urządzenia są zorientowane tak, że znajdują się na „płaszczyznach równoległych” z ekranami skierowanymi w tym samym kierunku.
    • [C-SR-3] Zdecydowanie ZALECANE są pomiary i kompensowanie przesunięcia teksu, tak aby mediana BLE RSSI wynosiła -60 dBm +/-10 dB w przypadku skanowania z urządzenia referencyjnego znajdującego się w odległości 1 m i przesyłania w ADVERTISE_TX_POWER_HIGH, gdzie urządzenia są zorientowane w tym samym kierunku i w „równoległych płaszczyznach” z ekranem.

    • [C-10-3] MUSI mierzyć i kompensować przesunięcie Rx, aby mediana BLE RSSI wynosiła -55 dBm +/-10 dB w odległości 1 m od urządzenia referencyjnego transmitującego z częstotliwości ADVERTISE_TX_POWER_HIGH.
    • [C-10-4] MUSI mierzyć i kompensować przesunięcie sygnału, aby mediana BLE RSSI wynosiła -55 dBm +/-10 dB podczas skanowania z urządzenia referencyjnego umieszczonego w odległości 1 m i przesyłania z odległości ADVERTISE_TX_POWER_HIGH.

    Jeśli implementacje urządzeń obsługują Bluetooth w wersji 5.0, to:

    • [C-SR-4] Zdecydowanie ZALECANE jest zapewnienie pomocy w zakresie:
    • LE 2M PHY
    • LE Codec PHY
    • LE Advertising Extension
    • Okresowe reklamy
    • Co najmniej 10 zestawów reklam.
    • Co najmniej 8 równoczesnych połączeń LE. Każde połączenie może należeć do jednej z tych ról w topologii połączeń.
    • LE Link Layer Privacy
    • Lista zadań o rozmiarze co najmniej 8 pozycji

  • 7.4.9. UWB:

    Zobacz wersję

    • [C-1-7] MUSI upewnić się, że mediana odległości w odległości 1 m od urządzenia referencyjnego mieści się w przedziale [0,75 m; 1,25 m], przy czym pomiar ten jest mierzony od górnej krawędzi urządzenia DUT. Trzymaj urządzenie ekranem w górę i pochylone pod kątem 45 stopni.

  • 7.5.1 Kamera tylna:

    Zobacz wersję

    Tylny aparat to kamera znajdująca się z boku urządzenia naprzeciw wyświetlacza. Oznacza to, że obrazuje sceny z daleka, tak jak tradycyjny aparat.

    Tylny aparat to aparat skierowany do świata, który rejestruje sceny z boku urządzenia, tak jak w przypadku tradycyjnych aparatów. W urządzeniach mobilnych jest to aparat umieszczony z boku urządzenia, naprzeciwko wyświetlacza.

  • 7.5.2 Przedni aparat:

    Zobacz wersję

    Przedni aparat to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz. To kamera zwykle używana do nagrywania obrazu użytkownika, na przykład do rozmów wideo i w podobnych aplikacjach.

    Przedni aparat to aparat skierowany do użytkownika, który jest zwykle używany do robienia zdjęć użytkownika, na przykład do rozmów wideo i podobnych aplikacji. W przypadku urządzeń mobilnych jest to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz.

  • 7.5.3 Kamera zewnętrzna:

    Zobacz wersję

    Kamera zewnętrzna to kamera, którą w każdej chwili można podłączyć fizycznie lub odłączyć od urządzenia i może być ustawiona w dowolnym kierunku, np. przez USB.

  • 7.5.4 Działanie interfejsu Camera API:

    Zobacz wersję

    Implementacje urządzeń MUSZĄ implementować poniższe zachowania w przypadku interfejsów API związanych z aparatem w przypadku wszystkich dostępnych kamer. Implementacje na urządzeniach:

    • [C-SR-1] W przypadku urządzeń z wieloma kamerami RGB znajdujących się w pobliżu i zwróconych w tym samym kierunku Zdecydowanie ZALECANE jest korzystanie z kamery logicznej, która zawiera listę możliwości CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, czyli wszystkie kamery RGB skierowane w tym kierunku jako fizyczne urządzenia podrzędne.

  • 7.5.5 Orientacja aparatu:

    Zobacz wersję

    Urządzenia, które spełniają wszystkie poniższe kryteria, są zwolnione z tego wymogu:

    • Implementacje urządzeń, których użytkownik nie może obracać, np. urządzenia motoryzacyjne.

  • 7.10. Czujnik haptyczny:

    Zobacz wersję

    Urządzenia przeznaczone do noszenia w dłoni lub noszenia w dłoni mogą zawierać ogólny czujnik haptyczny dostępny w aplikacjach np. do przyciągania uwagi za pomocą dzwonków, alarmów, powiadomień i ogólnych reakcji na dotyk.

    Jeśli implementacje urządzeń NIE zawierają tego ogólnego przeznaczenia czujnika haptycznego, zapewniają one:

    • [7.10/C] MUSI zwracać wartość fałsz dla funkcji Vibrator.hasVibrator().

    Jeśli implementacje urządzeń OBEJMUJĄ co najmniej jeden taki ogólny czujnik haptyczny:

    Jeśli implementacje urządzeń postępują zgodnie z mapowaniem stałych haptycznych:

    Wymagania związane z poszczególnymi urządzeniami znajdziesz w artykule 2.2.1.

9. Zgodność modelu zabezpieczeń

  • 9.1. Uprawnienia:

    Zobacz wersję

    Implementacje na urządzeniach:

    • [C-0-4] MUSI mieć tylko jedną implementację obu interfejsów użytkownika.

    Jeśli implementacje urządzenia wstępnie instalują pakiety z rolą System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence lub System Visual Intelligence, pakiety:

    • [C-4-1] MUSI spełniać wszystkie wymagania dotyczące implementacji na urządzeniach podane w sekcjach „9.8.6 Rejestrowanie treści” „9.8.6 Dane na poziomie systemu operacyjnego i otoczenia oraz 9.8.15 Implementacje interfejsu API w trybie piaskownicy”.

    • [C-4-2] NIE MOŻE mieć uprawnienia android.permission.INTERNET. Jest to bardziej rygorystyczne niż Zdecydowanie ZALECANE w sekcji 9.8.6.
    • [C-4-3] NIE MOŻE tworzyć powiązań z innymi aplikacjami z wyjątkiem tych aplikacji systemowych: Bluetooth, Kontakty, Media, Telefonia, SystemUI oraz komponenty udostępniające internetowe interfejsy API. Jest to bardziej rygorystyczne niż Zdecydowanie ZALECANE, o którym mowa w sekcji 9.8.6.

    Jeśli implementacje urządzeń obejmują domyślną aplikację obsługującą VoiceInteractionService:

    • [C-5-1] NIE MOŻE przyznawać ustawienia ACCESS_FINE_LOCATION jako domyślnego dla tej aplikacji.

  • 9.5. Obsługa wielu użytkowników:

    Zobacz wersję

    Jeśli po implementacji na urządzeniach dodatkowy profil użytkownika omówiony powyżej:

    • [C-4-5] MUSI wizualnie odróżniać ikony aplikacji z 2 instancjami, gdy są one wyświetlane użytkownikom.
    • [C-4-6] MUSI zapewnić dostęp użytkownika do wszystkich danych profilu klonu.
    • [C-4-7] MUSI odinstalować wszystkie aplikacje, usunąć prywatne katalogi danych aplikacji i ich zawartość, a także usunąć dane sklonowanego profilu, jeśli użytkownik zdecyduje się usunąć całe dane sklonowanego profilu.
    • POWINNY jest prosić użytkownika o usunięcie wszystkich danych sklonowanego profilu po usunięciu ostatniej sklonowanej aplikacji.
    • [C-4-8] MUSI informować użytkownika, że dane aplikacji zostaną usunięte po odinstalowaniu klona, lub umożliwiać użytkownikom zachowanie danych aplikacji po jej odinstalowaniu z urządzenia.
    • [C-4-9] Jeśli użytkownik zdecyduje się usunąć dane podczas odinstalowywania, MUSI usunąć katalogi prywatnych danych aplikacji i ich zawartość.

    • [C-4-14] MUSI mieć oddzielne uprawnienia i zarządzanie miejscem na dane dla aplikacji działających w tym dodatkowym profilu

    • [C-4-5] MUSI zezwalać na dostęp do kontaktów, które są już dostępne dla nadrzędnego profilu użytkownika, tylko aplikacjom w profilu dodatkowym z aktywnością uruchamiającą.

  • 9.7. Funkcje zabezpieczeń:

    Zobacz wersję

    Technologia bezpieczeństwa pamięci to technologia, która eliminuje co najmniej te klasy błędów o wysokim prawdopodobieństwie (> 90%) w aplikacjach, które korzystają z opcji manifestu android:memtagMode:

    • przepełnienie bufora sterty
    • użyj po bezpłatnym
    • podwójne wolne
    • wolny (wild wolne) (bez wskaźnika niemalloc)

    Implementacje na urządzeniach:

    • [C-SR-15] Zdecydowanie ZALECANE jest ustawienie parametru ro.arm64.memtag.bootctl_supported.

    Jeśli implementacje urządzeń mają ustawioną właściwość systemową ro.arm64.memtag.bootctl_supported na wartość true,:

    • [C-3-1] MUSI zezwalać właściwości systemowej arm64.memtag.bootctl na zaakceptowanie listy wartości rozdzielonych przecinkami, z odpowiednim efektem przy następnym uruchomieniu:

      • memtag: włączono technologię bezpieczeństwa pamięci zdefiniowaną powyżej
      • memtag-once: technologia Bezpieczeństwo pamięci zdefiniowana powyżej jest tymczasowo włączona i wyłączana automatycznie przy następnym uruchomieniu.
      • memtag-off: technologia Bezpieczeństwo pamięci zgodnie z definicją powyżej jest wyłączona

    • [C-3-2] MUSI umożliwiać użytkownikowi powłoki ustawienie arm64.memtag.bootctl.

    • [C-3-3] MUSI zezwalać dowolny proces na odczyt arm64.memtag.bootctl.

    • [C-3-4] MUSI ustawić arm64.memtag.bootctl na obecny stan podczas uruchamiania, MUSI też aktualizować właściwość, jeśli implementacja urządzenia umożliwia zmianę stanu bez zmiany właściwości systemu.

    • [C-SR-16] Zdecydowanie ZALECANE jest włączenie ustawienia programisty, które powoduje włączenie memtagu i ponowne uruchomienie urządzenia. W przypadku zgodnego programu rozruchowego projekt Android Open Source Project spełnia powyższe wymagania dzięki protokołowi programu rozruchowego MTE.

    • [C-SR-17] Zdecydowanie ZALECANE jest wyświetlenie ustawienia w menu Ustawienia zabezpieczeń, które umożliwia użytkownikowi włączenie usługi memtag.

  • 9.8.2 Nagrywanie:

    Zobacz wersję

    Implementacje na urządzeniach:

    • [C-0-2] MUSI wyświetlać ostrzeżenie użytkownika i uzyskać wyraźną zgodę użytkownika, zezwalając na przechwytywanie wszelkich informacji poufnych wyświetlanych na ekranie użytkownika, które zawierają dokładnie ten sam komunikat co AOSP za każdym razem za każdym razem, gdy każda sesja przechwytuje zarejestrowane / zarejestrowane za pomocą / zastrzeżone zastrzeżone przesyłanie lub nagrywanie ekranu.MediaProjection.createVirtualDisplay()VirtualDeviceManager.createVirtualDisplay() NIE MOŻE udostępniać użytkownikom możliwości wyłączenia wyświetlania zgody użytkownika w przyszłości.

    • [C-SR-1] Zdecydowanie ZALECANE jest wyświetlanie ostrzeżenia użytkownika, które jest dokładnie takie samo jak w AOSP, ale MOŻNA je zmienić, o ile wiadomość wyraźnie ostrzega użytkownika, że na jego ekranie widoczne są poufne informacje.

    • [C-0-4] NIE MOŻE umożliwiać użytkownikom wyłączenia w przyszłości próśb o zgodę na zrzut ekranu, chyba że sesja została uruchomiona przez aplikację systemową, na którą użytkownik zezwolił associate() w ramach profilu urządzenia android.app.role.COMPANION_DEVICE_APP_STREAMING lub android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING.

  • 9.8.6 Dane na poziomie systemu operacyjnego i danych otoczenia: Nazwa tej sekcji została zmieniona z Rejestrowanie treści i wyszukiwanie aplikacji na Dane na poziomie systemu operacyjnego i dane otoczenia.

    Zobacz wersję

    Android, przez interfejsy API systemowe ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query lub inne zastrzeżone środki, obsługuje mechanizm implementacji na urządzeniach, który rejestruje następujące interakcje aplikacji z danymi aplikacji: dane wrażliwe:

    • Wszelkie ekrany i inne dane wysyłane do systemu przez AugmentedAutofillService.
    • Wszelkie ekrany i inne dane dostępne przez interfejs API Content Capture.
    • Dowolny ekran lub inne dane dostępne przez interfejs API FieldClassificationService
    • Wszystkie dane aplikacji przekazywane do systemu przez interfejs API AppSearchManager i dostępne w AppSearchGlobalManager.query.

    • Wszelkie inne zdarzenia przekazywane przez aplikację do systemu za pomocą interfejsu API Content Capture lub AppSearchManager API o podobnej funkcjonalności Androida i zastrzeżonego interfejsu API.

    • Dane audio uzyskane w wyniku korzystania z usługi SpeechRecognizer#onDeviceSpeechRecognizer() za pomocą implementacji rozpoznawania mowy.
    • Dane dźwiękowe uzyskane w tle (ciągle) za pomocą usługi AudioRecord, SoundTrigger lub innych interfejsów API audio, które nie powodują wyświetlenia wskaźnika widocznego dla użytkownika
    • Dane z kamery uzyskane w tle (ciągle) za pomocą usługi CameraManager lub innych interfejsów API kamery i nie powodują wyświetlenia wskaźnika widocznego dla użytkownika

    Jeśli implementacje urządzeń rejestrują któreś z powyższych danych, to:

    • [C-1-3] MUSI wysyłać wszystkie takie dane i dziennik z urządzenia wyłącznie z użyciem mechanizmu chroniącego prywatność, chyba że za każdym razem, gdy dane są udostępniane, za wyraźną zgodą użytkownika. Mechanizm chroniący prywatność definiuje się jako „umożliwiające tylko zbiorcze analizy i uniemożliwiające dopasowywanie zarejestrowanych zdarzeń lub uzyskanych wyników do poszczególnych użytkowników”, zapobiegające otwartości danych poszczególnych użytkowników (np. wdrażanych z wykorzystaniem technologii prywatności różnicowej, takiej jak RAPPOR).

    • [C-1-5] NIE MOŻE udostępniać takich danych innym komponentom systemu operacyjnego, które nie spełniają wymagań opisanych w bieżącej sekcji (9.8.6 Rejestrowanie treści Dane na poziomie systemu operacyjnego i otoczenia), chyba że użytkownik wyrazi na to zgodę za każdym razem, gdy będą udostępniane. Jeśli taka funkcja nie jest stworzona jako interfejs API Android SDK (AmbientContext, HotwordDetectionService).

    • [C-1-6] MUSI zapewnić użytkownikowi możliwość usunięcia takich danych, które są zbierane przez ContentCaptureService wdrożenie lub przez środki zastrzeżone, jeśli gdy dane są przechowywane na urządzeniu w dowolnej formie. Jeśli użytkownik zdecyduje się usunąć dane, MUSI usunąć wszystkie zebrane dane historyczne.

    • [C-SR-3] Zdecydowanie ZALECANE są wdrożenia za pomocą interfejsu Android SDK API lub podobnego repozytorium typu open source należącego do OEM; albo muszą być wykonywane w ramach piaskownicy (patrz 9.8.15 Implementacje interfejsów API w trybie piaskownicy).

    Android w SpeechRecognizer#onDeviceSpeechRecognizer() umożliwia rozpoznawanie mowy na urządzeniu bez konieczności korzystania z sieci. Implementacja narzędzia SpeechSpeechr na urządzeniu MUSI być zgodna z zasadami opisanymi w tej sekcji.

  • 9.8.10. Raport o błędzie z łącznością:

    Zobacz wersję

    Jeśli implementacje urządzeń zadeklarują flagę funkcji android.hardware.telephony:

    • [C-1-4] Raporty wygenerowane za pomocą narzędzia BUGREPORT_MODE_TELEPHONY MUSZĄ zawierać co najmniej te informacje:
      • Zrzut SubscriptionManagerService

  • 9.8.14. Credential Manager (Menedżer danych logowania): usunięty

  • 9.8.15. Implementacje interfejsu API w trybie piaskownicy: nowa sekcja

    Zobacz wersję

    Android za pomocą zestawu delegowanych interfejsów API zapewnia mechanizm przetwarzania bezpiecznych danych na poziomie systemu operacyjnego i danych otoczenia. Takie przetwarzanie może zostać przekazane do wstępnie zainstalowanego pliku APK z podwyższonymi uprawnieniami dostępu i ograniczonymi możliwościami komunikacji. Jest to tzw. implementacja interfejsu API w trybie piaskownicy.

    Dowolne wdrożenie interfejsu API w trybie piaskownicy:

    • [C-0-1] NIE MOŻE prosić o uprawnienia INTERNET.
    • [C-0-2] MUSI uzyskać dostęp do internetu wyłącznie za pomocą uporządkowanych interfejsów API wspieranych publicznie dostępnymi implementacjami typu open source z wykorzystaniem mechanizmów chroniących prywatność lub pośrednio przez interfejsy API pakietu Android SDK. Mechanizm ochrony prywatności definiuje się jako „umożliwiające tylko zbiorcze analizy i uniemożliwiające dopasowywanie zarejestrowanych zdarzeń lub uzyskanych wyników do poszczególnych użytkowników”, zapobiegające introspektywowaniu danych poszczególnych użytkowników (np. implementowane z wykorzystaniem technologii prywatności różnicowej, takiej jak RAPPOR).
    • [C-0-3] MUSI oddzielić usługi od innych komponentów systemu (np. nie wiązać identyfikatorów usług ani procesów udostępniania) z wyjątkiem tych sytuacji:
      • Telefonia, kontakty, interfejs systemu i multimedia
    • [C-0-4] NIE MOŻE zezwalać użytkownikom na zastępowanie usług aplikacjami lub usługami, które mogą instalować użytkownicy
    • [C-0-5] MUSI zezwalać na zbieranie takich danych tylko wstępnie zainstalowanym usługom. Chyba że funkcja zastępcza jest wbudowana w AOSP (np. w aplikacjach Asystenta cyfrowego).
    • [C-0-6] NIE MOŻE zezwalać na przechwytywanie takich danych aplikacjom innym niż wstępnie zainstalowany mechanizm usług. Chyba że taka możliwość przechwytywania danych nie zostanie wdrożona za pomocą interfejsu API Android SDK.
    • [C-0-7] MUSI zapewniać koszty użytkownika w celu wyłączenia usług.
    • [C-0-8] NIE MOŻE pomijać zgody użytkownika na zarządzanie uprawnieniami Androida w ramach usług i zgodnie z modelem uprawnień Androida opisanym w Sekcji 9.1. Uprawnienia.

  • 9.8.16. Ciągły dźwięk i dane kamery: nowa sekcja

    Zobacz wersję

    Oprócz wymagań opisanych w artykułach 9.8.2 dotyczących nagrywania, danych na poziomie systemu operacyjnego i danych otoczenia oraz 9.8.15 implementacji interfejsu API w trybie piaskownicy, implementacje, które korzystają z danych audio uzyskanych w tle (w sposób ciągły) za pomocą interfejsów AudioRecord, SoundTrigger lub innych interfejsów API dźwięku LUB danych kamery uzyskanych w tle (ciągle) za pomocą CameraManagera lub innych interfejsów API aparatu:

    • [C-0-1] MUSI wymusić stosowanie odpowiedniego wskaźnika (aparatu lub mikrofonu zgodnie z sekcją 9.8.2 Nagrywanie), chyba że:
      • Dostęp jest wykonywany w ramach implementacji w trybie piaskownicy (patrz: Implementacja interfejsu API w trybie piaskownicy – patrz sekcja 9.8.15 Implementacja interfejsu API w trybie piaskownicy) za pomocą pakietu zawierającego co najmniej jedną z tych ról: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Notification Intelligence, System Notification Intelligence} lub Visual Intelligence} {/10
      • Dostęp jest wykonywany w piaskownicy, zaimplementowany i egzekwowany za pomocą mechanizmów w AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector).
      • Dostęp do dźwięku jest wykonywany w celach wspomagających przez aplikację Asystent cyfrowy, przesyłając SOURCE_HOTWORD jako źródło dźwięku.
      • Dostęp jest wykonywany przez system i implementowany za pomocą kodu open source.
    • [C-SR-1] Zdecydowanie ZALECANE jest wymaganie zgody użytkownika w przypadku każdej funkcji korzystającej z takich danych i jest domyślnie wyłączona.
    • [C-SR-2] Zdecydowanie ZALECANE jest zastosowanie tego samego traktowania (tzn. przestrzegania ograniczeń opisanych w sekcjach 9.8.2 nagrywania, danych na poziomie systemu operacyjnego i danych otoczenia 9.8.6, 9.8.15 implementacji interfejsu API w trybie piaskownicy) oraz 9.8.16 danych kamery i dźwięku podawanych z kamery ze zdalnego urządzenia do noszenia.

    Jeśli dane z kamery są dostarczane ze zdalnego urządzenia do noszenia i otwierane w formie niezaszyfrowanej poza systemem operacyjnym Android, metodą piaskownicy lub dzięki funkcjom piaskownicy opracowanym przez WearableSensingManager:

    • [C-1-1] MUSI wskazać na zdalnym urządzeniu do noszenia, aby wyświetlić tam dodatkowy wskaźnik.

    Jeśli urządzenia umożliwiają interakcję z aplikacją Asystenta cyfrowego bez przypisanego słowa kluczowego (obsługa ogólnych zapytań użytkownika lub analiza jego obecności za pomocą aparatu):

    • [C-2-1] MUSI zapewnić taką implementację w pakiecie pełniącym rolę android.app.role.ASSISTANT.
    • [C-2-2] MUSI mieć pewność, że taka implementacja korzysta z interfejsów API HotwordDetectionService lub VisualQueryDetectionService na Androida.

  • 9.8.17. Dane telemetryczne: nowa sekcja

    Zobacz wersję

    Android przechowuje dzienniki systemowe i dzienniki aplikacji za pomocą interfejsów StatsLog API. Logi te są zarządzane przez interfejsy API StatsManager, których mogą używać aplikacje systemowe z podwyższonymi uprawnieniami.

    StatsManager udostępnia również sposób gromadzenia danych z urządzeń z mechanizmem chroniącym prywatność, które są sklasyfikowane jako poufne. W szczególności interfejs API StatsManager::query umożliwia wysyłanie zapytań dotyczących kategorii danych z ograniczeniami zdefiniowanych w StatLog.

    Wszelkie zapytania dotyczące implementacji i zbieranie wskaźników z ograniczeniami w StatsManager:

    • [C-0-1] MUSI być jedyną aplikacją lub implementacją na urządzeniu i musi mieć uprawnienie READ_RESTRICTED_STATS.
    • [C-0-2] MOŻE wysyłać tylko dane telemetryczne i dziennik urządzenia przy użyciu mechanizmu chroniącego prywatność. Mechanizm chroniący prywatność definiuje się jako „umożliwiające tylko zbiorcze analizy i uniemożliwiające dopasowywanie zarejestrowanych zdarzeń lub wyników uzyskanych do poszczególnych użytkowników”, zapobiegające spojrzeniu na dane poszczególnych użytkowników (np. implementowane z wykorzystaniem technologii ochrony prywatności różnicowej, takiej jak RAPPOR).
    • [C-0-3] NIE MOŻE wiązać takich danych z żadną tożsamością użytkownika (np. kontem) na urządzeniu.
    • [C-0-4] NIE MOŻE udostępniać takich danych innym komponentom systemu operacyjnego, które nie spełniają wymagań opisanych w bieżącej sekcji (9.8.17 Ustawienia telemetryczne z zachowaniem prywatności).
    • [C-0-5] MUSI zapewniać użytkownikom korzyści w celu włączenia lub wyłączenia zbierania, wykorzystywania i udostępniania danych telemetrycznych z zachowaniem prywatności.
    • [C-0-6] MUSI zapewniać użytkownikowi możliwość usunięcia takich danych zbieranych na urządzeniu, jeśli są one przechowywane w dowolnej formie na urządzeniu. Jeśli użytkownik zdecyduje się wykasować dane, MUSI usunąć wszystkie dane zapisane na urządzeniu.
    • [C-0-7] MUSI ujawniać w repozytorium open source metodę implementacji protokołu chroniącą prywatność.
    • [C-0-8 ]MUSI egzekwować zasady ruchu wychodzącego danych opisane w tej sekcji, aby ograniczyć gromadzenie danych w kategoriach wskaźników podlegających ograniczeniom zdefiniowanych w StatsLog.

  • 9.10. Integralność urządzenia:

    Zobacz wersję

    Implementacje urządzeń

    Jeśli implementacje na urządzeniach mają możliwość weryfikowania zawartości plików na poszczególnych stronach,

    • [C-0-3 C-2-1] obsługuje kryptograficzną weryfikację zawartości pliku w porównaniu z zaufanym kluczem bez odczytu całego pliku.

    • [C-0-4 C-2-2] NIE MOŻE zezwalać na realizację żądań odczytu chronionego pliku, gdy odczytywana treść nie jest weryfikowana za pomocą zaufanego klucza nie została zweryfikowana zgodnie z [C-2-1] powyżej.

    • [C-2-4] W przypadku włączonych plików MUSI zwracać sumę kontrolną pliku w O(1).

  • 9.11. Klucze i dane logowania:

    Zobacz wersję

    System magazynu kluczy Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i wykorzystywanie ich w operacjach kryptograficznych za pomocą interfejsu KeyChain API lub interfejsu Keystore API. Implementacje na urządzeniach:

    • [C-0-3] MUSI ograniczać liczbę nieudanych prób uwierzytelnienia podstawowego.
    • [C-SR-2] Zdecydowanie ZALECANE jest wprowadzenie górnej granicy 20 nieudanych prób podstawowych uwierzytelniania. Jeśli użytkownik wyrazi zgodę i akceptuje tę funkcję, po przekroczeniu limitu nieudanych prób uwierzytelnienia należy przywrócić dane fabryczne.

    Jeśli implementacje urządzeń dodają lub zmieniają metody uwierzytelniania w celu odblokowywania ekranu blokady na podstawie znanego obiektu tajnego i używają nowej metody uwierzytelniania, która jest traktowana jako bezpieczny sposób blokowania ekranu, to:

    • [C-SR-3] Zdecydowanie ZALECANY jest kod PIN składający się z co najmniej 6 cyfr lub równoważnej 20-bitowej entropii.
    • [C-2-1] Kod PIN o długości mniejszej niż 6 cyfr NIE MOŻE umożliwiać automatycznego wprowadzenia bez interakcji użytkownika, aby nie ujawniać jego długości.

  • 9.11.1. Bezpieczny ekran blokady, uwierzytelnianie i urządzenia wirtualne:

    Zobacz wersję

    Implementacje na urządzeniach:

    • [C-0-1] MUSI ograniczać liczbę nieudanych prób uwierzytelnienia podstawowego.
    • [C-SR-5] Zdecydowanie ZALECANE jest wprowadzenie górnej granicy 20 nieudanych podstawowych prób uwierzytelniania. Jeśli użytkownik wyrazi zgodę i wyrazi zgodę na tę funkcję, po przekroczeniu limitu nieudanych prób uwierzytelnienia należy przeprowadzić „Przywracanie danych fabrycznych”.

    Jeśli implementacje urządzeń ustawiają numeryczny kod PIN jako zalecaną podstawową metodę uwierzytelniania, to:

    • [C-SR-6] Zdecydowanie ZALECANY jest kod PIN składający się z co najmniej 6 cyfr lub równoważnej 20-bitowej entropii.
    • [C-SR-7] Zdecydowanie ZALECANE jest użycie kodu PIN o długości mniejszej niż 6 cyfr, ponieważ NIE umożliwia on automatycznego wpisywania bez interakcji użytkownika i pozwala uniknąć ujawnienia długości kodu.

    Jeśli implementacje urządzeń mają bezpieczny ekran blokady i zawierają co najmniej 1 agenta zaufania, który wdraża systemowy interfejs API TrustAgentService:

    [C-7-8] Użytkownik MUSI otrzymywać potwierdzenie użycia jednej z zalecanych podstawowych metod uwierzytelniania (np.kodu PIN, wzoru, hasła) co najmniej raz na 72 godziny, chyba że zagraża to bezpieczeństwu użytkownika (np. rozpraszającym uwagę kierowcy).

    Jeśli implementacje urządzeń umożliwiają aplikacjom tworzenie dodatkowych wyświetlaczy wirtualnych i obsługują powiązane zdarzenia wejściowe, np. za pomocą VirtualDeviceManager, a ekrany nie mają oznaczenia VIRTUAL_DISPLAY_FLAG_SECURE,:

    [C-13-10] MUSI wyłączyć możliwość instalowania aplikacji inicjowanych z urządzeń wirtualnych.

  • 9.17. Platforma wirtualizacji Androida:

    Zobacz wersję

    Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework (android.system.virtualmachine.*), host Androida:

    • [C-1-1] MUSI obsługiwać wszystkie interfejsy API zdefiniowane w pakiecie android.system.virtualmachine.
    • [C-1-2] NIE MOŻE modyfikować modelu SELinux ani modelu uprawnień Androida na potrzeby zarządzania chronionymi maszynami wirtualnymi (pVM).

    • [C-1-3] NIE MOŻE modyfikować, pomijać ani zastępować reguł nigdy, które znajdują się w systemie/sepolicy dostarczonym w ramach projektu Android Open Source Project (AOSP), a zasada MUSI skompilować wszystkie obecne reguły „Nigdy nie zezwalaj”.

    • [C-1-4] MUSI zezwalać tylko na kod podpisany przez platformę oraz aplikacje z podwyższonymi uprawnieniamiNIE MOŻE umożliwiać niezaufanego kodu (np. aplikacji innych firm) na tworzenie i uruchamianie chronionej maszyny wirtualnej. Uwaga: może się to zmienić w kolejnych wersjach Androida.

    • [C-1-5] NIE MOŻE zezwalać chronionej maszynie wirtualnej pVM na wykonanie kodu, który nie jest częścią obrazu fabrycznego ani jego aktualizacji. Wszystko, co nie jest objęte weryfikacją podczas uruchamiania Androida (np. pliki pobrane z internetu lub pobrane z innego urządzenia), NIE może być uruchamiane w chronionej maszynie wirtualnej .

    • [C-1-5] MUSI zezwalać na wykonanie kodu z obrazu fabrycznego lub aktualizacji platformy, która nie jest możliwa do debugowania, tylko w przypadku aktualizacji aplikacji uprzywilejowanych.

    Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework (android.system.virtualmachine.*), każda instancja Protected Virtual Machine pVM :

    • [C-2-1] MUSI uruchamiać wszystkie systemy operacyjne dostępne w APEX wirtualizacji w chronionej maszynie wirtualnej pVM .
    • [C-2-2] NIE MOŻE zezwalać chronionej maszynie wirtualnej na uruchamianie systemu operacyjnego, który nie jest podpisany przez implementatora urządzenia lub dostawcę systemu operacyjnego.
    • [C-2-3] NIE MOŻE zezwalać chronionej maszynie wirtualnej pVM na wykonanie danych jako kodu (np. SELinux nigdy nie zezwala na wykonanie kodu).

    • [C-2-4] NIE MOŻE modyfikować, pomijać ani zastępować reguł nigdy, które znajdują się w systemie/sepolicy/mikrodroidie określonym w nadrzędnym projekcie Android Open Source Project (AOSP).

    • [C-2-5] MUSI wdrożyć chronioną maszynę wirtualną pVM zapewniające zaawansowane mechanizmy obrony (np. SELinux dla pVM) nawet w systemach operacyjnych innych niż mikrodroid.
    • [C-2-6] MUSI zadbać o to, aby maszyna wirtualna nie powiodła się oprogramowanie układowe odmawia uruchomienia, jeśli nie może zweryfikować początkowych obrazów, że nie można zweryfikować uruchomienia maszyny wirtualnej. Weryfikację należy przeprowadzić w maszynie wirtualnej.
    • [C-2-7] MUSI zadbać o to, aby maszyna wirtualna nie działała oprogramowanie układowe odmawia uruchomienia w przypadku naruszenia integralności instancji.img.

    Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework (android.system.virtualmachine.*), hipernadzorca:

    • [C-3-1] MUSI zapewnić, że strony pamięci należące wyłącznie do maszyny wirtualnej (pVM lub hosta) są dostępne tylko dla maszyny wirtualnej lub hipernadzorcy, a nie dla innych maszyn wirtualnych – ani przez zabezpieczenia, ani niechronione. NIE MOŻE umożliwiać żadnym podmiotom stowarzyszonym dostępu do strony należącej do innego podmiotu (np. innego urządzenia pVM lub hipernadzorcy), chyba że właściciel strony wyraźnie to zrobi. Obejmuje to hostowaną maszynę wirtualną. Dotyczy to dostępu zarówno przez CPU, jak i przez DMA.
    • [C-3-2] MUSI wyczyścić stronę po użyciu jej przez pVM , ale przed jej zwróceniem do hosta (np. pVM zostanie zniszczone).
    • [C-3-3SR-1] Zdecydowanie ZALECANY jest taki, aby MUSZ się upewnić, że oprogramowanie pVM zostało załadowane i wykonane przed jakimkolwiek kodem w maszynie wirtualnej.
    • [C-3-4] MUSI mieć pewność, że każda maszyna wirtualna pobiera tajny klucz, który {łańcuch certyfikatów rozruchowych (BCC) i CDI (CDI) dostarczony do instancji pVM może zostać wyodrębniony wyłącznie z tej konkretnej instancji maszyny wirtualnej i zmienia się po przywróceniu ustawień fabrycznych i OTA.

    Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework, to we wszystkich obszarach:

    • [C-4-1] NIE MOŻE udostępniać funkcji maszyny wirtualnej umożliwiającej omijanie modelu zabezpieczeń Androida.

    Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework, wykonaj te czynności:

    • [C-5-1] MUSI mieć możliwość obsługi kompilacji izolowanej, ale może wyłączyć tę funkcję podczas przesyłania aktualizacji środowiska wykonawczego ART na urządzeniu.

    Jeśli urządzenie obsługuje interfejsy API platformy Android Virtualization Framework, to w przypadku zarządzania kluczami:

    • [C-6-1] MUSI mieć dostęp do roota łańcucha DICE w punkcie, którego użytkownik nie może modyfikować, nawet na odblokowanych urządzeniach. (aby zapewnić ochronę przed podszywaniem się pod inne osoby).

    • [C-SR-26-2] Zdecydowanie ZALECANE jest użycie DICE jako mechanizmu generowania obiektów tajnych w poszczególnych maszynach wirtualnych. Funkcja DICE musi działać prawidłowo, tj. podawać poprawne wartości.

Powrót do góry