1. Wprowadzenie

Ten dokument zawiera listę wymagań, które muszą być spełnione, aby urządzenia były zgodne z Androidem 7.1.

Użycie słów „MUST”, „MUST NOT”, „REQUIRED”, „SHALL”, „SHALL NOT”, „SHOULD”, „SHOULD NOT”, „RECOMMENDED”, „MAY” i „OPTIONAL” jest zgodne ze standardem IETF zdefiniowanym w RFC2119 .

W tym dokumencie „implementator urządzenia” to osoba lub organizacja opracowująca rozwiązanie sprzętowe lub programowe z Androidem 7.1. „Wdrożeniem urządzenia” lub „wdrożeniem” jest opracowane rozwiązanie sprzętowo-programowe.

Aby można było uznać je za zgodne z Androidem 7.1, ich implementacje MUSZĄ spełniać wymagania podane w tej definicji zgodności, w tym wszelkie dokumenty włączone przez odniesienie.

Jeśli definicja lub testy oprogramowania opisane w sekcji 10 są niejasne, niepełne lub nieprecyzyjne, implementator urządzenia musi zadbać o zgodność z dotychczasowymi implementacjami.

Z tego powodu Android Open Source Project jest zarówno referencyjnym, jak i preferowanym wdrożeniem Androida. Wdrożeniom urządzeń MOCNO zaleca się, aby w jak największym stopniu opierać swoje implementacje na „upstreamowym” kodzie źródłowym dostępnym w ramach Projektu Android Open Source. Chociaż niektóre komponenty można teoretycznie zastąpić alternatywnymi implementacjami, ZDECYDOWANIE zalecamy, aby nie stosować tej praktyki, ponieważ przejście testów oprogramowania będzie znacznie trudniejsze. Obowiązkiem implementatora jest zapewnienie pełnej zgodności z zachowaniem standardowej implementacji Androida, w tym w ramach pakietu testów zgodności i poza nim. Pamiętaj, że niektóre zamiany i modyfikacje komponentów są wyraźnie zabronione w tym dokumencie.

Wiele zasobów, do których linki znajdują się w tym dokumencie, pochodzi bezpośrednio lub pośrednio z Android SDK i będzie funkcjonalnie identyczne z informacjami w dokumentacji tego pakietu. W każdym przypadku, gdy definicja zgodności lub zestaw testów zgodności są niezgodne z dokumentacją pakietu SDK, decydująca jest dokumentacja pakietu SDK. Wszelkie szczegóły techniczne podane w powiązanych zasobach w tym dokumencie są uznawane za część tej definicji zgodności.

2. Typy urządzeń

Projekt Android Open Source został wykorzystany do implementacji różnych typów i formatów urządzeń, ale wiele aspektów architektury i wymagań dotyczących zgodności zostało zoptymalizowanych pod kątem urządzeń przenośnych. Począwszy od Androida 5.0, projekt Android Open Source ma obejmować szerszą gamę typów urządzeń, jak opisano w tej sekcji.

Urządzenie przenośne z Androidem to urządzenie z Androidem, które zwykle trzyma się w ręce, np. odtwarzacze mp3, telefony i tablety. Implementacje na urządzeniach przenośnych z Androidem:

• Musi mieć wbudowany ekran dotykowy.
• MUSI mieć źródło zasilania, które zapewnia mobilność, np. baterię.

Urządzenie Android TV to implementacja urządzenia z Androidem, która jest interfejsem rozrywkowym umożliwiającym korzystanie z multimediów, filmów, gier, aplikacji lub telewizji na żywo. Urządzenia te są przeznaczone dla użytkowników siedzących w odległości około 3 metrów od ekranu (interfejs „lean back” lub „10-foot user interface”).

• Musi mieć wbudowany ekran LUB zawierać port wyjścia wideo, np. VGA, HDMI lub bezprzewodowy port do wyświetlania.
• MUSISZ zadeklarować funkcje android.software.leanback i android.hardware.type.television.

Urządzenie typu zegarek z Androidem to implementacja urządzenia z Androidem przeznaczona do noszenia na ciele, np. na nadgarstku. Takie urządzenie:

• MUSI mieć ekran o fizycznej przekątnej o długości od 1,1 do 2,5 cala.
• MUSI zadeklarować funkcję android.hardware.type.watch.
• MUSI obsługiwać uiMode = UI_MODE_TYPE_WATCH .

Wdrożeniem Androida Automotive jest panel pojazdu z Androidem jako systemem operacyjnym dla części lub całości systemu lub funkcji multimedialnych. Implementacje Androida Automotive:

• MUSI mieć ekran o fizycznej przekątnej równej lub większej niż 6 cali.
• Musisz zadeklarować funkcję android.hardware.type.automotive.
• MUSI obsługiwać uiMode = UI_MODE_TYPE_CAR .
• Implementacje Androida Automotive MUSZĄ obsługiwać wszystkie publiczne interfejsy API w przestrzeni nazw android.car.*.

Aby być zgodne z Androidem 7.1, wszystkie implementacje urządzeń z Androidem, które nie pasują do żadnego z wymienionych powyżej typów urządzeń, MUSZĄ spełniać wszystkie wymagania podane w tym dokumencie, chyba że wyraźnie określono, że dany wymóg dotyczy tylko określonego typu urządzenia z Androidem.

2.1 Konfiguracje urządzenia

Oto podsumowanie głównych różnic w konfiguracji sprzętu w zależności od typu urządzenia. (puste komórki oznaczają „MOŻNA”). W tej tabeli nie uwzględniono wszystkich konfiguracji. Więcej informacji znajdziesz w odpowiednich sekcjach dotyczących sprzętu.

Kategoria	Funkcja	Sekcja	Kamera z ręki	Telewizja	Obejrzyj	Automotive	Inne
Urządzenie wejściowe	Pad kierunkowy	7.2.2. Nawigacja bezdotykowa		MUST
	Ekran dotykowy	7.2.4. Dotykowe wprowadzanie danych	MUST		MUST		SHOULD
	mikrofon	7.8.1. Mikrofon	MUST	SHOULD	MUST	MUST	SHOULD
Czujniki	Akcelerometr	7.3.1 Akcelerometr	SHOULD		SHOULD		SHOULD
	GPS	7.3.3. GPS	SHOULD			SHOULD
Łączność	Wi-Fi	7.4.2. IEEE 802.11	SHOULD	SHOULD		SHOULD	SHOULD
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	SHOULD	SHOULD			SHOULD
	Bluetooth	7.4.3. Bluetooth	SHOULD	MUST	MUST	MUST	SHOULD
	Bluetooth Low Energy	7.4.3. Bluetooth	SHOULD	MUST	SHOULD	SHOULD	SHOULD
	Radio komórkowe	7.4.5. Minimalna obsługa sieci				SHOULD
	Tryb urządzenia peryferyjnego USB lub hosta	7.7. USB	SHOULD			SHOULD	SHOULD
Urządzenie wyjściowe	Głośniki lub gniazda wyjścia audio	7.8.2. Wyjście audio	MUST	MUST		MUST	MUST

3. Oprogramowanie

3.1. Zgodność z zarządzanym interfejsem API

Zarządzane środowisko wykonywania kodu bajtowego Dalvik jest głównym narzędziem do uruchamiania aplikacji na Androida. Interfejs programowania aplikacji (API) Androida to zestaw interfejsów platformy Androida udostępnionych aplikacjom działającym w środowisku zarządzanego środowiska wykonawczego. Implementacje na urządzeniu MUSZĄ zawierać pełne implementacje, w tym wszystkie udokumentowane zachowania, wszystkich udokumentowanych interfejsów API udostępnionych przez pakiet SDK Androida lub wszystkich interfejsów API oznaczonych znacznikiem „@SystemApi” w kodziku źródłowym Androida.

Implementacje na urządzeniach MUSZĄ obsługiwać i zachowywać wszystkie klasy, metody i powiązane elementy oznaczone adnotacją TestApi (@TestApi).

Implementacje na urządzeniach NIE MOGĄ pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów ani podpisów interfejsów API, odbiegać od udokumentowanego zachowania lub zawierać operacji niemających żadnego efektu, z wyjątkiem przypadków, w których jest to wyraźnie dozwolone przez tę definicję zgodności.

Ta definicja zgodności zezwala na pominięcie przez implementacje urządzeń niektórych typów sprzętu, dla których Android zawiera interfejsy API. W takich przypadkach interfejsy API MUSZĄ być nadal dostępne i działać w rozsądny sposób. Więcej informacji o wymaganiach w tym scenariuszu znajdziesz w sekcji 7.

3.1.1. Rozszerzenia Androida

Android obsługuje rozszerzanie zarządzanych interfejsów API przy zachowaniu tej samej wersji interfejsu API. Implementacje urządzeń z Androidem MUSZĄ wstępnie wczytywać implementację AOSP zarówno współdzielonej biblioteki ExtShared, jak i usług ExtServices w wersjach nowszych lub równych minimalnym wersjom dozwolonym dla każdego poziomu interfejsu API. Na przykład implementacje na urządzeniach z Androidem 7.0 i poziomem interfejsu API 24 MUSZĄ zawierać co najmniej wersję 1.

3.2. Zgodność z interfejsem API w wersji próbnej

Oprócz zarządzanych interfejsów API z sekcji 3.1 Android zawiera też „miękki” interfejs API działający tylko w czasie wykonywania. Dotyczy to na przykład intencji, uprawnień i podobnych aspektów aplikacji na Androida, których nie można wymusić w czasie kompilacji aplikacji.

3.2.1. Uprawnienia

Implementatorzy urządzeń MUSZĄ obsługiwać i stosować wszystkie stałe uprawnienia zgodnie z dokumentacją na stronie referencyjnej dotyczącej uprawnień . Pamiętaj, że w sekcji 9 znajdziesz dodatkowe wymagania dotyczące modelu zabezpieczeń Androida.

3.2.2. Parametry tworzenia

Interfejsy API Androida zawierają wiele stałych wartości w klasie android.os.Build, które opisują bieżące urządzenie. Aby zapewnić spójne, sensowne wartości we wszystkich implementacjach urządzeń, w tabeli poniżej podajemy dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi implementacje urządzeń MUSZĄ być zgodne.

Parametr	Szczegóły
VERSION.RELEASE	Wersja aktualnie uruchomionego systemu Android w czytelnym dla człowieka formacie. To pole MUSI zawierać jeden z ciągów znaków zdefiniowanych w sekcji 7.1 .
WERSJ.SDK	Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 7.1 to pole MUSI zawierać wartość całkowitą 7.1_INT.
VERSION.SDK_INT	Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 7.1 to pole MUSI zawierać wartość całkowitą 7.1_INT.
VERSION.INCREMENTAL	Wartość wybrana przez implementatora urządzenia, która w czytelnym dla człowieka formacie wskazuje konkretną wersję aktualnie działającego systemu Android. Tej wartości NIE MOŻNA używać ponownie w przypadku różnych wersji udostępnionych użytkownikom. Typowe zastosowanie tego pola to wskazanie, który numer wersji lub identyfikator zmiany kontroli źródłowej został użyty do wygenerowania wersji. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („”).
PLANSZOWE	Wartość wybrana przez implementatora urządzenia, która identyfikuje konkretny sprzęt wewnętrzny używany przez urządzenie w czytelnym dla człowieka formacie. Możliwe zastosowanie tego pola to wskazanie konkretnej wersji płyty głównej zasilającej urządzenie. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
MARKA	Wartość odzwierciedlająca nazwę marki powiązaną z urządzeniem, jaką znają użytkownicy. MUSI być w formacie zrozumiałym dla człowieka i POWINIEN wskazywać producenta urządzenia lub markę firmy, pod którą urządzenie jest sprzedawane. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
SUPPORTED_32_BIT_ABIS	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
SUPPORTED_64_BIT_ABIS	Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
CPU_ABI	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
CPU_ABI2	Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3. Zgodność z natywnym interfejsem API.
URZĄDZENIE	Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodową identyfikującą konfigurację funkcji sprzętowych i wzornictwo przemysłowe urządzenia. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Nazwa urządzenia NIE MOŻE się zmieniać w trakcie trwania produktu.
FINGERPRINT	Ciąg znaków jednoznacznie identyfikujący tę kompilację. Powinien być zrozumiały dla człowieka. Musi on być zgodny z tym szablonem: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Przykład: acme/myproduct/     mydevice:7.1/LMYXX/3359:userdebug/test-keys Odcisk palca NIE MOŻE zawierać znaków odstępów. Jeśli inne pola w powyższym szablonie zawierają znaki odstępu, należy je zastąpić w odciskach palców wersji innym znakiem, np. podkreśleniem („_”). Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII.
SPRZĘT	Nazwa sprzętu (z wiersza poleceń jądra lub katalogu /proc). Powinien być zrozumiały dla człowieka. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”.
HOST	Ciąg tekstowy jednoznacznie identyfikujący hosta, na którym została utworzona kompilacja, w formacie zrozumiałym dla człowieka. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („”).
ID	Identyfikator wybrany przez implementatora urządzenia, który odnosi się do konkretnej wersji w czytelnym dla człowieka formacie. To pole może być takie samo jak android.os.Build.VERSION.INCREMENTAL, ale POWINIEN zawierać wartość wystarczająco znaczącą, aby użytkownicy mogli odróżnić różne wersje oprogramowania. Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9._-]+$”.
PRODUCENT	Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („”).
MODEL	Wartość wybrana przez implementatora urządzenia zawierająca nazwę urządzenia znaną użytkownikowi. Powinna to być ta sama nazwa, pod którą urządzenie jest sprzedawane i reklamowane. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („”).
USŁUGA	Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodową konkretnego produktu (SKU), która MUSI być unikalna w ramach tej samej marki. Musi być czytelny dla człowieka, ale niekoniecznie musi być widoczny dla użytkowników. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^[a-zA-Z0-9_-]+$”. Nazwa produktu NIE MOŻE się zmieniać w trakcie jego cyklu życia.
SERIAL	Numer seryjny sprzętu, który MUSI być dostępny i niepowtarzalny w przypadku urządzeń z tym samym MODELEM i PRODUCENTEM. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego „^([a-zA-Z0-9]{6,20})$”.
TAGI	Lista tagów wybranych przez implementatora urządzenia, oddzielona przecinkami, która dodatkowo rozróżnia kompilację. To pole MUSI zawierać jedną z wartości odpowiadających 3 typowym konfiguracjom podpisywania na platformie Androida: release-keys, dev-keys, test-keys.
CZAS	Wartość reprezentująca sygnaturę czasową utworzenia kompilacji.
TYP	Wartość wybrana przez implementatora urządzenia, która określa konfigurację kompilacji w czasie wykonywania. To pole MUSI zawierać jedną z wartości odpowiadających 3 typowym konfiguracjom środowiska uruchomieniowego Androida: user, userdebug lub eng.
UŻYTKOWNIK	Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował wersję. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („”).
SECURITY_PATCH	Wartość wskazująca poziom aktualizacji zabezpieczeń danej kompilacji. Musi on oznaczać, że kompilacja nie jest w żaden sposób narażona na żadne z problemów opisanych w wybranym Biuletynie bezpieczeństwa Androida. Musi on mieć format [RRRR-MM-DD] i być zgodny z definiowanym ciągiem znaków w publicznym biuletynie bezpieczeństwa Androida lub powiadomieniu o bezpieczeństwie Androida, np. „2015-11-01”.
BASE_OS	Wartość reprezentująca parametr FINGERPRINT kompilacji, która jest identyczna z tą kompilacją z wyjątkiem poprawek podanych w komunikatach o bezpieczeństwie Androida. Musi on zwracać prawidłową wartość. Jeśli taka wersja nie istnieje, musi zwracać pusty ciąg znaków („”).

3.2.3. Zgodność z zamiarem

3.2.3.1. Główne intencje aplikacji

Intencje Androida umożliwiają komponentom aplikacji żądanie funkcji od innych komponentów Androida. Projekt upstream Androida zawiera listę aplikacji uznawanych za podstawowe aplikacje na Androida, które implementują kilka wzorów intencji do wykonywania typowych działań. Podstawowe aplikacje na Androida to:

• Zegar biurkowy
• Przeglądarka
• Kalendarz
• kontakty,
• Galeria
• GlobalSearch
• Wyrzutnia
• Muzyka
• Ustawienia

Implementacje urządzeń MUSZĄ zawierać podstawowe aplikacje Androida lub komponenty implementujące te same wzorce intencji zdefiniowane przez wszystkie komponenty Activity lub Service tych podstawowych aplikacji Androida udostępnione innym aplikacjom, pośrednio lub bezpośrednio za pomocą atrybutu android:exported.

3.2.3.2. Rozwiązywanie intencji

Ponieważ Android jest platformą rozszerzalną, implementacje urządzeń MUSZĄ umożliwiać zastąpienie przez aplikacje innych firm każdego wzorca intencji, do którego odwołuje się sekcja 3.2.3.1. Implementacja natywnej wersji systemu Android na licencji open source umożliwia to domyślnie. Implementatorzy urządzeń NIE MOGĄ dołączać specjalnych uprawnień do korzystania z tych wzorów intencji przez aplikacje systemowe ani uniemożliwiać aplikacjom innych firm wiązania się z tymi wzorami i przejmowania nad nimi kontroli. Zakaz ten obejmuje m.in. wyłączenie interfejsu „Wybór”, który umożliwia użytkownikowi wybór spośród wielu aplikacji obsługujących ten sam wzór intencji.

Implementacje na urządzeniach MUSZĄ zawierać interfejs użytkownika umożliwiający modyfikowanie domyślnej aktywności dla intencji.

Implementacje urządzeń mogą jednak udostępniać domyślne działania w przypadku określonych wzorów URI (np. http://play.google.com), gdy domyślne działanie udostępnia bardziej szczegółowy atrybut dla URI danych. Na przykład wzór filtra intencji określający identyfikator URI danych „http://www.android.com” jest bardziej szczegółowy niż podstawowy wzór intencji przeglądarki „http://”.

Android zawiera też mechanizm, który umożliwia aplikacjom innych firm deklarowanie wiarygodnego domyślnego zachowania w przypadku łączenia aplikacji w przypadku niektórych typów intencji identyfikatora URI internetowego. Gdy w wzorach filtrów intencji aplikacji zdefiniowane są takie autorytatywne deklaracje, implementacje na urządzeniach:

• MUSI próbować weryfikować wszystkie filtry intencji, wykonując kroki weryfikacji zdefiniowane w specyfikacji Digital Asset Links, jak jest to implementowane przez menedżera pakietów w górnym projekcie Android Open Source.
• MUSI próbować weryfikować filtry intencji podczas instalacji aplikacji i ustawić wszystkie zweryfikowane filtry intencji UIR jako domyślne moduły obsługi aplikacji dla ich identyfikatorów UIR.
• MOGĄ ustawić określone filtry intencji URI jako domyślne moduły obsługi aplikacji dla swoich identyfikatorów URI, jeśli zostaną one pomyślnie zweryfikowane, ale inne potencjalne filtry URI nie przejdą weryfikacji. Jeśli implementacja urządzenia wykonuje tę funkcję, MUSI udostępnić użytkownikowi odpowiednie zastąpienia wzorca na podstawie URI w menu ustawień.
• MUSI udostępniać użytkownikom ustawienia dotyczące linków do aplikacji w ustawieniach aplikacji w ten sposób:
  • Użytkownik MUSI mieć możliwość globalnego zastąpienia domyślnego zachowania linków aplikacji, aby było ono takie: zawsze otwierać, zawsze pytać lub nigdy nie otwierać. Musi to dotyczyć wszystkich docelowych filtrów identyfikatorów URI.
  • Użytkownik MUSI mieć możliwość wyświetlenia listy docelowych filtrów intencji URI.
  • Implementacja urządzenia MOŻE umożliwić użytkownikowi zastąpienie konkretnych docelowych filtrów intencji URI, które zostały zweryfikowane, na podstawie każdego filtra intencji.
  • Implementacja na urządzeniu MUSI umożliwiać użytkownikom wyświetlanie i zastępowanie konkretnych docelowych filtrów URI, jeśli implementacja na urządzeniu pozwala na przeprowadzenie weryfikacji niektórych docelowych filtrów URI, a nie innych.

3.2.3.3. Przestrzenie nazw intencji

Implementacje urządzeń NIE MOGĄ zawierać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub rozgłaszania intencji za pomocą działania, kategorii lub innego ciągu klucza w przestrzeni nazw android. lub com.android.. Implementatorzy urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe intencje lub wzorce transmisji intencji za pomocą działania, kategorii lub innego ciągu kluczy w przestrzeni pakietu należącej do innej organizacji. Implementatorzy urządzeń NIE MOGĄ zmieniać ani rozszerzać żadnych wzorów intencji używanych przez podstawowe aplikacje wymienione w sekcji 3.2.3.1 . Implementacje na urządzeniach MOGĄ zawierać wzorce intencji, które używają przestrzeni nazw wyraźnie i wyraźnie powiązanych z własną organizacją. Ten zakaz jest analogiczny do zakazu dotyczącego zajęć z języka Java w sekcji 3.6 .

3.2.3.4. Zamiary związane z transmisją

Aplikacje innych firm polegają na platformie, która wysyła określone intencje, aby powiadomić je o zmianach w środowisku sprzętowym lub programowym. Urządzenia zgodne z Androidem MUSZĄ wysyłać publiczne intencje transmisji w odpowiedzi na odpowiednie zdarzenia systemowe. Intencje przesyłania są opisane w dokumentacji pakietu SDK.

3.2.3.5. Domyślne ustawienia aplikacji

Android zawiera ustawienia, które umożliwiają użytkownikom łatwe wybieranie domyślnych aplikacji, np. na ekran główny lub do wysyłania SMS-ów. W przypadku urządzeń, w których ma to sens, implementacje MUSZĄ udostępniać podobne menu ustawień i być zgodne z wzorcem filtra intencji oraz metodami interfejsu API opisanymi w dokumentacji pakietu SDK, jak pokazano poniżej.

Implementacje na urządzeniu:

• MUSI obsługiwać działanie okna android.settings.HOME_SETTINGS, aby wyświetlić menu ustawień domyślnej aplikacji ekranu głównego, jeśli implementacja urządzenia zgłasza android.software.home_screen.
• Jeśli implementacja urządzenia zgłasza android.hardware.telephony, aplikacja MUSI udostępnić menu ustawień, które wywołuje działanie android.provider.Telephony.ACTION_CHANGE_DEFAULT, aby wyświetlić okno dialogowe umożliwiające zmianę domyślnej aplikacji do obsługi SMS-ów.
• MUSI obsługiwać działanie okna dialogowego android.settings.NFC_PAYMENT_SETTINGS, aby wyświetlić domyślne menu ustawień aplikacji do obsługi funkcji Tap & Pay, jeśli implementacja urządzenia zgłasza android.hardware.nfc.hce.
• W przypadku implementacji na urządzeniu, która zwraca android.hardware.telephony, MUSISZ obsługiwać działanie android.telecom.action.CHANGE_DEFAULT_DIALER, aby wyświetlić okno dialogowe umożliwiające użytkownikowi zmianę domyślnej aplikacji Telefon .
• Musi obsługiwać działanie android.settings.ACTION_VOICE_INPUT_SETTINGS, gdy urządzenie obsługuje interfejs VoiceInteractionService, oraz wyświetlać domyślne menu ustawień aplikacji do wprowadzania i obsługi poleceń głosowych.

3.3. Zgodność z natywnym interfejsem API

Zgodność kodu natywnego jest trudna do osiągnięcia. Dlatego ZALECAMY implementującym urządzenie korzystanie z implementacji bibliotek wymienionych poniżej z upstreamowego projektu Android Open Source.

3.3.1. Interfejsy binarne aplikacji

Zarządzany kod bajtowy Dalvik może wywoływać kod natywny dostarczony w pliku APK aplikacji jako plik .so ELF skompilowany dla odpowiedniej architektury sprzętowej urządzenia. Ponieważ kod natywny jest w dużej mierze zależny od podstawowej technologii procesora, Android definiuje w NDK Androida kilka interfejsów binarnych aplikacji (ABI). Implementacje na urządzeniu MUSZĄ być zgodne z co najmniej 1 definicją ABI i MUSZĄ być zgodne z Android NDK, jak pokazano poniżej.

Jeśli implementacja urządzenia obejmuje obsługę interfejsu ABI Androida, to:

• MUSI zawierać obsługę kodu działającego w środowisku zarządzanym, aby wywoływać kod natywny, korzystając ze standardowej semantyki interfejsu JNI (Java Native Interface).
• Musi być zgodny pod względem źródłowym (czyli zgodny z nagłówkiem) i binarnym (w przypadku interfejsu ABI) z każdą wymaganą biblioteką na liście poniżej.
• Musi obsługiwać odpowiedni interfejs ABI 32-bitowy, jeśli obsługiwany jest jakikolwiek interfejs ABI 64-bitowy.
• Musisz dokładnie podać natywny interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie za pomocą parametrów android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS i android.os.Build.SUPPORTED_64_BIT_ABIS. Każdy z tych parametrów to oddzielona przecinkami lista interfejsów ABI posortowanych od najbardziej do najmniej preferowanego.
• NALEŻY zgłaszać za pomocą powyższych parametrów tylko te ABI, które są udokumentowane i opisane w najnowszej wersji dokumentacji Androida NDK dotyczącej zarządzania ABI. NALEŻY też uwzględnić obsługę rozszerzenia Advanced SIMD (znanego też jako NEON).
• NALEŻY go skompilować, używając kodu źródłowego i plików nagłówków dostępnych w upstreamowym projekcie Android Open Source.

Pamiętaj, że w przyszłych wersjach NDK na Androida możemy dodać obsługę dodatkowych ABI. Jeśli implementacja urządzenia jest niezgodna z dotychczasowym wstępnie zdefiniowanym ABI, NIE MOŻE zgłaszać obsługi żadnych ABI.

Aplikacje zawierające kod natywny muszą mieć dostęp do tych interfejsów API:

• libandroid.so (obsługa natywnej aktywności Androida)
• libc (biblioteka C)
• libcamera2ndk.so
• libdl (linker dynamiczny)
• libEGL.so (własne zarządzanie powierzchnią OpenGL)
• libGLESv1_CM.so (OpenGL ES 1.x)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.x)
• libicui18n.so
• libicuuc.so
• libjnigraphics.so
• liblog (rejestrowanie na Androidzie)
• libmediandk.so (obsługa natywnych interfejsów API multimediów)
• libm (biblioteka matematyczna)
• libOpenMAXAL.so (obsługa OpenMAX AL 1.0.1)
• libOpenSLES.so (obsługa dźwięku OpenSL ES 1.0.1)
• libRS.so
• libstdc++ (minimalna obsługa C++)
• libvulkan.so (Vulkan)
• libz (kompresja Zlib)
• Interfejs JNI
• Obsługa OpenGL, jak opisano poniżej

W przypadku wymienionych powyżej bibliotek natywnych implementacja na urządzeniu NIE MOŻE dodawać ani usuwać publicznych funkcji.

Biblioteki natywne, które nie są wymienione powyżej, ale są implementowane i udostępniane w AOSP jako biblioteki systemowe, są zarezerwowane i NIE MOGĄ być udostępniane aplikacjom innych firm kierowanym na interfejs API na poziomie 24 lub wyższym.

Implementacje urządzeń mogą DODAĆ biblioteki inne niż AOSP i udostępnić je bezpośrednio jako interfejs API aplikacjom innych firm, ale DODATKOWE biblioteki POWINNY BYĆ w katalogu /vendor/lib lub /vendor/lib64 i MUSZĄ BYĆ wymienione w katalogu /vendor/etc/public.libraries.txt .

Pamiętaj, że implementacje na urządzeniu MUSZĄ zawierać plik libGLESv3.so i MUSZĄ eksportować wszystkie symbole funkcji OpenGL ES 3.1 i pakietu rozszerzeń Androida zgodnie z definicją w wersji NDK android-24. Chociaż wszystkie symbole muszą być obecne, należy w pełni zaimplementować tylko funkcje odpowiadające wersjom i rozszerzeniom OpenGL ES, które są obsługiwane przez urządzenie.

3.3.1.1. Biblioteki graficzne

Vulkan to interfejs API o niskim obciążeniu, który umożliwia tworzenie wydajnej grafiki 3D. Implementacje na urządzeniach, nawet jeśli nie obsługują interfejsów Vulkan API, MUSZĄ spełniać te wymagania:

• Należy zawsze udostępnić natywną bibliotekę o nazwie libvulkan.so , która eksportuje symbole funkcji dla podstawowego interfejsu Vulkan 1.0 API oraz rozszerzeń VK_KHR_surface , VK_KHR_android_surface i VK_KHR_swapchain.

Implementacje na urządzeniach, jeśli obejmują obsługę interfejsów Vulkan API:

• MUSI zgłosić co najmniej 1 VkPhysicalDevices w ramach wywołania vkEnumeratePhysicalDevices.
• Każdy z wymienionych interfejsów VkPhysicalDevices MUSI w pełni implementować interfejs Vulkan 1.0.
• Musisz podać prawidłowe flagi funkcji PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL i PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.
• MUSI wyliczać warstwy zawarte w bibliotekach natywnych o nazwie libVkLayer*.so w katalogu bibliotek natywnych pakietu aplikacji za pomocą funkcji vkEnumerateInstanceLayerProperties i vkEnumerateDeviceLayerProperties w libvulkan.so
• NIE MOŻE wymieniać warstw udostępnianych przez biblioteki spoza pakietu aplikacji ani udostępniać innych sposobów śledzenia lub przechwytywania interfejsu Vulkan API, chyba że aplikacja ma atrybut android:debuggable=”true”.

Implementacje na urządzeniach, jeśli nie obsługują interfejsów Vulkan API:

• Musisz zgłosić 0 VkPhysicalDevices w wywołaniu vkEnumeratePhysicalDevices.
• NIE MOŻNA deklarować żadnej z flag funkcji Vulkan PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL i PackageManager#FEATURE_VULKAN_HARDWARE_VERSION .

3.3.2. Zgodność z 32-bitowym kodem natywnym ARM

Architektura ARMv8 wycofuje kilka operacji procesora, w tym niektóre operacje używane w dotychczasowym kodzie natywnym. Na 64-bitowych urządzeniach ARM te wycofane operacje MUSZĄ być dostępne dla 32-bitowego kodu natywnego ARM, albo przez obsługę natywnego procesora, albo przez emulację oprogramowania:

• Instrukcje dotyczące SWP i SWPB
• Instrukcja SETEND
• CP15ISB, CP15DSB i CP15DMB

Starsze wersje NDK na Androida używały /proc/cpuinfo do wykrywania funkcji procesora z 32-bitowego kodu natywnego ARM. Aby zapewnić zgodność z aplikacjami utworzonymi za pomocą tego NDK, urządzenia MUSZĄ zawierać te wiersze w pliku /proc/cpuinfo, gdy jest on odczytywany przez 32-bitowe aplikacje ARM:

• „Funkcje:”, a następnie lista opcjonalnych funkcji procesora ARMv7 obsługiwanych przez urządzenie.
• „CPU architecture: ”, a następnie liczba całkowita określająca najwyższą obsługiwaną architekturę ARM urządzenia (np. „8” w przypadku urządzeń ARMv8).

Te wymagania mają zastosowanie tylko wtedy, gdy plik /proc/cpuinfo jest odczytywany przez 32-bitowe aplikacje ARM. Urządzenia nie powinny zmieniać pliku /proc/cpuinfo, gdy jest on odczytywany przez aplikacje 64-bitowe ARM lub inne niż ARM.

3.4. Zgodność z przeglądarką

3.4.1. Zgodność WebView

Funkcja platformy android.software.webview MUSI być zgłaszana na dowolnym urządzeniu, które zapewnia pełną implementację interfejsu API android.webkit.WebView. Nie wolno jej zgłaszać na urządzeniach bez pełnej implementacji interfejsu API. Implementacja Androida Open Source używa kodu z projektu Chromium do implementacji android.webkit.WebView . Ponieważ niemożliwe jest opracowanie kompleksowego zestawu testów dla systemu renderowania stron internetowych, implementatorzy urządzeń MUSZĄ używać określonej kompilacji Chromium w ramach implementacji WebView. Więcej szczegółów:

• Implementacje android.webkit.WebView na urządzeniu MUSZĄ być oparte na kompilacji Chromium z wyższego poziomu projektu Android Open Source na Androida 7.1. Ta kompilacja zawiera określony zestaw funkcji i poprawek zabezpieczeń dla WebView.

• Ciąg tekstowy klienta użytkownika przesyłany przez WebView MUSI mieć format:

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • Wartość ciągu $(VERSION) MUSI być taka sama jak wartość android.os.Build.VERSION.RELEASE.
  • Wartość ciągu $(MODEL) MUSI być taka sama jak wartość android.os.Build.MODEL.
  • Wartość ciągu znaków $(BUILD) MUSI być taka sama jak wartość android.os.Build.ID.
  • Wartość ciągu $(CHROMIUM_VER) MUSI być wersją Chromium w poprzednim projekcie open source Android.
  • Implementacje urządzeń MOGĄ pomijać w ciągu danych klienta użytkownika ciąg znaków Mobile.

Komponent WebView powinien obsługiwać jak najwięcej funkcji HTML5. Jeśli obsługuje daną funkcję, powinien być zgodny ze specyfikacją HTML5.

3.4.2. Zgodność z przeglądarką

Samodzielna przeglądarka MOŻE być o zasadzie oparta na innej technologii przeglądarki niż WebKit. Jednak nawet jeśli używana jest inna przeglądarka, komponent android.webkit.WebView udostępniany aplikacjom innych firm MUSI być oparty na WebKit, zgodnie z opisem w sekcji 3.4.1 .

W ramach implementacji MOŻNA dostarczyć niestandardowy ciąg znaków klienta użytkownika w samodzielnej aplikacji przeglądarki.

Samodzielna aplikacja przeglądarki (oparta na przeglądarce WebKit lub na przeglądarce innej firmy) POWINNA obsługiwać jak najwięcej funkcji HTML5. Implementacje na urządzeniach muszą co najmniej obsługiwać te interfejsy API związane z HTML5:

• pamięć podręczna aplikacji/operacja offline
• tag<video>
• geolocation

Ponadto implementacje urządzeń MUSZĄ obsługiwać interfejs webstorage API HTML5/W3C i POWINNY wspierać interfejs IndexedDB API HTML5/W3C . Pamiętaj, że organizacje opracowujące standardy dotyczące tworzenia stron internetowych przechodzą na IndexedDB zamiast Web Storage, dlatego IndexedDB ma stać się wymaganym komponentem w przyszłej wersji Androida.

3.5. Zgodność zachowania interfejsu API

Zachowanie każdego z typów interfejsu API (zarządzanego, miękkiego, natywnego i internetowego) musi być zgodne z preferowaną implementacją Android Open Source Project . Niektóre konkretne obszary zgodności to:

• Urządzenia NIE MOGĄ zmieniać działania ani semantyki standardowego zamiaru.
• Urządzenia NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia danego typu komponentu systemu (np. usługi, aktywności, dostawcy treści itp.).
• Urządzenia NIE MOGĄ zmieniać semantyki standardowych uprawnień.

Powyższa lista nie jest wyczerpująca. Pakiet Compatibility Test Suite (CTS) testuje znaczne części platformy pod kątem zgodności behawioralnej, ale nie wszystkie. Implementator musi zadbać o zachowanie zgodności z Android Open Source Project. Dlatego implementatorzy urządzeń powinni w miarę możliwości używać kodu źródłowego dostępnego w ramach Projektu Android Open Source, a nie ponownie wdrażać istotnych części systemu.

3.6. Nazwy katalogów interfejsu API

Android stosuje konwencje dotyczące przestrzeni nazw pakietów i klas zdefiniowane przez język programowania Java. Aby zapewnić zgodność z aplikacjami innych firm, implementatorzy urządzeń NIE MOGĄ wprowadzać żadnych zabronionych modyfikacji (patrz poniżej) w następujących przestrzeniach nazw pakietów:

• java.*
• javax.*
• sun.*
• android.*
• com.android.*,

Zabronione modyfikacje:

• Implementacje na urządzeniach NIE MOGĄ modyfikować publicznie udostępnionych interfejsów API na platformie Androida przez zmianę podpisów metod lub klas albo usunięcie klas lub pól klas.
• Implementatorzy urządzeń MOGĄ modyfikować podstawową implementację interfejsów API, ale takie modyfikacje NIE MOGĄ wpływać na opisane działanie i sygnatura języka Java interfejsów API udostępnionych publicznie.
• Implementatorzy urządzeń NIE MOGĄ dodawać do powyższych interfejsów API żadnych publicznie dostępnych elementów (takich jak klasy, interfejsy, pola lub metody do istniejących klas lub interfejsów).

„Publicznie dostępny element” to dowolna konstrukcja, która nie jest ozdobiona znacznikiem „@hide” używanym w poprzednim kodzie źródłowym Androida. Innymi słowy, implementatorzy urządzeń NIE MOGĄ udostępniać nowych interfejsów API ani zmieniać istniejących interfejsów API w wymienionych powyżej przestrzeniach nazw. Implementatorzy urządzeń MOGĄ wprowadzać modyfikacje tylko na potrzeby wewnętrzne, ale te modyfikacje NIE MOGĄ być reklamowane ani w inny sposób udostępniane deweloperom.

Implementatorzy urządzeń MOGĄ dodawać niestandardowe interfejsy API, ale nie mogą umieszczać ich w przestrzeni nazw należącej do innej organizacji ani do niej odwołującej się. Na przykład implementatorzy urządzeń NIE MOGĄ dodawać interfejsów API do przestrzeni nazw com.google.* ani podobnych: może to robić tylko Google. Podobnie Google NIE MOŻE dodawać interfejsów API do przestrzeni nazw innych firm. Jeśli implementacja na urządzeniu zawiera niestandardowe interfejsy API spoza standardowego zasięgu nazewnictwa Androida, muszą one zostać zapakowane w bibliotece współdzielonej Androida, aby tylko aplikacje, które z nich korzystają (za pomocą mechanizmu <uses-library>), odczuwały skutki zwiększonego zużycia pamięci przez te interfejsy API.

Jeśli implementator urządzenia zamierza ulepszyć jedną z wymienionych powyżej przestrzeni nazw pakietów (np. przez dodanie nowej przydatnej funkcji do istniejącego interfejsu API lub dodanie nowego interfejsu API), powinien odwiedzić stronę source.android.com i rozpocząć proces przesyłania zmian i kodu zgodnie z informacjami na tej stronie.

Pamiętaj, że powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku programowania Java. Celem tej sekcji jest po prostu wzmocnienie tych konwencji i ustanowienie ich jako wiążących poprzez uwzględnienie w tej definicji zgodności.

3.7. Zgodność w czasie działania

Implementacje na urządzeniu MUSZĄ obsługiwać pełny format Dalvik Executable (DEX) oraz specyfikację i semantykę bajtkodów Dalvik . Implementatorzy urządzeń powinni używać ART, referencyjnej implementacji upstream formatu wykonywalnego Dalvik oraz systemu zarządzania pakietami referencyjnej implementacji.

Implementacje na urządzeniach MUSZĄ skonfigurować środowisko uruchomieniowe Dalvik w taki sposób, aby przydzielać pamięć zgodnie z górną platformą Androida i jak określono w tabeli poniżej. (Definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1). Pamiętaj, że podane poniżej wartości pamięci są wartościami minimalnymi, a implementacje urządzeń MOŻE przydzielić więcej pamięci na aplikację.

Układ ekranu	Gęstość ekranu	Minimalna pamięć aplikacji
Android Watch	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36 MB
	280 dpi
	320 dpi (xhdpi)	48 MB
	360 dpi
	400 dpi (400 dpi)	56 MB
	420 dpi (420 dpi)	64 MB
	480 dpi (xxhdpi)	88 MB
	560 dpi (560 dpi)	112 MB
	640 dpi (xxxhdpi)	154 MB
małe/normalne	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	48 MB
	240 dpi (hdpi)
	280 dpi
	320 dpi (xhdpi)	80 MB
	360 dpi
	400 dpi (400 dpi)	96 MB
	420 dpi (420 dpi)	112 MB
	480 dpi (xxhdpi)	128 MB
	560 dpi (560 dpi)	192 MB
	640 dpi (xxxhdpi)	256 MB
duża	120 dpi (ldpi)	32 MB
	160 dpi (mdpi)	48 MB
	213 dpi (tvdpi)	80 MB
	240 dpi (hdpi)
	280 dpi	96 MB
	320 dpi (xhdpi)	128 MB
	360 dpi	160 MB
	400 dpi (400 dpi)	192 MB
	420 dpi (420 dpi)	228 MB
	480 dpi (xxhdpi)	256 MB
	560 dpi (560 dpi)	384 MB
	640 dpi (xxxhdpi)	512 MB
bardzo duża	120 dpi (ldpi)	48 MB
	160 dpi (mdpi)	80 MB
	213 dpi (tvdpi)	96 MB
	240 dpi (hdpi)
	280 dpi	144 MB
	320 dpi (xhdpi)	192 MB
	360 dpi	240 MB
	400 dpi (400 dpi)	288 MB
	420 dpi (420 dpi)	336 MB
	480 dpi (xxhdpi)	384 MB
	560 dpi (560 dpi)	576 MB
	640 dpi (xxxhdpi)	768 MB

3.8. Zgodność interfejsu

3.8.1. Menu z aplikacjami (ekran główny)

Android zawiera aplikację uruchamiającą (ekran główny) i obsługuje aplikacje innych firm, które mogą zastąpić aplikację uruchamiającą urządzenie (ekran główny). Implementacje urządzeń, które umożliwiają zastąpienie ekranu głównego aplikacji innych firm, MUSZĄ deklarować funkcję platformy android.software.home_screen.

3.8.2. Widżety

Android definiuje typ komponentu oraz odpowiadający mu interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie „widżetu aplikacji” użytkownikowi. Funkcja ta jest MOCNO POLECANA w przypadku implementacji na urządzeniach przenośnych. Implementacje urządzeń, które obsługują umieszczanie widżetów na ekranie głównym, MUSZĄ spełniać te wymagania i deklarować obsługę funkcji platformy android.software.app_widgets.

• Aplikacje uruchamiające MUSZĄ zawierać wbudowane wsparcie dla widżetów aplikacji i zapewniać użytkownikom możliwość dodawania, konfigurowania, wyświetlania i usuwania widżetów bezpośrednio w aplikacji uruchamiającej.
• Implementacje na urządzeniach MUSZĄ umożliwiać renderowanie widżetów o standardowym rozmiarze siatki 4 x 4. Szczegółowe informacje znajdziesz w wytycznych dotyczących projektowania widżetów aplikacji w dokumentacji pakietu Android SDK.
• Implementacje urządzeń, które obejmują obsługę ekranu blokady, MOGĄ obsługiwać widżety aplikacji na ekranie blokady.

3.8.3. Powiadomienia

Android zawiera interfejsy API, które umożliwiają deweloperom powiadamianie użytkowników o istotnych zdarzeniach za pomocą funkcji sprzętowych i programowych urządzenia.

Niektóre interfejsy API umożliwiają aplikacjom wyświetlanie powiadomień lub zwracanie uwagi za pomocą sprzętu, w tym dźwięku, wibracji i światła. Implementacje na urządzeniach MUSZĄ obsługiwać powiadomienia, które korzystają z funkcji sprzętowych zgodnie z opisem w dokumentacji pakietu SDK oraz w zakresie możliwym w przypadku sprzętu implementowanego na urządzeniu. Jeśli na przykład implementacja urządzenia zawiera wibrator, musi on prawidłowo implementować interfejsy API wibracji. Jeśli implementacja urządzenia nie zawiera sprzętu, odpowiednie interfejsy API MUSZĄ być zaimplementowane jako no-ops. Szczegółowe informacje na ten temat znajdziesz w sekcji 7 .

Ponadto implementacja MUSI prawidłowo renderować wszystkie zasobów (ikony, pliki animacji itp.) udostępnione w interfejsach API lub w przewodniku po stylu ikon w pasku stanu/systemowym, który w przypadku urządzenia z Androidem TV obejmuje możliwość niewyświetlania powiadomień. Implementatorzy urządzeń MOGĄ zapewnić użytkownikom alternatywną obsługę powiadomień niż ta oferowana przez referencyjną implementację Androida w wersji open source. Jednak takie alternatywne systemy powiadomień MUSZĄ obsługiwać istniejące zasoby powiadomień, jak opisano powyżej.

Android obsługuje różne powiadomienia, takie jak:

• Powiadomienia z zawartością . Interaktywne widoki dla powiadomień o trwających działaniach.
• Powiadomienia z ostrzeżeniem . Widoki interaktywne, z którymi użytkownicy mogą wchodzić w interakcje lub je zamykać bez opuszczania bieżącej aplikacji.
• Powiadomienia na ekranie blokady . Powiadomienia wyświetlane na ekranie blokady z dokładną kontrolą widoczności.

Implementacje na urządzeniach z Androidem, gdy takie powiadomienia są widoczne, MUSZĄ prawidłowo wykonywać powiadomienia Rich i Heads-up oraz zawierać tytuł/nazwę, ikonę i tekst zgodnie z dokumentacją interfejsów API Androida .

Android zawiera interfejsy Notification Listener Service API, które umożliwiają aplikacjom (po wyraźnym włączeniu przez użytkownika) otrzymywanie kopii wszystkich powiadomień w miarę ich publikowania lub aktualizowania. Implementacje na urządzeniu MUSZĄ prawidłowo i natychmiast wysyłać powiadomienia w całości do wszystkich zainstalowanych usług odsłuchujących włączonych przez użytkownika, w tym wszystkich metadanych dołączonych do obiektu Notification.

Implementacje na urządzeniach przenośnych MUSZĄ obsługiwać funkcje aktualizowania, usuwania, odpowiadania na powiadomienia i zbiorcze powiadomień zgodnie z opisem w tej sekcji .

Implementacje na urządzeniach ręcznych MUSZĄ zawierać:

• możliwość sterowania powiadomieniami bezpośrednio w pasku powiadomień.
• Wizualne elementy umożliwiające wywołanie panelu sterowania w panelu powiadomień.
• Możliwość BLOKOWANIA, WYCISZENIA i RESETOWANIA ustawień powiadomień z poziomu panelu sterowania w aplikacji oraz w aplikacji Ustawienia.

Wszystkie 6 bezpośrednich podklas klasy Notification.Style class MUSZĄ być obsługiwane zgodnie z opisem w dokumentacji SDK .

Implementacje urządzeń, które obsługują funkcję DND (Nie przeszkadzać), MUSZĄ spełniać te wymagania:

• NALEŻY zaimplementować aktywność, która będzie odpowiadać na intencję ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. W przypadku implementacji z UI_MODE_TYPE_NORMAL musi to być aktywność, w której użytkownik może zezwolić lub odmówić aplikacji dostępu do konfiguracji zasad Nie przeszkadzać.
• MUSI, gdy implementacja urządzenia umożliwia użytkownikowi zezwolenie lub odmowę zezwolenia aplikacjom innych firm na dostęp do konfiguracji trybu Nie przeszkadzać, wyświetlać automatyczne reguły trybu Nie przeszkadzać utworzone przez aplikacje obok reguł utworzonych przez użytkownika i zdefiniowanych wstępnie.
• MUSI uwzględniać wartości suppressedVisualEffects przekazywane w ramach NotificationManager.Policy. Jeśli aplikacja ma ustawione flagi SUPPRESSED_EFFECT_SCREEN_OFF lub SUPPRESSED_EFFECT_SCREEN_ON, POWINNA poinformować użytkownika, że efekty wizualne są tłumione w menu ustawień DND.

3.8.4. Szukaj

Android zawiera interfejsy API, które umożliwiają deweloperom włączanie wyszukiwania w aplikacjach i udostępnianie danych aplikacji w globalnym wyszukiwaniu systemowym. Ogólnie ta funkcja składa się z jednego interfejsu użytkownika obejmującego cały system, który umożliwia wpisywanie zapytań, wyświetlanie sugestii podczas pisania i wyświetlanie wyników. Interfejsy API Androida umożliwiają deweloperom ponowne używanie tego interfejsu do udostępniania wyszukiwania w ich własnych aplikacjach oraz dostarczania wyników do wspólnego globalnego interfejsu wyszukiwania.

Implementacje na urządzeniach z Androidem powinny zawierać wyszukiwanie globalne, czyli jeden wspólny interfejs wyszukiwania w całym systemie, który może wyświetlać sugestie w czasie rzeczywistym w odpowiedzi na dane wejściowe użytkownika. Implementacje urządzeń powinny zawierać interfejsy API, które umożliwiają deweloperom ponowne użycie tego interfejsu użytkownika w celu zapewnienia wyszukiwania w ich własnych aplikacjach. Implementacje urządzeń, które implementują interfejs wyszukiwarki globalnej, MUSZĄ implementować interfejsy API, które umożliwiają aplikacjom innych firm dodawanie sugestii do pola wyszukiwania, gdy jest ono używane w trybie wyszukiwania globalnego. Jeśli nie są zainstalowane żadne aplikacje innych firm korzystające z tej funkcji, domyślnie powinny wyświetlać się wyniki i sugestie wyszukiwarki internetowej.

Implementacje urządzeń z Androidem powinny, a implementacje Androida Automotive muszą zawierać na urządzeniu asystenta, który będzie obsługiwał działanie pomocy .

Android zawiera też interfejsy API Asystenta, które umożliwiają aplikacjom określenie, ile informacji o bieżącym kontekście ma być udostępniane Asystentowi na urządzeniu. Implementacje urządzeń obsługujące działanie Assist MUSZĄ wyraźnie wskazywać użytkownikowi, kiedy kontekst jest udostępniany, wyświetlając białe światło na krawędziach ekranu. Aby zapewnić użytkownikowi wyraźną widoczność, wskazanie MUSI mieć czas trwania i jasność zgodną z implementacją projektu Open Source Android.

To wskazanie MOŻE być domyślnie wyłączone w przypadku wstępnie zainstalowanych aplikacji korzystających z interfejsu Assist i VoiceInteractionService API, jeśli są spełnione wszystkie te wymagania:

• Wstępnie zainstalowana aplikacja MUSI poprosić o udostępnienie kontekstu tylko wtedy, gdy użytkownik wywołał aplikację w jeden z tych sposobów i aplikacja działa na pierwszym planie:

  • wywołanie słowa-klucza
  • wciśnięcie przycisku nawigacyjnego ASSIST, przycisku lub gestu nawigacyjnego

• Implementacja na urządzeniu MUSI umożliwiać wyświetlenie informacji w mniej niż 2 krokach od menu ustawień domyślnego mikrofonu i asystenta (patrz sekcja 3.2.3.5).

3.8.5. Toasty

Aplikacje mogą używać interfejsu Toast API do wyświetlania użytkownikowi krótkich niemodalnych ciągów znaków, które znikają po krótkim czasie. Implementacje urządzeń MUSZĄ wyświetlać komunikaty typu Toast od aplikacji do użytkowników końcowych w sposób dobrze widoczny.

3.8.6. Motywy

Android udostępnia „motywy” jako mechanizm, który pozwala aplikacjom stosować style w całej aktywności lub aplikacji.

Android zawiera rodzinę motywów „Holo” jako zestaw zdefiniowanych stylów, z których deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd i wykonanie motywu Holo zgodnie z definicją w pakiecie Android SDK. Implementacje na urządzeniach NIE MOGĄ zmieniać żadnych atrakcji motywu Holo udostępnianych aplikacjom.

Android zawiera rodzinę motywów „Material” jako zestaw zdefiniowanych stylów, z których deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd i wrażenia do motywu projektowego na różnych typach urządzeń z Androidem. Implementacje urządzeń MUSZĄ obsługiwać rodzinę motywów „Material” i NIE MOGĄ zmieniać żadnych atrybutów motywu Material ani zasobów udostępnianych aplikacjom.

Android zawiera też rodzinę motywów „Domyślny motyw urządzenia” jako zestaw zdefiniowanych stylów, z których deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd i sposób obsługi motywu urządzenia zgodnie z definicją implementatora urządzenia. Implementacje na urządzeniu mogą modyfikować atrybuty motywu domyślnego urządzenia udostępniane aplikacjom.

Android obsługuje wariant motywu z przezroczystymi paskami systemu, co pozwala deweloperom aplikacji wypełnić obszar za paskiem stanu i paskiem nawigacji treściami aplikacji. Aby zapewnić spójne środowisko deweloperów w ramach tej konfiguracji, ważne jest, aby styl ikony paska stanu był zachowany na różnych urządzeniach. Dlatego implementacje urządzeń z Androidem MUSZĄ używać koloru białego do ikon stanu systemu (takich jak siła sygnału i poziom naładowania baterii) i powiadomień wysyłanych przez system, chyba że ikona wskazuje stan problemowy lub aplikacja prosi o jasny pasek stanu za pomocą flagi SYSTEM_UI_FLAG_LIGHT_STATUS_BAR. Gdy aplikacja poprosi o jasny pasek stanu, implementacje na urządzeniach z Androidem MUSZĄ zmienić kolor ikon stanu systemu na czarny (szczegóły znajdziesz w R.style).

3.8.7. Animowane tapety

Android definiuje typ komponentu oraz odpowiadający mu interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie użytkownikowi co najmniej 1 animowanej tapety. Tapety na żywo to animacje, wzory lub podobne obrazy z ograniczonymi możliwościami wprowadzania danych, które wyświetlają się jako tapeta za innymi aplikacjami.

Urządzenie jest uznawane za zdolne do niezawodnego wyświetlania tapet na żywo, jeśli może odtwarzać wszystkie tapety na żywo bez ograniczeń funkcjonalności, przy rozsądznej częstotliwości klatek i bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują, że tapety lub aplikacje ulegają awarii, nie działają prawidłowo, zużywają zbyt dużo energii procesora lub baterii albo działają z niedopuszczalnie niską liczbą klatek na sekundę, sprzęt jest uznawany za niezdolny do obsługi tapety na żywo. Na przykład niektóre tapety na żywo mogą używać kontekstu OpenGL 2.0 lub 3.x do renderowania treści. Tapeta na żywo nie będzie działać prawidłowo na sprzęcie, który nie obsługuje wielu kontekstów OpenGL, ponieważ używanie przez nią tego kontekstu może powodować konflikty z innymi aplikacjami, które również go używają.

Implementacje urządzeń, które mogą niezawodnie wyświetlać tapety na żywo zgodnie z opisem powyżej, POWINNY implementować tapety na żywo. W przypadku implementacji MUSI być używana flaga funkcji platformy android.software.live_wallpaper.

3.8.8. Przełączanie aktywności

Dotychczasowy kod źródłowy Androida obejmuje ekran przeglądu, czyli interfejs użytkownika na poziomie systemu służący do przełączania zadań i wyświetlania ostatnio używanych czynności i zadań za pomocą miniatury graficznego stanu aplikacji w momencie, gdy użytkownik ostatnio ją zamknął. Implementacje na urządzeniach, które obejmują klawisz nawigacji funkcji ostatnich, zgodnie z opisem w sekcji 7.2.3, MOGĄ zmienić interfejs, ale MUSZĄ spełniać te wymagania:

• MUSI obsługiwać co najmniej 20 wyświetlanych aktywności.
• POWINIEN wyświetlać co najmniej tytuł 4 aktywności naraz.
• MUSI implementować zachowanie przypinania ekranu i zapewnić użytkownikowi menu ustawień, aby włączyć tę funkcję.
• NALEŻY wyświetlić kolor wyróżnienia, ikonę i tytuł ekranu w ostatnich.
• NALEŻY wyświetlić opcję zamknięcia („x”), ale MOŻNA opóźnić to, aż użytkownik wejdzie w interakcję z ekranami.
• NALEŻY wdrożyć skrót, który umożliwia łatwe przełączanie się do poprzedniej aktywności.
• MOŻNA wyświetlać powiązane ostatnie elementy jako grupę, która porusza się razem.
• POWINIEN wywoływać szybkie przełączanie między 2 ostatnio używanymi aplikacjami, gdy dwukrotnie kliknie się przycisk funkcji Ostatnio używane.
• POWINIEN aktywować tryb wielookien podzielonego ekranu (jeśli jest obsługiwany), gdy przycisk funkcji ostatnich aplikacji jest długo naciśnięty.

W przypadku implementacji urządzeń MOCNO zaleca się używanie na ekranie przeglądu interfejsu Androida (lub podobnego interfejsu opartego na miniaturach).

3.8.9. Zarządzanie wejściami

Android obsługuje zarządzanie wprowadzaniem danych oraz edytory metod wprowadzania danych innych firm. Implementacje urządzeń, które umożliwiają użytkownikom korzystanie z metod wprowadzania danych innych firm na urządzeniu, MUSZĄ deklarować funkcję platformy android.software.input_methods i obsługiwać interfejsy IME zgodnie z definicją w dokumentacji pakietu Android SDK.

Implementacje urządzeń, które deklarują funkcję android.software.input_methods, MUSZĄ udostępniać użytkownikom mechanizm dodawania i konfigurowania metod wprowadzania danych innych firm. Implementacje na urządzeniu MUSZĄ wyświetlać interfejs ustawień w odpowiedzi na intencję android.settings.INPUT_METHOD_SETTINGS.

3.8.10. Sterowanie multimediami na ekranie blokady

W Androidzie 5.0 interfejs Remote Control Client API został wycofany na rzecz szablonu powiadomienia multimedialnego, który umożliwia aplikacjom multimedialnym integrację z elementami sterowania odtwarzaniem wyświetlanymi na ekranie blokady. Implementacje urządzeń, które obsługują ekran blokady (z wyjątkiem implementacji Androida Automotive lub zegarka) MUSZĄ wyświetlać powiadomienia na ekranie blokady, w tym szablon powiadomienia multimedialnego.

3.8.11. Wygaszacze ekranu (wcześniej Dreams)

Android obsługuje ekrany blokady interaktywnej , które wcześniej nazywano „marzeniami”. Wygaszacze ekranu umożliwiają użytkownikom korzystanie z aplikacji, gdy urządzenie podłączone do źródła zasilania jest nieaktywne lub zadokowane w stacji dokującej. Urządzenia z Androidem Watch MOGĄ stosować wygaszacze, ale inne typy urządzeń powinny uwzględniać obsługę wygaszaczy i zapewniać użytkownikom opcję ustawień, aby mogli skonfigurować wygaszacz w odpowiedzi na intencję android.settings.DREAM_SETTINGS.

3.8.12. Lokalizacja

Jeśli urządzenie ma czujnik sprzętowy (np. GPS), który może udostępniać współrzędne lokalizacji, tryby lokalizacji MUSZĄ być wyświetlane w menu Lokalizacja w Ustawieniach.

3.8.13. Unicode i czcionka

Android obsługuje emotikony zdefiniowane w Unicode 9.0 . Wszystkie implementacje na urządzeniach MUSZĄ umożliwiać renderowanie tych emotikonów w kolorze, a gdy implementacje na urządzeniach z Androidem zawierają IME, POWINNY one udostępniać użytkownikowi metodę wprowadzania tych emotikonów.

Urządzenia przenośne z Androidem powinny obsługiwać emotikony z różnymi odcieniami skóry i różnymi rodzinami emotikonów, zgodnie z raportem technicznym Unicode nr 51 .

Android obsługuje czcionkę Roboto 2 z różnymi grubościami – bezszeryfowa cienka, bezszeryfowa jasna, bezszeryfowa średnia, bezszeryfowa czarna, bezszeryfowa skompresowana, bezszeryfowa skompresowana jasna – które MUSZĄ być uwzględnione w przypadku języków dostępnych na urządzeniu oraz pełnego zakresu Unicode 7.0 w przypadku alfabetów łacińskiego, greckiego i cyrylicy, w tym zakresów A, B, C i D alfabetu łacińskiego rozszerzonego oraz wszystkich znaków w bloku symboli walutowych w Unicode 7.0.

3.8.14. Wiele okien

Implementacja urządzenia MOŻE nie implementować żadnych trybów wielookien, ale jeśli ma możliwość wyświetlania wielu aktywności jednocześnie, MUSI implementować takie tryby wielookienne zgodnie z zachowaniem aplikacji i interfejsami API opisanymi w dokumentacji dotyczącej obsługi trybu wielookiennego w pakiecie SDK Androida oraz spełniać te wymagania:

• Aplikacje mogą wskazywać, czy są zdolne do działania w trybie wielookiennym w pliku AndroidManifest.xml, albo jawnie za pomocą atrybutu android:resizeableActivity, albo domyślnie, gdy wartość targetSdkVersion > 24. Aplikacje, które w pliku manifestu mają ten atrybut ustawiony na wartość „false”, NIE MOGĄ być uruchamiane w trybie wielu okien. Aplikacje, które nie mają ustawionego atrybutu w pliku manifestu (targetSdkVersion < 24), można uruchamiać w trybie wielu okien, ale system MUSI wyświetlić ostrzeżenie, że aplikacja może nie działać zgodnie z oczekiwaniami w tym trybie.
• Implementacje na urządzeniach NIE MOGĄ oferować trybu podzielonego ekranu ani trybu swobodnego, jeśli wysokość i szerokość ekranu są mniejsze niż 440 dp.
• Implementacje urządzeń o rozmiarach ekranu xlarge POWINNY obsługiwać tryb swobodny.
• Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać tryb obrazu w obrazie (PIP) w oknie wielozadaniowym i umieszczać okno PIP w prawym górnym rogu, gdy jest ono włączone.
• Implementacje urządzeń z obsługą trybu PIP w trybie wielookiennym MUSZĄ przydzielić co najmniej 240 x 135 dp dla okna PIP.
• Jeśli tryb PIP jest obsługiwany, do sterowania oknem PIP NALEŻY używać klawisza KeyEvent.KEYCODE_WINDOW. W przeciwnym razie klucz MUSI być dostępny dla aktywności na pierwszym planie.

3.9. Administracja urządzeniem

Android zawiera funkcje, które umożliwiają aplikacjom dbającym o bezpieczeństwo wykonywanie funkcji administracyjnych na poziomie systemu, takich jak egzekwowanie zasad dotyczących haseł czy zdalne wymazywanie danych za pomocą interfejsu API do administracji urządzeniami z Androidem. Implementacje urządzeń MUSZĄ zawierać implementację klasy DevicePolicyManager. Implementacje urządzeń, które obsługują bezpieczny ekran blokady, MUSZĄ implementować pełny zakres zasad zarządzania urządzeniem zdefiniowanych w dokumentacji pakietu Android SDK i zgłaszać funkcję platformy android.software.device_admin.

3.9.1 Obsługa administracyjna urządzenia

3.9.1.1 Obsługa administracyjna właściciela urządzenia

Jeśli implementacja urządzenia deklaruje funkcję android.software.device_admin, MUSI implementować Provisioning aplikacji właściciela urządzenia w aplikacji DPC (Device Policy Client) zgodnie z podanymi niżej wytycznymi:

• Jeśli implementacja urządzenia nie ma jeszcze skonfigurowanych danych użytkownika, to:
  • Wymagane raportowanie true w przypadku DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) .
  • W odpowiedzi na działanie intencyjne android.app.action.PROVISION_MANAGED_DEVICE aplikacja DPC MUSI zarejestrować się jako aplikacja właściciela urządzenia .
  • Aplikacja DPC MUSI zostać zarejestrowana jako aplikacja właściciela urządzenia, jeśli urządzenie deklaruje obsługę komunikacji Near Field Communication (NFC) za pomocą flagi funkcji android.hardware.nfc i odbiera wiadomość NFC zawierającą rekord z typem MIME MIME_TYPE_PROVISIONING_NFC .
• Gdy implementacja urządzenia zawiera dane użytkownika, to:
  • Musisz przesłać raport false dla DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) .
  • NIE MOŻESZ już rejestrować żadnej aplikacji DPC jako aplikacji właściciela urządzenia.

Implementacje urządzeń mogą mieć wstępnie zainstalowaną aplikację wykonującą funkcje administracyjne, ale ta aplikacja NIE MOŻE być ustawiona jako aplikacja właściciela urządzenia bez wyraźnej zgody lub działania użytkownika lub administratora urządzenia.

3.9.1.2 Zarządzanie profilem zarządzanym

Jeśli implementacja urządzenia deklaruje android.software.managed_users, MUSI być możliwe zarejestrowanie aplikacji kontrolera zasad dotyczących urządzenia (DPC) jako właściciela nowego profilu zarządzanego .

Proces obsługi administracyjnej profilu zarządzanego (przepływ danych inicjowany przez android.app.action.PROVISION_MANAGED_PROFILE) MUSI być zgodny z implementacją AOSP.

Implementacje urządzeń MUSZĄ zawierać w interfejsie Ustawienia te funkcje, aby wskazywać użytkownikowi, że dana funkcja systemu została wyłączona przez kontroler zasad urządzenia (DPC):

• Ujednoliconą ikonę lub inny element interfejsu użytkownika (np. ikonę informacji o AOSP w górę) wskazującą, że określone ustawienie jest ograniczone przez administratora urządzenia.
• Krótki komunikat wyjaśniający, który administrator urządzenia udostępnia za pomocą setShortSupportMessage .
• Ikona aplikacji DPC

3.9.2 Obsługa profilu zarządzanego

Urządzenia obsługujące profile zarządzane to urządzenia, które:

• Zadeklaruj android.software.device_admin (patrz sekcja 3.9 Administracja urządzeniami).
• nie są urządzeniami z niewielką ilością pamięci RAM (patrz sekcja 7.6.1);
• Przydziel pamięć wewnętrzną (niewymienną) jako pamięć współdzieloną (patrz sekcja 7.6.2).

Urządzenia obsługujące profile zarządzane MUSZĄ:

• Zadeklaruj flagę funkcji platformy android.software.managed_users .
• Obsługa profili zarządzanych za pomocą interfejsów API android.app.admin.DevicePolicyManager.
• Zezwalanie na utworzenie jednego zarządzanego profilu .
• Użyj plakietki ikony (podobnej do plakietki pracy w górę w AOSP), aby reprezentować zarządzane aplikacje i widżety oraz inne elementy interfejsu z plakietką, takie jak Ostatnie i Powiadomienia.
• Wyświetlanie ikony powiadomienia (podobnej do plakietki AOSP upstream) w celu wskazania, że użytkownik jest w aplikacji na profilu zarządzanym.
• wyświetlać komunikat podpowiadający, że użytkownik jest na profilu zarządzanym, gdy urządzenie się obudzi (ACTION_USER_PRESENT) i gdy aplikacja na pierwszym planie znajduje się na profilu zarządzanym.
• Jeśli istnieje profil zarządzany, wyświetl w oknie „Wybieranie intencji” wizualne elementy umożliwiające użytkownikowi przekierowywanie intencji z profilu zarządzanego do głównego użytkownika lub odwrotnie, jeśli jest to możliwe w ramach kontrolera zasad urządzenia.
• Jeśli profil zarządzany istnieje, wyświetl te opcje dla użytkownika głównego i profilu zarządzanego:
  • oddzielne rozliczanie baterii, lokalizacji, danych mobilnych i zajęcia miejsca na dane w przypadku głównego użytkownika i profilu zarządzanego;
  • niezależne zarządzanie aplikacjami VPN zainstalowanymi w profilu głównego użytkownika lub zarządzanym.
  • niezależne zarządzanie aplikacjami zainstalowanymi na profilu głównego użytkownika lub profilu zarządzanym;
  • niezależne zarządzanie kontami w ramach profilu głównego lub profilu zarządzanego,
• Zapewnienie możliwości wyszukiwania i wyświetlania informacji o dzwoniącym z profilu zarządzanego (jeśli istnieje) oraz z profilu głównego (jeśli istnieje) w wbudowanych aplikacjach do wybierania numerów, kontaktów i wysyłania wiadomości, jeśli zezwala na to kontroler zasad urządzenia. Gdy kontakty z profilu zarządzanego są wyświetlane w preinstalowanym dzienniku połączeń, interfejsie podczas połączenia, powiadomieniach o rozmowie w toku i nieodebranych połączeniach, kontaktach i aplikacjach do obsługi wiadomości, powinny być oznaczone tym samym znacznikiem, który jest używany do wskazywania aplikacji na profilu zarządzanym.
• Musisz się upewnić, że spełnia on wszystkie wymagania dotyczące zabezpieczeń obowiązujące w przypadku urządzeń z włączoną funkcją wielu użytkowników (patrz sekcja 9.5), mimo że profil zarządzany nie jest liczony jako dodatkowy użytkownik oprócz głównego użytkownika.
• Obsługa możliwości określenia osobnego ekranu blokady spełniającego poniższe wymagania, aby przyznać dostęp do aplikacji działających w profilu zarządzanym.
  • Implementacje urządzeń MUSZĄ obsługiwać intencję DevicePolicyManager.ACTION_SET_NEW_PASSWORD i wyświetlać interfejs do konfigurowania osobnych danych logowania na ekranie blokady dla profilu zarządzanego.
  • Dane logowania na ekranie blokady w profilu zarządzanym MUSZĄ używać tych samych mechanizmów przechowywania i zarządzania danymi logowania co profil nadrzędny, zgodnie z dokumentacją na stronie projektu Android Open Source.
  • Zasady dotyczące haseł w DPC MUSZĄ dotyczyć tylko danych logowania na ekranie blokady w profilu zarządzanym, chyba że są wywoływane w przypadku instancji DevicePolicyManager zwracanej przez funkcję getParentProfileInstance .

3.10. Ułatwienia dostępu

Android udostępnia warstwę ułatwień dostępu, która ułatwia osobom niepełnosprawnym poruszanie się po urządzeniach. Ponadto Android udostępnia interfejsy API platformy, które umożliwiają implementacji usług dostępności odbieranie wywołań zwrotnych dotyczących zdarzeń związanych z użytkownikiem i systemem oraz generowanie alternatywnych mechanizmów sprzężenia zwrotnego, takich jak odczytywanie tekstu, sprzężenie zwrotne haptyczne i sterowanie za pomocą trackballa lub panelu dotykowego.

W przypadku implementacji na urządzeniach obowiązują te wymagania:

• W systemie Android Automotive należy zaimplementować platformę ułatwień dostępu zgodną z domyślną implementacją Androida.
• Implementacje na urządzeniach (z wyjątkiem Androida Automotive) MUSZĄ zawierać implementację platformy dostępności Androida zgodną z domyślną implementacją Androida.
• Implementacje na urządzeniach (z wyjątkiem Androida Automotive) MUSZĄ obsługiwać implementacje usług ułatwień dostępu innych firm za pomocą interfejsów android.accessibilityservice API .
• Implementacje na urządzeniu (z wyjątkiem Androida Automotive) MUSZĄ generować zdarzenia AccessibilityEvents i przekazywać je do wszystkich zarejestrowanych implementacji AccessibilityService w sposób zgodny z domyślną implementacją na Androidzie.

• Implementacje urządzeń (Android Automotive i Android Watch bez wyjścia audio) MUSZĄ zawierać mechanizm dostępny dla użytkownika umożliwiający włączanie i wyłączanie usług ułatwień dostępu. Interfejs ten MUSI być wyświetlany w odpowiedzi na intencję android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

• W przypadku implementacji urządzeń z Androidem i wyjścia audio MOCNO zaleca się implementację usług ułatwień dostępu na urządzeniu, które mają funkcjonalność porównywaną z usługami ułatwień dostępu TalkBack** i Switch Access (https://github.com/google/talkback).

• Urządzenia z Androidem Watch z wyjściami audio powinny mieć implementację usługi ułatwień dostępu na urządzeniu, która jest porównywalna z funkcjonalnością usługi ułatwień dostępu TalkBack (https://github.com/google/talkback) lub ją przewyższa.
• W ramach implementacji na urządzeniu w ramach gotowego procesu konfiguracji NALEŻY zapewnić użytkownikom mechanizm umożliwiający włączanie odpowiednich usług ułatwień dostępu, a także opcje dostosowywania rozmiaru czcionki, rozmiaru wyświetlacza i gestyk powiększania.

** W przypadku języków obsługiwanych przez funkcję zamiany tekstu na mowę.

Pamiętaj też, że jeśli na urządzeniu jest wstępnie załadowana usługa ułatwień dostępu, to musi to być aplikacja obsługująca bezpośrednie uruchamianie {directBootAware}, jeśli urządzenie ma zaszyfrowane miejsce na dane za pomocą szyfrowania na podstawie plików (FBE).

3.11. Zamiana tekstu na mowę

Android zawiera interfejsy API, które umożliwiają aplikacjom korzystanie z usług konwersji tekstu na mowę (TTS), a także umożliwia dostawcom usług implementowanie usług TTS. Implementacje urządzeń zgłaszające funkcję android.hardware.audio.output MUSZĄ spełniać te wymagania związane z ramką TTS Androida .

Implementacje Androida Automotive:

• MUSI obsługiwać interfejsy API platformy TTS na Androidzie.
• MOŻE obsługiwać instalację silników TTS innych firm. Jeśli jest to obsługiwane, partnerzy MUSZĄ udostępnić użytkownikowi interfejs, który umożliwia mu wybranie silnika TTS do użycia na poziomie systemu.

Wszystkie inne implementacje urządzeń:

• Musi obsługiwać interfejsy API frameworku TTS na Androida i powinna zawierać mechanizm TTS obsługujący języki dostępne na urządzeniu. Pamiętaj, że upstreamowe oprogramowanie open source na Androida zawiera pełną implementację mechanizmu TTS.
• MUSI obsługiwać instalację mechanizmów TTS innych firm.
• MUSI zawierać interfejs dostępny dla użytkowników, który umożliwia im wybranie silnika TTS do użycia na poziomie systemu.

3.12. Framework wejścia TV

Android Television Input Framework (TIF) upraszcza dostarczanie treści na żywo na urządzeniach z Androidem TV. TIF udostępnia standardowy interfejs API do tworzenia modułów wejściowych, które sterują urządzeniami Android TV. Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać interfejs TV Input Framework.

Implementacje urządzeń, które obsługują TIF, MUSZĄ zadeklarować funkcję platformy android.software.live_tv.

3.12.1. Aplikacja TV

W przypadku każdej implementacji urządzenia, która deklaruje obsługę Live TV, MUSI być zainstalowana aplikacja telewizyjna (aplikacja TV). Projekt Android Open Source udostępnia implementację aplikacji na telewizor.

Aplikacja na telewizor MUSI umożliwiać instalowanie i używanie kanałów telewizyjnych oraz spełniać te wymagania:

• Implementacje urządzeń MUSZĄ umożliwiać instalowanie i zarządzanie danymi wejściowymi innych firm ( danymi wejściowymi innych firm) opartymi na TIF.
• Implementacje urządzeń MOGĄ zapewniać wizualne oddzielenie wstępnie zainstalowanych wejść opartych na TIF (zainstalowanych wejść) od wejść innych firm.
• Implementacje urządzeń NIE MOGĄ wyświetlać danych wejściowych innych firm, które wymagają więcej niż jednego działania nawigacyjnego, aby opuścić aplikację na telewizor (np. rozwinięcia listy danych wejściowych innych firm w aplikacji na telewizor).

3.12.1.1. Elektroniczny przewodnik po programach

Implementacje urządzeń z Androidem TV MUSZĄ wyświetlać nakładkę informacyjną i interaktywną, która MUSI zawierać elektroniczny przewodnik po programach (EPG) wygenerowany na podstawie wartości w polach TvContract.Programs. EPG musi spełniać te wymagania:

• EPG MUSI wyświetlać informacje ze wszystkich zainstalowanych wejść i wejść innych firm.
• EPG MOŻE zapewniać wizualne oddzielenie zainstalowanych wejść od wejść zewnętrznych.
• W przypadku EPG MOCNO zaleca się wyświetlanie zainstalowanych wejść i wejść innych firm z równą widocznością. EPG NIE MOŻE wyświetlać danych wejściowych innych firm, które znajdują się dalej niż jedno działanie nawigacyjne od zainstalowanych danych wejściowych w EPG.
• W przypadku zmiany kanału implementacje urządzeń MUSZĄ wyświetlać dane EPG dla aktualnie odtwarzanego programu.

3.12.1.2. Nawigacja

Aplikacja na telewizor MUSI umożliwiać nawigację za pomocą przycisków D-pad, Wstecz i Strona główna na urządzeniu wejściowym (np. pilocie, aplikacji do sterowania lub kontrolerze do gier) urządzenia z Androidem TV w celu wykonania tych funkcji:

• Zmiana kanałów telewizyjnych
• Otwieranie EPG
• Konfigurowanie i dostrajanie pod kątem danych wejściowych innych firm opartych na formacie TIF
• otwieranie menu Ustawienia.

Aplikacja na telewizorze powinna przekazywać kluczowe zdarzenia do wejść HDMI przez CEC.

3.12.1.3. Łączenie aplikacji z wejściem TV

Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać linkowanie aplikacji z wejściem TV , co pozwala na tworzenie linków aktywności z bieżącej aktywności do innej aktywności (np. link z transmisji na żywo do powiązanych treści). Aplikacja TV MUSI wyświetlać link do aplikacji z wejściami TV, jeśli jest on dostępny.

3.12.1.4. Przesuwanie w czasie

Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać przesuwanie w czasie, co pozwala użytkownikowi wstrzymać i wznowić odtwarzanie treści na żywo. Implementacje urządzeń MUSZĄ zapewniać użytkownikowi możliwość wstrzymania i wznowienia odtwarzanego programu, jeśli przesuwanie czasowe dla tego programu jest dostępne .

3.12.1.5. Nagrywanie telewizji

W przypadku implementacji urządzeń z Androidem TV MOCNO zalecamy obsługę nagrywania telewizyjnego. Jeśli wejście telewizora obsługuje nagrywanie, EPG MOŻE udostępnić sposób nagrywania programu, jeśli nagrywanie takiego programu nie jest zabronione . Implementacje urządzeń powinny zawierać interfejs do odtwarzania nagranych programów.

3.13. Szybkie ustawienia

Implementacje na urządzeniach z Androidem powinny zawierać komponent interfejsu Szybkich ustawień, który umożliwia szybki dostęp do często używanych lub pilnie potrzebnych działań.

Android zawiera interfejs API quicksettings, który umożliwia aplikacjom innych firm implementowanie kafelków, które użytkownik może dodawać obok kafelków udostępnianych przez system w komponencie interfejsu Szybkie ustawienia. Jeśli implementacja urządzenia zawiera element interfejsu Szybkich ustawień:

• MUSI umożliwiać użytkownikowi dodawanie i usuwanie kafelków aplikacji innych firm w szybkich ustawieniach.
• Nie wolno automatycznie dodawać kafelka z aplikacji innej firmy bezpośrednio do Szybkich ustawień.
• MUSI wyświetlać wszystkie kafelki dodane przez użytkownika z aplikacji innych firm obok kafelków szybkich ustawień dostarczonych przez system.

3.14. Interfejsy Vehicle UI API

3.14.1. Interfejs multimedialny w pojeździe

W przypadku każdej implementacji urządzenia, która deklaruje obsługę samochodową, MUSI być uwzględniony interfejs UI do obsługi aplikacji innych firm korzystających z interfejsów MediaBrowser i MediaSession API.

Platforma interfejsu użytkownika obsługująca aplikacje innych firm, które zależą od MediaBrowser i MediaSession, musi spełniać te wymagania wizualne:

• MUSI wyświetlać ikony MediaItem i ikony powiadomień w niezmienionej formie.
• MUSI wyświetlać te elementy zgodnie z opisem w MediaSession, np. metadane, ikony, obrazy.
• Musi zawierać tytuł aplikacji.
• Musi zawierać szufladę, aby wyświetlać hierarchię MediaBrowser.

4. Zgodność z pakietem aplikacji

Implementacje urządzeń MUSZĄ instalować i uruchamiać pliki „.apk” na Androida wygenerowane przez narzędzie „aapt” zawarte w oficjalnym pakiecie Android SDK . Z tego powodu implementacje na urządzeniach POWINNY używać systemu zarządzania pakietami implementacji referencyjnej.

Menedżer pakietów MUSI obsługiwać weryfikację plików „.apk” przy użyciu schematu podpisu plików APK w wersji 2 i podpisywania plików JAR .

Implementacje urządzeń NIE MOGĄ rozszerzać formatów .apk , Android Manifest , Dalvik bytecode ani RenderScript bytecode w taki sposób , aby uniemożliwić prawidłowe instalowanie i uruchamianie tych plików na innych zgodnych urządzeniach.

Implementacje na urządzeniach NIE MOGĄ zezwalać aplikacjom innym niż bieżący „instalator” pakietu na bezgłośne odinstalowanie aplikacji bez żadnego prompta, zgodnie z dokumentacją w pakiecie SDK dotyczącą uprawnienia DELETE_PACKAGE. Jedynymi wyjątkami są aplikacja weryfikująca pakiet systemowy, która obsługuje intencję PACKAGE_NEEDS_VERIFICATION, oraz aplikacja menedżera pamięci, która obsługuje intencję ACTION_MANAGE_STORAGE.

5. Zgodność multimedialna

5.1. Kodeki multimedialne

Implementacje na urządzeniu:

• MUSI obsługiwać podstawowe formaty multimediów określone w dokumentacji pakietu Android SDK, z wyjątkiem przypadków, w których jest to wyraźnie dozwolone w tym dokumencie.

• MUSI obsługiwać formaty multimediów, kodery, dekodery, typy plików i formaty kontenerów zdefiniowane w tabelach poniżej i zgłoszone za pomocą MediaCodecList .

• Musi być też możliwe odkodowanie wszystkich profili zgłoszonych w CamcorderProfile.

• MUSI być w stanie dekodować wszystkie formaty, które może kodować. Obejmuje to wszystkie strumienie bitowe generowane przez kodery.

Należy dążyć do minimalnego opóźnienia kodeka, innymi słowy:

• NIE POWINNA zużywać ani przechowywać buforów wejściowych i zwracać buforów wejściowych tylko po przetworzeniu
• NIE NALEŻY przechowywać odkodowanych buforów dłużej niż określono w standardzie (np. SPS).
• NIE POWINIEN przechowywać zakodowanych buforów dłużej niż wymaga tego struktura GOP.

Wszystkie kodeki wymienione w tabeli poniżej są dostępne jako implementacje oprogramowania w preferowanej implementacji Androida z Projektu Android Open Source.

Należy pamiętać, że ani Google, ani Open Handset Alliance nie gwarantują, że te kodeki są wolne od patentów innych firm. Osoby, które chcą używać tego kodu źródłowego w urządzeniach lub produktach programowych, powinny wiedzieć, że implementacje tego kodu, w tym w oprogramowaniu open source lub shareware, mogą wymagać licencji na patenty od odpowiednich właścicieli patentów.

5.1.1. Kodeki audio

Format/kodek	za pomocą kodera.	Dekoder	Szczegóły	Obsługiwane typy plików i formaty kontenerów
MPEG-4 AAC Profile (AAC LC)	WYMAGANE 1	WYMAGANE	Obsługa treści mono/stereo/5.0/5.1 2 o standardowej częstotliwości próbkowania od 8 do 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS raw AAC (.aac, dekodowanie w Androidzie 3.1 lub nowszym, kodowanie w Androidzie 4.0 lub nowszym, ADIF nie jest obsługiwany) MPEG-TS (.ts, nieprzeskakuj, Android 3.0 lub nowszy)
MPEG-4 HE AAC Profile (AAC+)	WYMAGANE 1 (Android 4.1 lub nowszy)	WYMAGANE	Obsługa treści mono/stereo/5.0/5.1 2 o standardowej częstotliwości próbkowania od 16 do 48 kHz.
MPEG-4 HE AACv2 Profile (enhanced AAC+)		WYMAGANE	Obsługa treści mono/stereo/5.0/5.1 2 o standardowej częstotliwości próbkowania od 16 do 48 kHz.
AAC ELD (ulepszona wersja AAC o niskim opóźnieniu)	WYMAGANE 1 (Android 4.1 lub nowszy)	WYMAGANE (Android 4.1 lub nowszy)	Obsługa treści mono lub stereo ze standardową częstotliwością próbkowania od 16 do 48 kHz.
AMR-NB	WYMAGANE 3	WYMAGANE 3	4,75–12,2 kb/s próbkowane z częstotliwością 8 kHz	3GPP (.3gp)
AMR-WB	WYMAGANE 3	WYMAGANE 3	9 szybkości od 6,60 kb/s do 23,85 kb/s z częstotliwością próbkowania 16 kHz
FLAC		WYMAGANE (Android 3.1 lub nowszy)	Mono/Stereo (bez kanałów dodatkowych). Częstotliwości próbkowania do 48 kHz (ale na urządzeniach z wyjściami 44,1 kHz zaleca się stosowanie częstotliwości do 44,1 kHz, ponieważ konwerter 48 kHz na 44,1 kHz nie zawiera filtra dolnoprzepustowego). 16-bit (ZALECANE); w przypadku 24-bitów nie jest stosowany dithering.	Tylko FLAC (.flac)
MP3		WYMAGANE	Mono/Stereo 8–320 kb/s stała (CBR) lub zmienna szybkość transmisji (VBR)	MP3 (.mp3)
MIDI		WYMAGANE	Typ MIDI 0 i 1. DLS w wersji 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonków RTTTL/RTX, OTA i iMelody	Typ 0 i 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		WYMAGANE		Ogg (.ogg) Matroska (.mkv, Android 4.0 lub nowszy)
PCM/WAVE	WYMAGANE 4 (Android 4.1 lub nowszy)	WYMAGANE	16-bitowy PCM liniowy (częstotliwość do limitu sprzętowego). Urządzenia MUSZĄ obsługiwać częstotliwości próbkowania dla nieskompresowanych nagrań PCM o częstotliwości 8000, 11025, 16000 i 44100 Hz.	WAVE (.wav)
Opus		WYMAGANE (Android 5.0 lub nowszy)		Matroska (.mkv), Ogg(.ogg)

1 Wymagany w przypadku implementacji na urządzeniach, które definiują android.hardware.microphone, ale opcjonalny w przypadku implementacji na urządzeniach z Androidem Watch.

2 Nagrywanie lub odtwarzanie MOŻE odbywać się w trybie mono lub stereo, ale dekodowanie buforów wejściowych AAC strumieni wielokanałowych (czyli więcej niż 2 kanałów) na PCM za pomocą domyślnego dekodera audio AAC w interfejsie API android.media.MediaCodec MUSI obsługiwać:

• dekodowanie jest wykonywane bez mieszania w dół (np. strumień AAC 5.0 musi zostać zdekodowany do 5 kanałów PCM, a strumień AAC 5.1 musi zostać zdekodowany do 6 kanałów PCM);
• metadane zakresu dynamicznego, zdefiniowane w sekcji „Dynamic Range Control (DRC)” w normie ISO/IEC 14496-3, oraz klucze DRC android.media.MediaFormat, które służą do konfigurowania zachowania dekodera audio związanego z zakresem dynamicznym. Klucze AAC DRC zostały wprowadzone w interfejsie API 21 i są to: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL i KEY_AAC_ENCODED_TARGET_LEVEL.

3 Wymagany w przypadku implementacji na urządzeniach przenośnych z Androidem.

4 Wymagany w przypadku implementacji urządzeń, które definiują android.hardware.microphone, w tym implementacji urządzeń z Androidem Watch.

5.1.2. Kodek obrazu

Format/kodek	za pomocą kodera.	Dekoder	Szczegóły	Obsługiwane typy plików i formaty kontenerów
JPEG	WYMAGANE	WYMAGANE	Podstawowe + progresywne	JPEG (.jpg)
GIF		WYMAGANE		GIF (.gif)
PNG	WYMAGANE	WYMAGANE		PNG (.png)
BMP		WYMAGANE		BMP (.bmp),
WebP	WYMAGANE	WYMAGANE		WebP (.webp),
Nieprzetworzony		WYMAGANE		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

5.1.3. Kodeki wideo

• Kodek reklamujący obsługę profilu HDR MUSI obsługiwać analizowanie i obsługę statycznych metadanych HDR.

• Jeśli kodek multimediów obsługuje odświeżanie wewnątrzklatkowe, MUSI obsługiwać okresy odświeżania w zakresie 10–60 ramek i działać z dokładnością do 20% skonfigurowanego okresu odświeżania.

• Kodery wideo MUSZĄ obsługiwać rozmiary buforów bajtów wejścia i wyjścia, które umożliwiają obsługę największych możliwych ramek skompresowanych i nieskompresowanych zgodnie ze standardem i konfiguracją, ale też nieprzekraczających ich rozmiarów.

• Kodery i dekodery wideo MUSZĄ obsługiwać elastyczny format kolorów YUV420 (COLOR_FormatYUV420Flexible).

Format/kodek	za pomocą kodera.	Dekoder	Szczegóły	Obsługiwane typy plików/ Formaty kontenerów
H.263	MAJ	MAJ		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	WYMAGANE 2	WYMAGANE 2	Więcej informacji znajdziesz w sekcji 5.2 i 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, tylko dźwięk AAC, brak możliwości przeskakiwania, Android 3.0 lub nowszy)
H.265 HEVC		WYMAGANE 5	Więcej informacji znajdziesz w sekcji 5.3.	MPEG-4 (.mp4)
MPEG-2		BARDZO ZALECANA 6	Profil główny	MPEG2-TS
MPEG-4 SP		WYMAGANE 2		3GPP (.3gp)
VP8 3	WYMAGANE 2 (Android 4.3 lub nowszy)	WYMAGANE 2 (Android 2.3.3 lub nowszy)	Więcej informacji znajdziesz w sekcji 5.2 i 5.3.	WebM (.webm) Matroska (.mkv, Android 4.0 lub nowszy) 4
VP9		WYMAGANE 2 (Android 4.4 lub nowszy)	Więcej informacji znajdziesz w sekcji 5.3.	WebM (.webm) Matroska (.mkv, Android 4.0 lub nowszy) 4

1 Wymagany w przypadku implementacji urządzeń, które zawierają sprzęt kamery i określają android.hardware.camera lub android.hardware.camera.front.

2 Wymagany w przypadku implementacji na urządzeniach z wyjątkiem zegarków z Androidem.

3 Aby zapewnić akceptowalną jakość strumieniowego przesyłania wideo i usług wideokonferencji, implementacje urządzeń POWINNY używać kodeka VP8 na poziomie sprzętowym, który spełnia wymagania .

4. Implementacje urządzeń powinny obsługiwać zapisywanie plików Matroska WebM.

5 ZALECANA w przypadku Androida Automotive, opcjonalna w przypadku zegarka z Androidem i wymagana w przypadku wszystkich innych typów urządzeń.

6 Dotyczy tylko implementacji na urządzeniach z Androidem TV.

5.2. Kodowanie wideo

Kodery wideo H.264, VP8, VP9 i HEVC

• MUSI obsługiwać dynamicznie konfigurowane szybkości transmisji.
• NALEŻY obsługiwać zmienne liczby klatek, przy czym koder wideo NALEŻY określać chwilowy czas trwania klatki na podstawie sygnałów czasowych buforów wejściowych i przydzielać zasobnik bitów na podstawie tego czasu trwania klatki.

Koder wideo H.263 i MPEG-4 POWINIEN obsługiwać dynamicznie konfigurowalne szybkości transmisji.

Wszystkie kodery wideo POWINNY osiągać te wartości przepływności danych w 2 przesuwających się oknach:

• Nie powinna przekraczać o więcej niż około 15% szybkości transmisji bitów między interwałami klatek wewnątrzramkowych (I-frame).
• Wartość ta nie powinna przekraczać 100% szybkości transmisji danych w przesuwalnym oknie 1 sekundy.

5.2.1. H.263

Implementacje urządzeń z Androidem i koderami H.263 MUSZĄ obsługiwać podstawowy profil poziomu 45.

5.2.2. H-264

Implementacje urządzeń z Androidem obsługujące kodek H.264:

• MUSI obsługiwać profil podstawowy na poziomie 3.
  Obsługa ASO (dowolne sortowanie segmentów), FMO (elastyczne sortowanie makrobloków) i RS (niepotrzebne segmenty) jest OPCJONALNA. Ponadto, aby zachować zgodność z innymi urządzeniami z Androidem, zalecamy, aby kodery nie używały funkcji ASO, FMO i RS w przypadku profilu podstawowego.
• MUSI obsługiwać profile kodowania filmów SD (standardowej rozdzielczości) podane w tabeli poniżej.
• Powinien obsługiwać poziom profilu głównego 4.
• Powinien obsługiwać profile kodowania filmów HD (High Definition) zgodnie z tabelą poniżej.
• Ponadto w przypadku urządzeń z Androidem TV MOCNO zaleca się kodowanie filmów w rozdzielczości HD 1080p przy 30 kl./s.

	SD (niska jakość)	SD (wysoka jakość)	HD 720p 1	HD 1080p 1
Rozdzielczość wideo	320 x 240 pikseli	720 x 480 piks.	1280 x 720 pikseli	1920 x 1080 piks.
liczba klatek na sekundę,	20 kl./s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	384 kbps	2 Mb/s	4 Mb/s	10 Mb/s

1 W przypadku obsługi przez sprzęt, ale BARDZO ZALECANA w przypadku urządzeń Android TV.

5.2.3. VP8

Implementacje urządzeń z Androidem, które obsługują kodek VP8, MUSZĄ obsługiwać profile kodowania filmów SD i POWINNY obsługiwać te profile kodowania filmów HD (wysokiej rozdzielczości).

	SD (niska jakość)	SD (wysoka jakość)	HD 720p 1	HD 1080p 1
Rozdzielczość wideo	320 x 180 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 piks.
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	4 Mb/s	10 Mb/s

1 Jeśli jest to obsługiwane przez sprzęt.

5.3. Dekodowanie wideo

Implementacje na urządzeniu:

• MUSI obsługiwać dynamiczną zmianę rozdzielczości wideo i szybkości klatek za pomocą standardowych interfejsów API Androida w ramach tego samego strumienia dla wszystkich kodeków VP8, VP9, H.264 i H.265 w czasie rzeczywistym oraz do maksymalnej rozdzielczości obsługiwanej przez każdy z tych kodeków na urządzeniu.

• Implementacje, które obsługują dekoder Dolby Vision:

• Musisz podać narzędzie do wyodrębniania obsługujące Dolby Vision.

• MUSI prawidłowo wyświetlać treści Dolby Vision na ekranie urządzenia lub na standardowym wyjściu wideo (np. HDMI).

• W implementacjach, które zapewniają ekstraktor obsługujący Dolby Vision, indeks ścieżki warstw bazowych zgodnych z wstecznością (jeśli występują) MUSI być taki sam jak indeks ścieżki połączonej warstwy Dolby Vision.

5.3.1. MPEG-2

Implementacje urządzeń z Androidem z dekoderami MPEG-2 muszą obsługiwać profil główny na wysokim poziomie.

5.3.2. H.263

Implementacje urządzeń z Androidem i dekoderami H.263 MUSZĄ obsługiwać poziomy profilu podstawowego 30 i 45.

5.3.3. MPEG-4

Implementacje urządzeń z Androidem z dekoderami MPEG-4 MUSZĄ obsługiwać profil Simple Profile poziomu 3.

5.3.4. H.264

Implementacje na urządzeniach z Androidem z dekoderami H.264:

• MUSI obsługiwać profil główny poziomu 3.1 i profil podstawowy.
  Obsługa ASO (dowolne sortowanie segmentów), FMO (elastyczne sortowanie makrobloków) i RS (niepotrzebne segmenty) jest OPCJONALNA.
• MUSI być w stanie dekodować filmy z profilami SD (standardowa rozdzielczość) wymienionymi w poniższej tabeli i zakodowanymi za pomocą profilu podstawowego i profilu głównego poziomu 3.1 (w tym 720p30).
• POWINIEN być w stanie dekodować filmy z profilami HD (High Definition) zgodnie z tabelą poniżej.
• Dodatkowo urządzenia z Androidem TV:
  • MUSI obsługiwać profil High Profile Level 4.2 i profil dekodowania HD 1080p60.
  • MUSI być w stanie dekodować filmy z obu profilami HD, jak wskazano w poniższej tabeli, i kodowane za pomocą profilu podstawowego, profilu głównego lub profilu wysokiego poziomu 4.2.

	SD (niska jakość)	SD (wysoka jakość)	HD 720p 1	HD 1080p 1
Rozdzielczość wideo	320 x 240 pikseli	720 x 480 piks.	1280 x 720 pikseli	1920 x 1080 piks.
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	60 kl./s	30 kl./s (60 kl./s 2)
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

1 WYMAGANE, gdy wysokość podana przez metodę Display.getSupportedModes() jest równa lub większa niż rozdzielczość filmu.

2 WYMAGANE w przypadku implementacji na urządzeniach z Androidem TV.

5.3.5. H.265 (HEVC)

Implementacje na urządzeniach z Androidem, które obsługują kodek H.265 zgodnie z opisem w sekcji 5.1.3 :

• MUSI obsługiwać poziom główny profilu głównego (poziom 3) i profily dekodowania SD zgodnie z tabelą poniżej.
• NALEŻY obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
• W przypadku dekodera sprzętowego MUSI obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
• Dodatkowo urządzenia z Androidem TV:
• MUSI obsługiwać profil dekodowania HD 720p.
• BARDZO ZALECAMY obsługę profilu dekodowania HD 1080p. Jeśli obsługiwany jest profil dekodowania HD 1080p, MUSI on obsługiwać poziom główny profilu głównego 4.1.
• POWINNA obsługiwać profil dekodowania UHD. Jeśli profil dekodowania UHD jest obsługiwany, kodek MUSI obsługiwać profil Main10 Level 5 Main Tier.

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	352 x 288 pikseli	720 x 480 piks.	1280 x 720 pikseli	1920 x 1080 piks.	3840 x 2160 pikseli
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	30 klatek/s	30 kl./s (60 kl./s 1)	60 kl./s
Szybkość transmisji wideo	600 Kb/s	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

1 WYMAGANE w przypadku implementacji urządzeń z Androidem TV z dekodowaniem sprzętowym H.265.

5.3.6. VP8

Implementacje na urządzeniach z Androidem, które obsługują kodek VP8 zgodnie z opisem w sekcji 5.1.3 :

• MUSI obsługiwać profile dekodowania SD podane w tabeli poniżej.
• NALEŻY obsługiwać profile dekodowania HD podane w tabeli poniżej.
• Urządzenia z Androidem TV MUSZĄ obsługiwać profil dekodowania HD 1080p60.

	SD (niska jakość)	SD (wysoka jakość)	HD 720p 1	HD 1080p 1
Rozdzielczość wideo	320 x 180 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 piks.
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	30 kl./s (60 kl./s 2)	30 (60 fps 2)
Szybkość transmisji wideo	800 Kb/s	2 Mb/s	8 Mb/s	20 Mb/s

1 WYMAGANE, gdy wysokość podana przez metodę Display.getSupportedModes() jest równa lub większa niż rozdzielczość filmu.

2 WYMAGANE w przypadku implementacji na urządzeniach z Androidem TV.

5.3.7. VP9

Implementacje na urządzeniach z Androidem, które obsługują kodek VP9 zgodnie z opisem w sekcji 5.1.3 :

• MUSI obsługiwać profile dekodowania filmów SD zgodnie z tabelą poniżej.
• NALEŻY obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.
• W przypadku dekodera sprzętowego MUSI obsługiwać profile dekodowania HD zgodnie z tabelą poniżej.

• Dodatkowo urządzenia z Androidem TV:

  • MUSI obsługiwać profil dekodowania HD 720p.
  • BARDZO ZALECAMY obsługę profilu dekodowania HD 1080p.
  • POWINNA obsługiwać profil dekodowania UHD. Jeśli profil dekodowania wideo UHD jest obsługiwany, MUSI obsługiwać 8-bitową głębię kolorów i POWINIEN obsługiwać profil VP9 Profile 2 (10-bitowy).

	SD (niska jakość)	SD (wysoka jakość)	HD – 720p	HD – 1080p	UHD
Rozdzielczość wideo	320 x 180 pikseli	640 x 360 pikseli	1280 x 720 pikseli	1920 x 1080 piks.	3840 x 2160 pikseli
liczba klatek na sekundę,	30 klatek/s	30 klatek/s	30 klatek/s	30 kl./s (60 kl./s 1)	60 kl./s
Szybkość transmisji wideo	600 Kb/s	1,6 Mb/s	4 Mb/s	5 Mb/s	20 Mb/s

1 WYMAGANE w przypadku implementacji urządzeń z Androidem TV ze sprzętowym dekodowaniem formatu VP9.

5.4. Nagrywanie dźwięku

Chociaż niektóre wymagania opisane w tej sekcji są od wersji 4.3 Androida oznaczone jako „NALEŻY”, w definicji zgodności w przyszłej wersji mają być oznaczone jako „NALEŻY”. W przypadku istniejących i nowych urządzeń z Androidem ZALECAMY spełnienie tych wymagań, które są oznaczone jako „NALEŻY”, ponieważ w przeciwnym razie nie będą one zgodne z Androidem po przejściu na przyszłą wersję.

5.4.1. Przechwytywanie dźwięku w formacie RAW

Implementacje urządzeń, które deklarują android.hardware.microphone, MUSZĄ umożliwiać rejestrowanie nieprzetworzonych treści audio o tych cechach:

• Format : Linear PCM, 16-bit
• Częstotliwości próbkowania : 8000, 11025, 16000, 44100
• Kanały : mono

Przechwytywanie przy powyższych częstotliwościach próbkowania MUSI odbywać się bez interpolacji, a każde próbkowanie w dół MUSI zawierać odpowiedni filtr antyaliasingowy.

Implementacje urządzeń, które deklarują android.hardware.microphone, POWINNY umożliwiać rejestrowanie surowych treści audio o tych cechach:

• Format : Linear PCM, 16-bit
• Częstotliwości próbkowania : 22050, 48000
• Kanały : stereo

Jeśli nagrywanie przy powyższych współczynnikach próbkowania jest obsługiwane, nagrywanie MUSI być wykonywane bez próbkowania w górę przy dowolnym współczynniku wyższym niż 16000:22050 lub 44100:48000. Każde próbkowanie w górę lub w dół MUSI obejmować odpowiedni filtr antyaliasingu.

5.4.2. Przechwytywanie danych do rozpoznawania głosu

Źródło dźwięku android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION MUSI obsługiwać przechwytywanie z jedną z tych częstotliwości próbkowania: 44100 Hz i 48000 Hz.

Oprócz powyższych specyfikacji nagrywania, gdy aplikacja rozpoczęła nagrywanie strumienia audio za pomocą źródła audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

• Urządzenie POWINNA mieć w przybliżeniu płaskie charakterystyki amplitudy w zależności od częstotliwości: konkretnie ±3 dB w zakresie 100–4000 Hz.
• Czułość wejścia audio powinna być ustawiona tak, aby źródło o poziomie mocy akustycznej (SPL) wynoszącym 90 dB przy częstotliwości 1000 Hz dawało wartość RMS wynoszącą 2500 dla próbek 16-bitowych.
• Poziomy amplitudy PCM POWINNY śledzić zmiany SPL wejścia w zakresie co najmniej 30 dB od –18 dB do +12 dB w stosunku do 90 dB SPL przy mikrofonie.
• Całkowite zniekształcenie harmoniczne POWINNA być mniejsza niż 1% dla 1 kHz przy 90 dB SPL na wejściu mikrofonu.
• Przetwarzanie redukcji szumów (jeśli występuje) MUSI być wyłączone.
• Automatyczna kontrola wzmocnienia (jeśli jest dostępna) MUSI być wyłączona.

Jeśli platforma obsługuje technologie tłumienia szumów dostosowane do rozpoznawania mowy, efekt MUSI być możliwy do kontrolowania za pomocą interfejsu API android.media.audiofx.NoiseSuppressor. Ponadto pole UUID w przypadku deskryptora efektu wyciszenia szumu MUSI jednoznacznie identyfikować każdą implementację technologii wyciszania szumu.

5.4.3. Przechwytywanie w celu przekierowania odtwarzania

Klasa android.media.MediaRecorder.AudioSource zawiera źródło dźwięku REMOTE_SUBMIX. Urządzenia, które deklarują android.hardware.audio.output, MUSZĄ prawidłowo zaimplementować źródło dźwięku REMOTE_SUBMIX, aby aplikacja korzystająca z interfejsu API android.media.AudioRecord do nagrywania z tego źródła dźwięku mogła rejestrować miks wszystkich strumieni dźwięku z wyjątkiem tych:

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

5.5. Odtwarzanie dźwięku

Implementacje urządzeń, które deklarują android.hardware.audio.output, MUSZĄ być zgodne z wymaganiami podanymi w tej sekcji.

5.5.1. Odtwarzanie dźwięku w postaci surowych danych

Urządzenie MUSI umożliwiać odtwarzanie surowych treści audio o tych cechach:

• Format : Linear PCM, 16-bit
• Częstotliwości próbkowania : 8000, 11025, 16000, 22050, 32000, 44100
• Kanały : mono, stereo

Urządzenie POWINIEN umożliwiać odtwarzanie surowych treści audio o tych cechach:

• Częstotliwości próbkowania : 24000, 48000

5.5.2. Efekty dźwiękowe

Android udostępnia interfejs API do efektów dźwiękowych na potrzeby implementacji na urządzeniach. Implementacje urządzeń, które deklarują funkcję android.hardware.audio.output:

• MUSI obsługiwać implementacje EFFECT_TYPE_EQUALIZER i EFFECT_TYPE_LOUDNESS_ENHANCER, które można kontrolować za pomocą podklas AudioEffect Equalizer i LoudnessEnhancer.
• MUSI obsługiwać implementację interfejsu API wizualizacji, którą można kontrolować za pomocą klasy Visualizer.
• Powinien obsługiwać implementacje EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB i EFFECT_TYPE_VIRTUALIZER, które można kontrolować za pomocą podklas AudioEffect BassBoost, EnvironmentalReverb, PresetReverb i Virtualizer.

5.5.3. Głośność wyjścia audio

Implementacje urządzeń z Androidem TV MUSZĄ zawierać obsługę systemowej głośności głównej i tłumienia głośności wyjścia audio cyfrowego na obsługiwanych wyjściach, z wyjątkiem wyjścia z przekazanym dźwiękiem skompresowanym (gdzie na urządzeniu nie jest wykonywane dekodowanie dźwięku).

Implementacje urządzeń z Androidem Automotive powinny umożliwiać dostosowywanie głośności dźwięku osobno dla każdego strumienia dźwięku za pomocą typu treści lub sposobu użycia zdefiniowanego przez AudioAttributes oraz sposobu użycia dźwięku w samochodzie zgodnie z publicznie zdefiniowanym w android.car.CarAudioManager .

5.6. Opóźnienie dźwięku

Opóźnienie dźwięku to czas opóźnienia sygnału dźwiękowego w systemie. Wiele rodzajów aplikacji wymaga niskich opóźnień, aby uzyskać efekty dźwiękowe w czasie rzeczywistym.

W rozumieniu tego punktu stosuje się następujące definicje:

• opóźnienie wyjścia . Interval między zapisaniem przez aplikację ramki danych zakodowanych w formacie PCM a momentem, w którym odpowiedni dźwięk jest prezentowany otoczeniu przez przetwornik na urządzeniu lub sygnał opuszcza urządzenie przez port i może być obserwowany z zewnątrz.
• opóźnienie zimnego wyjścia . Opóźnienie wyjścia dla pierwszego obrazu, gdy system wyjścia audio był nieaktywny i wyłączony przed żądaniem.
• ciągły czas oczekiwania na wyjście . Opóźnienie wyjściowe kolejnych klatek po rozpoczęciu odtwarzania dźwięku przez urządzenie.
• opóźnienie reakcji . Interval between when a sound is presented by environment to device at an on-device transducer or signal enters the device via a port and when an application reads the corresponding frame of PCM-coded data.
• utracił(a) dane wejściowe . Początkowa część sygnału wejściowego, która jest nieprzydatna lub niedostępna.
• opóźnienie zimnego wejścia . Suma utraconego czasu wprowadzania danych i opóźnienia wprowadzania danych dla pierwszej klatki, gdy system wprowadzania danych audio był nieaktywny i wyłączony przed żądaniem.
• ciągłe opóźnienie wejścia . Opóźnienie wejścia w przypadku kolejnych klatek podczas rejestrowania dźwięku przez urządzenie.
• tylko w przypadku jittera na wyjściu . zmienność między poszczególnymi pomiarami wartości opóźnienia wyjścia bez uczenia
• Jitter sygnału wejściowego . zmienność między poszczególnymi pomiarami wartości opóźnienia zimnego wejścia;
• ciągłe opóźnienie w obie strony . Suma opóźnienia ciągłego wejścia i opóźnienia ciągłego wyjścia oraz jeden okres buforowania. Okres buforowania daje aplikacji czas na przetworzenie sygnału i zmniejszenie różnicy fazy między strumieniami wejściowym i wyjściowym.
• OpenSL ES PCM buffer queue API . Zestaw interfejsów API OpenSL ES związanych z PCM w Android NDK .

W przypadku implementacji urządzeń, które deklarują android.hardware.audio.output, MOCNO zaleca się spełnienie tych wymagań dotyczących wyjścia audio lub przekroczenie ich:

• opóźnienie wyjścia „na zimno” nie większe niż 100 ms;
• ciągłe opóźnienie wyjścia na poziomie 45 ms lub mniej
• minimalizowanie jittera wyjścia „na zimno”;

Jeśli implementacja urządzenia spełnia wymagania podane w tym rozdziale po początkowej kalibracji przy użyciu interfejsu API kolejki buforowej OpenSL ES PCM, w przypadku opóźnienia ciągłego wyjścia i opóźnienia zimnego wyjścia na co najmniej 1 obsługiwanym urządzeniu z wyjściami audio, MOCNO zalecamy zgłoszenie obsługi dźwięku o niskim opóźnieniu. Aby to zrobić, użyj funkcji android.hardware.audio.low_latency w klasie android.content.pm.PackageManager. Jeśli implementacja urządzenia nie spełnia tych wymagań, NIE MOŻE zgłaszać obsługi dźwięku o małej latencji.

W przypadku implementacji urządzeń, które zawierają android.hardware.microphone, MOCNO zaleca się spełnienie tych wymagań dotyczących dźwięku wejściowego:

• opóźnienie na wejściu „na zimno” nieprzekraczające 100 ms,
• ciągłe opóźnienie wejścia na poziomie 30 ms lub mniej,
• ciągłe opóźnienie w obie strony nieprzekraczające 50 ms;
• minimalizowanie jittera danych wejściowych „na zimno”

5.7. Protokoły sieciowe

Urządzenia MUSZĄ obsługiwać protokoły sieci multimedialnej do odtwarzania dźwięku i obrazu zgodnie z dokumentacją pakietu Android SDK. Urządzenia MUSZĄ obsługiwać te protokoły sieci multimedialnych:

• HTTP(S) strumieniowe przesyłanie progresywne
  Wszystkie wymagane kodeki i formaty kontenerów wymienione w sekcji 5.1 MUSZĄ być obsługiwane przez HTTP(S).

• Protokół transmisji na żywo przez HTTP w wersji roboczej, wersja 7
  Musisz obsługiwać te formaty segmentów multimediów:

Formaty segmentów	Źródła	Obsługa wymaganych kodeków
MPEG-2 Transport Stream	ISO 13818	Kodek wideo: H264 AVC MPEG-4 SP MPEG-2 Szczegółowe informacje o H.264 AVC, MPEG2-4 SP, i MPEG-2 znajdziesz w sekcji 5.1.3. Kodeki audio: AAC Więcej informacji o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
AAC z ramowaniem ADTS i tagami ID3	ISO 13818-7	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
WebVTT	WebVTT

• RTSP (RTP, SDP)

  NALEŻY obsługiwać ten profil RTP audio i powiązane z nim kodeki. Wyjątki znajdziesz w przypisach do tabeli w sekcji 5.1 .

Nazwa profilu	Źródła	Obsługa wymaganych kodeków
H264 AVC	RFC 6184	Szczegółowe informacje na temat H264 AVC znajdziesz w sekcji 5.1.3.
MP4A-LATM	RFC 6416	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Szczegółowe informacje o H.263 znajdziesz w sekcji 5.1.3.
H263-2000	RFC 4629	Szczegółowe informacje o H.263 znajdziesz w sekcji 5.1.3.
AMR	RFC 4867	Szczegółowe informacje o AMR-NB znajdziesz w sekcji 5.1.1.
AMR-WB	RFC 4867	Szczegółowe informacje o AMR-WB znajdziesz w sekcji 5.1.1.
MP4V-ES	RFC 6416	Szczegółowe informacje o MPEG-4 SP znajdziesz w sekcji 5.1.3.
mpeg4-generic	RFC 3640	Szczegółowe informacje o AAC i jego wariantach znajdziesz w sekcji 5.1.1.
MP2T	RFC 2250	Szczegółowe informacje znajdziesz w sekcji MPEG-2 Transport Stream w sekcji Transmisja na żywo przez HTTP.

5.8. Secure Media

Implementacje urządzeń, które obsługują bezpieczne wyjście wideo i mogą obsługiwać bezpieczne powierzchnie, MUSZĄ deklarować obsługę Display.FLAG_SECURE. Implementacje urządzeń, które deklarują obsługę flagi Display.FLAG_SECURE, jeśli obsługują protokół wyświetlacza bezprzewodowego, MUSZĄ zabezpieczyć połączenie za pomocą silnego mechanizmu szyfrowania, takiego jak HDCP 2.x lub nowszy w przypadku wyświetlaczy bezprzewodowych Miracast. Podobnie, jeśli obsługują one przewodowy wyświetlacz zewnętrzny, ich implementacje MUSZĄ obsługiwać HDCP 1.2 lub nowszą wersję. Implementacje urządzeń Android TV MUSZĄ obsługiwać HDCP 2.2 w przypadku urządzeń obsługujących rozdzielczość 4K oraz HDCP 1.4 lub nowszą w przypadku niższych rozdzielczości. Współdzielona implementacja open source Androida obejmuje obsługę wyświetlaczy bezprzewodowych (Miracast) i przewodowych (HDMI), które spełniają ten wymóg.

5.9. MusicaI Instrument Digital Interface (MIDI)

Jeśli implementacja urządzenia obsługuje przesyłanie danych MIDI między aplikacjami (wirtualne urządzenia MIDI) i obsługuje MIDI za pomocą wszystkich tych interfejsów przesyłania danych MIDI, dla których zapewnia ogólne połączenia nieobsługujące MIDI, to BARDZO ZALECAMY zgłoszenie obsługi interfejsu android.software.midi za pomocą klasy android.content.pm.PackageManager.

Urządzenia MIDI:

• Tryb hosta USB (sekcja 7.7 USB)
• Tryb urządzenia peryferyjnego USB (sekcja 7.7 USB)
• MIDI przez Bluetooth LE w roli centralnej (sekcja 7.4.3 Bluetooth)

Jeśli implementacja urządzenia zapewnia ogólne połączenie nie-MIDI za pomocą określonego sprzętowego interfejsu MIDI z listy powyżej, ale nie obsługuje MIDI za pomocą tego interfejsu, NIE MOŻE zgłaszać obsługi funkcji android.software.midi.

5.10. Profesjonalny dźwięk

Jeśli implementacja urządzenia spełnia wszystkie wymagania wymienione poniżej, MOCNO zalecamy zgłoszenie obsługi funkcji android.hardware.audio.pro za pomocą klasy android.content.pm.PackageManager.

• Implementacja urządzenia MUSI zgłaszać obsługę funkcji android.hardware.audio.low_latency.
• Ciągłe opóźnienie w obie strony w przypadku dźwięku, zgodnie z definicją w sekcji 5.6 Opóźnienie dźwięku, MUSI wynosić 20 ms lub mniej i POWINNY wynosić 10 ms lub mniej na co najmniej jednej obsługiwanej ścieżce.
• Jeśli urządzenie ma 4-żyłowe gniazdo słuchawek 3, 5 mm, ciągłe opóźnienie w obie strony MUSI wynosić 20 ms lub mniej na ścieżce dźwięku przez gniazdo słuchawek.Powinno wynosić 10 ms lub mniej na ścieżce dźwięku przez gniazdo słuchawek.
• Implementacja urządzenia MUSI zawierać porty USB obsługujące tryb hosta USB i tryb urządzenia peryferyjnego USB.
• Tryb hosta USB MUSI implementować klasę dźwięku USB.
• Jeśli urządzenie ma port HDMI, jego implementacja MUSI obsługiwać wyjście stereo i 8 kanałów z głębokością bitową 20- lub 24-bitową oraz częstotliwością 192 kHz bez utraty głębi bitowej ani próbkowania.
• Implementacja urządzenia MUSI zgłaszać obsługę funkcji android.software.midi.
• Jeśli urządzenie ma 4-żyłowe gniazdo słuchawek 3,5 mm, zalecamy, aby jego implementacja była zgodna z sekcją Specyfikacja urządzenia mobilnego (gniazdo) w specyfikacji przewodowych zestawów słuchawkowych (wersja 1.1).

Wymagania dotyczące opóźnień i dźwięku USB MUSZĄ być spełnione za pomocą interfejsu API kolejki bufora PCM OpenSL ES.

Implementacja urządzenia, która zgłasza obsługę tej funkcji, POWINNA:

• Zapewnij odpowiedni poziom wydajności procesora podczas odtwarzania dźwięku.
• Zminimalizowanie niedokładności zegara audio i jego odchyleń od czasu standardowego.
• Zminimalizuj przesunięcie zegara audio względem procesora CLOCK_MONOTONIC, gdy oba są aktywne.
• Zminimalizuj opóźnienie dźwięku na przetwornikach na urządzeniu.
• Zminimalizuj opóźnienie dźwięku przesyłanego przez USB.
• Udokumentuj pomiary opóźnienia dźwięku na wszystkich ścieżkach.
• Zminimalizuj jitter w czasie wywołania zwrotnego bufora dźwięku, ponieważ wpływa on na procentową część pełnej przepustowości procesora wykorzystywanej przez wywołanie zwrotne.
• Nie dopuszczaj do żadnych przerw w odtwarzaniu dźwięku (wyjście) ani przepełnienia (wejścia) podczas normalnego użytkowania przy zgłoszonym opóźnieniu.
• zapewnić brak różnicy w opóźnieniach między kanałami;
• Minimalizowanie średniego opóźnienia MIDI w przypadku wszystkich transportów.
• Minimalizowanie zmienności opóźnienia MIDI przy obciążeniu (jitter) we wszystkich transmisjach.
• Dostarczaj dokładne sygnatury czasowe MIDI w przypadku wszystkich transportów.
• Zminimalizuj szum sygnału audio na przetwornikach na urządzeniu, w tym w okresie bezpośrednio po uruchomieniu „na zimno”.
• zapewnić zerową różnicę zegara audio między stronami wejścia i wyjścia odpowiednich punktów końcowych, gdy oba są aktywne; Przykłady odpowiednich punktów końcowych to mikrofon i głośnik na urządzeniu lub wejście i wyjście gniazda audio.
• Obsługuj wywołania zwrotne po zakończeniu buforowania dźwięku po stronie wejścia i wyjścia odpowiednich punktów końcowych w tym samym wątku, gdy oba są aktywne, i wejdź w wywołanie zwrotne wyjścia bezpośrednio po powrocie z wywołania zwrotnego wejścia. Jeśli nie można obsłużyć wywołań zwrotnych w tym samym wątku, wpisz wywołanie zwrotne wyjścia tuż po wywołaniu zwrotnym wejścia, aby umożliwić aplikacji spójne ustalanie czasu po stronie wejścia i wyjścia.
• Zminimalizuj różnicę fazową między buforowaniem dźwięku HAL po stronie wejścia i wyjścia odpowiednich punktów końcowych.
• Zminimalizuj opóźnienie dotyku.
• Zminimalizuj zmienność opóźnienia dotyku pod obciążeniem (jitter).

5.11. Rejestrowanie nieprzetworzonych

Od Androida 7.0 dodano nowe źródło nagrywania. Dostęp do niego można uzyskać za pomocą źródła dźwięku android.media.MediaRecorder.AudioSource.UNPROCESSED. W OpenSL ES można uzyskać do niego dostęp za pomocą wstępnie ustawionego rekordera SL_ANDROID_RECORDING_PRESET_UNPROCESSED .

Aby urządzenie mogło zgłaszać obsługę nieprzetworzonego źródła audio za pomocą właściwości android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED, MUSI spełniać wszystkie te wymagania :

• Urządzenie MUSI wykazywać w zakresie średnich częstotliwości w przybliżeniu płaską charakterystykę amplitudy w funkcji częstotliwości: ±10 dB w zakresie 100–7000 Hz.

• Urządzenie MUSI wykazywać poziomy amplitudy w zakresie niskich częstotliwości: konkretnie od ±20 dB w zakresie od 5 Hz do 100 Hz w porównaniu z zakresem średnich częstotliwości.

• Urządzenie MUSI wykazywać poziomy amplitudy w zakresie wysokich częstotliwości: konkretnie od ±30 dB od 7000 Hz do 22 kHz w porównaniu z zakresem średnich częstotliwości.

• Czułość wejścia audio MUSI być ustawiona tak, aby sygnał sinusoidalny o częstotliwości 1000 Hz odtwarzany z poziomem ciśnienia akustycznego (SPL) 94 dB dawał odpowiedź z wartością RMS wynoszącą 520 dla próbek 16-bitowych (lub -36 dB w przypadku próbek z precyzją zmiennoprzecinkową/podwójną).

• SNR > 60 dB (różnica między 94 dB SPL a ekwiwalentnym SPL własnego szumu, z wagami A).

• Całkowite zniekształcenie harmoniczne MUSI być mniejsze niż 1% dla 1 kHz przy 90 dB SPL na wejściu mikrofonu.

• Jedynym przetwarzaniem sygnału dozwolonym na ścieżce jest mnożnik poziomu, który ma na celu dostosowanie poziomu do pożądanego zakresu. Ten mnożnik poziomu NIE MOŻE powodować opóźnienia w ścieżce sygnału.

• Na ścieżce nie jest dozwolone żadne inne przetwarzanie sygnału, takie jak automatyczna regulacja wzmocnienia, filtr górnoprzepustowy czy eliminacja echa. Jeśli w ramach architektury z jakiegokolwiek powodu występuje przetwarzanie sygnału, należy je wyłączyć i wprowadzić zerowe opóźnienie lub dodatkowe opóźnienie na ścieżce sygnału.

Wszystkie pomiary SPL są wykonywane bezpośrednio przy mikrofonie, który jest testowany.

W przypadku wielu konfiguracji mikrofonów te wymagania mają zastosowanie do każdego mikrofonu.

Zdecydowanie zalecamy, aby urządzenie spełniało jak najwięcej wymagań dotyczących ścieżki sygnału dla nieprzetworzonego źródła nagrania. Jeśli urządzenie obsługuje nieprzetworzone źródło audio, musi spełniać wszystkie wymagania wymienione powyżej.

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

6.1. Narzędzia dla programistów

Implementacje urządzeń MUSZĄ obsługiwać narzędzia dla deweloperów Androida udostępniane w pakiecie Android SDK. Zgodne urządzenia z Androidem MUSZĄ być zgodne z:

• Android Debug Bridge (adb)
  • Implementacje urządzeń MUSZĄ obsługiwać wszystkie funkcje adb zgodnie z dokumentacją do pakietu Android SDK, w tym dumpsys .
  • Demon adb na urządzeniu MUSI być domyślnie nieaktywny i MUSI istnieć mechanizm dostępny dla użytkownika, który umożliwia włączenie Android Debug Bridge. Jeśli implementacja urządzenia pomija tryb urządzenia peryferyjnego USB, MUSI implementować Android Debug Bridge za pomocą sieci lokalnej (np. Ethernet lub 802.11).
  • Android obsługuje bezpieczne połączenia ADB. Bezpieczny adb włącza adb na znanych uwierzytelnionych hostach. Implementacje urządzeń MUSZĄ obsługiwać bezpieczny interfejs adb.
• Dalvik Debug Monitor Service (ddms)
  • Implementacje na urządzeniach MUSZĄ obsługiwać wszystkie funkcje DMS zgodnie z dokumentacją do pakietu Android SDK.
  • Ponieważ ddms używa adb, obsługa ddms powinna być domyślnie nieaktywna, ale MUSI być obsługiwana, gdy użytkownik aktywuje Android Debug Bridge (ADB), jak opisano powyżej.
• Monkey Implementacje na urządzeniach MUSZĄ zawierać platformę Monkey i musisz udostępnić ją aplikacjom.
• SysTrace
  • Implementacje na urządzeniu MUSZĄ obsługiwać narzędzie systrace zgodnie z dokumentacją pakietu Android SDK. Systrace musi być domyślnie nieaktywny i musi być dostępny dla użytkownika mechanizm włączania Systrace.
  • Większość systemów opartych na Linuksie i systemów Apple Macintosh rozpoznaje urządzenia z Androidem za pomocą standardowych narzędzi pakietu Android SDK bez dodatkowego wsparcia. Systemy Microsoft Windows zwykle wymagają sterownika dla nowych urządzeń z Androidem. (na przykład nowe identyfikatory dostawców i czasem nowe identyfikatory urządzeń wymagają niestandardowych sterowników USB w systemach Windows).
  • Jeśli implementacja urządzenia nie jest rozpoznawana przez narzędzie adb udostępniane w standardowym pakiecie SDK Androida, implementatorzy urządzeń MUSZĄ udostępnić sterowniki Windowsa, które pozwolą deweloperom na połączenie z urządzeniem za pomocą protokołu adb. Te sterowniki MUSZĄ być dostępne w wersjach 32- i 64-bitowej dla systemów Windows XP, Windows Vista, Windows 7, Windows 8 i Windows 10.

6.2. Opcje programisty

Android zawiera funkcje umożliwiające deweloperom konfigurowanie ustawień związanych z tworzeniem aplikacji. Implementacje na urządzeniach MUSZĄ obsługiwać intencję android.settings.APPLICATION_DEVELOPMENT_SETTINGS, aby wyświetlać ustawienia związane z rozwojem aplikacji. Implementacja na Androidzie domyślnie ukrywa menu Opcje programisty i umożliwia użytkownikom uruchomienie Opcji programisty po naciśnięciu siedmiu (7) razy opcji Ustawienia > Informacje o urządzeniu > Numer kompilacji. Implementacje na urządzeniach MUSZĄ zapewniać spójne działanie opcji dla deweloperów. W szczególności implementacje urządzeń MUSZĄ domyślnie ukrywać Opcje programisty i MUSZĄ udostępniać mechanizm włączania Opcji programisty, który jest zgodny z implementacją w głównym systemie Android.

7. Zgodność sprzętowa

Jeśli urządzenie zawiera określony komponent sprzętowy z odpowiednim interfejsem API dla deweloperów zewnętrznych, implementacja urządzenia MUSI implementować ten interfejs API zgodnie z opisem w dokumentacji pakietu Android SDK. Jeśli interfejs API w pakiecie SDK współdziała ze sprzętowym komponentem, który jest oznaczony jako opcjonalny, a urządzenie nie ma tego komponentu:

• Wciąż musisz podać pełne definicje klas (opisane w pakiecie SDK) interfejsów API komponentów.
• Interfejs API MUSI być zaimplementowany w taki sposób, aby nie wykonywał żadnych operacji.
• Metody interfejsu API MUSZĄ zwracać wartości null, gdy jest to dozwolone przez dokumentację pakietu SDK.
• Metody interfejsu API MUSZĄ zwracać implementacje no-op klas, w których wartości null nie są dozwolone zgodnie z dokumentacją pakietu SDK.
• Metody interfejsu API NIE MOGĄ zgłaszać wyjątków, które nie są opisane w dokumentacji pakietu SDK.

Typowym przykładem scenariusza, w którym obowiązują te wymagania, jest interfejs API telefonii: nawet na urządzeniach innych niż telefony te interfejsy API muszą być implementowane jako uzasadnione operacje bezczynne.

Implementacje urządzeń MUSZĄ konsekwentnie przekazywać dokładne informacje o konfiguracji sprzętu za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager dla tego samego odcisku palca kompilacji.

7.1. Wyświetlanie i grafika

Android zawiera funkcje, które automatycznie dostosowują zasoby aplikacji i układy interfejsu do urządzenia, aby aplikacje innych firm działały prawidłowo w różnych konfiguracjach sprzętowych . Urządzenia MUSZĄ prawidłowo implementować te interfejsy API i zachowania zgodnie z opisem w tej sekcji.

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

• fizyczna przekątna . Odległość w calach między dwoma przeciwległymi rogami podświetlonej części wyświetlacza.
• punkty na cal (dpi) . Liczba pikseli zawartych w liniowym zakresie poziomym lub pionowym 1 cala. W przypadku podanych wartości dpi zarówno poziomy, jak i pionowy dpi muszą mieścić się w zakresie.
• format . Stosunek pikseli dłuższego wymiaru do krótszego wymiaru ekranu. Na przykład wyświetlacz o wymiarach 480 x 854 pikseli miałby współczynnik 854/480 = 1, 779, czyli mniej więcej „16:9”.
• piksel niezależny od gęstości (dp) . Wirtualna jednostka piksela znormalizowana do ekranu o wyświetlaniu 160 dpi, obliczona jako: piksele = dps * (gęstość/160).

7.1.1. Konfiguracja ekranu

7.1.1.1. Rozmiar ekranu

Interfejs użytkownika Androida obsługuje różne rozmiary ekranu i pozwala aplikacjom uzyskiwać informacje o rozmiarze ekranu urządzenia (czyli „układzie ekranu”) za pomocą android.content.res.Configuration.screenLayout z SCREENLAYOUT_SIZE_MASK. Implementacje na urządzeniach MUSZĄ zgłaszać prawidłowy rozmiar ekranu zgodnie z definicją w dokumentacji pakietu Android SDK i określonym przez platformę Android na wyższym poziomie. W szczególności implementacje urządzeń MUSZĄ zgłaszać prawidłowy rozmiar ekranu zgodnie z tymi logicznymi wymiarami ekranu w pikselach niezależnych od gęstości (dp).

• Urządzenia MUSZĄ mieć ekran o rozmiarach co najmniej 426 dp x 320 dp („małe”), chyba że jest to urządzenie z Androidem Watch.
• Urządzenia, które zwracają rozmiar ekranu „normalny”, MUSZĄ mieć rozmiar ekranu co najmniej 480 x 320 dp.
• Urządzenia, które zwracają rozmiar ekranu „duży”, MUSZĄ mieć rozmiar ekranu co najmniej 640 x 480 dp.
• Urządzenia, które podają rozmiar ekranu „xlarge”, MUSZĄ mieć ekran o rozmiarach co najmniej 960 x 720 dp.

Ponadto:

• Urządzenia z Androidem na zegarek MUSZĄ mieć ekran o fizycznej przekątnej w zakresie od 1,1 do 2,5 cala.
• Urządzenia z Androidem Automotive MUSZĄ mieć ekran o fizycznej przekątnej co najmniej 6 cali.
• Ekrany urządzeń z Androidem Automotive MUSZĄ mieć rozmiar co najmniej 750 x 480 dp.
• Inne typy implementacji urządzeń z Androidem, w których ekran jest fizycznie zintegrowany, MUSZĄ mieć ekran o szerokości co najmniej 2,5 cala.

Raportowany rozmiar ekranu urządzenia NIE MOŻE się zmieniać.

Aplikacje opcjonalnie wskazują, które rozmiary ekranu obsługują, za pomocą atrybutu <supports-screens> w pliku AndroidManifest.xml. Implementacje urządzeń MUSZĄ prawidłowo obsługiwać deklarowaną przez aplikację obsługę ekranów małych, normalnych, dużych i bardzo dużych, zgodnie z opisem w dokumentacji pakietu SDK Androida.

7.1.1.2. Format obrazu

Chociaż nie ma ograniczeń dotyczących wartości proporcji ekranu fizycznego, proporcje ekranu powierzchni, na której renderowane są aplikacje innych firm i które można uzyskać na podstawie wartości zgłoszonych przez DisplayMetrics, MUSZĄ spełniać te wymagania:

• Jeśli parametr uiMode ma wartość UI_MODE_TYPE_WATCH, wartość proporcji może wynosić 1,0 (1:1).
• Jeśli aplikacja innej firmy wskazuje, że można zmienić jej rozmiar za pomocą atrybutu android:resizeableActivity, nie ma żadnych ograniczeń dotyczących wartości proporcji.
• W wszystkich pozostałych przypadkach współczynnik proporcji MUSI mieć wartość od 1,3333 (4:3) do 1,86 (około 16:9), chyba że aplikacja wyraźnie wskazuje, że obsługuje większy współczynnik proporcji ekranu za pomocą wartości metadanych maxAspectRatio.

7.1.1.3. Gęstość ekranu

Interfejs użytkownika Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić deweloperom aplikacji kierowanie zasobów aplikacji. Domyślnie implementacje urządzeń MUSZĄ zgłaszać tylko jedną z tych logicznych gęstości interfejsu Androida za pomocą interfejsu API DENSITY_DEVICE_STABLE, a ta wartość NIE MOŻE się zmieniać w żaden sposób. Urządzenie MOŻE jednak zgłaszać inną dowolną gęstość w zależności od zmian wprowadzonych przez użytkownika w konfiguracji wyświetlacza (np. rozmiar wyświetlacza) po pierwszym uruchomieniu.

• 120 dpi (ldpi)
• 160 dpi (mdpi)
• 213 dpi (tvdpi)
• 240 dpi (hdpi)
• 260 dpi
• 280 dpi
• 300 dpi (300 dpi)
• 320 dpi (xhdpi)
• 340 dpi (340 dpi)
• 360 dpi
• 400 dpi (400 dpi)
• 420 dpi (420 dpi)
• 480 dpi (xxhdpi)
• 560 dpi (560 dpi)
• 640 dpi (xxxhdpi)

Implementacje urządzeń powinny zdefiniować standardową gęstość w ramach Androida, która jest liczbowo najbliższa fizycznej gęstości ekranu, chyba że ta gęstość logiczna spowoduje, że zgłaszany rozmiar ekranu będzie niższy niż minimalny obsługiwany rozmiar. Jeśli standardowa gęstość ramki Androida, która pod względem liczbowym jest najbliższa fizycznej gęstości, powoduje, że rozmiar ekranu jest mniejszy niż najmniejszy obsługiwany zgodny rozmiar ekranu (szerokość 320 dp), implementacje urządzeń POWINNY zgłaszać następną niższą standardową gęstość ramki Androida.

W przypadku implementacji na urządzeniach MOCNO ZALECAMY udostępnienie użytkownikom ustawienia umożliwiającego zmianę rozmiaru wyświetlacza. Jeśli istnieje implementacja, która zmienia rozmiar wyświetlacza urządzenia, MUSI ona być zgodna z implementacją AOSP w następujący sposób:

• Rozmiar wyświetlacza NIE MOŻE być powiększony ponad 1,5-krotną wartość gęstości natywnej ani nie może powodować, że minimalny wymiar ekranu będzie mniejszy niż 320 dp (cokolwiek nastąpi wcześniej).
• Rozmiar wyświetlacza NIE MOŻE być przeskalowany do wartości mniejszej niż 0,85-krotna gęstość natywna.
• Aby zapewnić dobrą użyteczność i spójność rozmiarów czcionek, zalecamy zastosowanie tych opcji skalowania wyświetlania natywnych (z zachowaniem limitów określonych powyżej).
• Małe: 0,85 x
• Domyślnie: 1x (rodzinna skala wyświetlacza)
• Duża: 1,15 x
• Większy: 1,3 x
• Największy 1,45x

7.1.2. Dane dotyczące wyświetleń

Implementacje urządzeń MUSZĄ przekazywać prawidłowe wartości wszystkich danych wyświetlacza zdefiniowanych w android.util.DisplayMetrics i MUSZĄ przekazywać te same wartości niezależnie od tego, czy jako domyślny wyświetlacz jest używany wbudowany czy zewnętrzny ekran.

7.1.3. Orientacja ekranu

Urządzenia MUSZĄ zgłaszać, które orientacje ekranu obsługują (android.hardware.screen.portrait lub android.hardware.screen.landscape) oraz MUSZĄ zgłaszać co najmniej jedną obsługiwaną orientację. Na przykład urządzenie z niezmienną orientacją poziomą ekranu, takie jak telewizor czy laptop, POWINNA zgłaszać tylko android.hardware.screen.landscape.

Urządzenia, które obsługują obie orientacje ekranu, MUSZĄ obsługiwać dynamiczną orientację ekranu w orientacji pionowej lub poziomej. Oznacza to, że urządzenie musi uwzględnić prośbę aplikacji o określoną orientację ekranu. Implementacje urządzeń MOGĄ domyślnie wybierać orientację pionową lub poziomą.

Urządzenia MUSZĄ zwracać prawidłową wartość bieżącego położenia urządzenia, gdy zostanie zapytanie o to za pomocą android.content.res.Configuration.orientation, android.view.Display.getOrientation() lub innych interfejsów API.

Urządzenia NIE MOGĄ zmieniać zgłaszanego rozmiaru ekranu ani gęstości podczas zmiany orientacji.

7.1.4. akceleracja grafiki 2D i 3D;

Implementacje urządzeń MUSZĄ obsługiwać interfejs OpenGL ES 1.0 i 2.0, zgodnie z opisem i szczegółami w dokumentacji pakietu SDK Androida. Implementacje na urządzeniach powinny obsługiwać OpenGL ES 3.0, 3.1 lub 3.2 na urządzeniach, które je obsługują. Implementacje na urządzeniu MUSZĄ obsługiwać Android RenderScript , zgodnie z opisem w dokumentacji pakietu SDK Androida.

Implementacje na urządzeniu MUSZĄ poprawnie identyfikować się jako obsługujące OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0, OpenGL 3.1 lub OpenGL 3.2. To oznacza, że

• Zarządzane interfejsy API (np. za pomocą metody GLES10.getString()) MUSZĄ zgłaszać obsługę OpenGL ES 1.0 i OpenGL ES 2.0.
• Natywna biblioteka OpenGL w języku C/C++ (interfejsy API dostępne dla aplikacji za pomocą libGLES_v1CM.so, libGLES_v2.so lub libEGL.so) MUSZĄ raportować obsługę OpenGL ES 1.0 i OpenGL ES 2.0.
• Implementacje urządzeń, które deklarują obsługę OpenGL ES 3.0, 3.1 lub 3.2, MUSZĄ obsługiwać odpowiednie zarządzane interfejsy API i mieć obsługę natywnych interfejsów API C/C++. W implementacjach na urządzeniu, które deklarują obsługę OpenGL ES 3.0, 3.1 lub 3.2, plik libGLESv2.so MUSI eksportować odpowiednie symbole funkcji oprócz symboli funkcji OpenGL ES 2.0.

Android udostępnia pakiet rozszerzeń OpenGL ES z interfejsami Java i natywnym wsparciem dla zaawansowanych funkcji graficznych, takich jak teselacja i format kompresji tekstur ASTC. Implementacje urządzeń z Androidem MUSZĄ obsługiwać pakiet rozszerzeń, jeśli urządzenie obsługuje OpenGL ES 3.2, i MOGĄ to robić w innych przypadkach. Jeśli pakiet rozszerzeń jest obsługiwany w całości, urządzenie MUSI rozpoznawać obsługę za pomocą flagi funkcji android.hardware.opengles.aep.

Implementacje na urządzeniach MOGĄ stosować dowolne rozszerzenia OpenGL ES. Implementacje urządzeń muszą jednak zgłaszać za pomocą zarządzanych i natywnych interfejsów API OpenGL ES wszystkie obsługiwane ciągi znaków rozszerzeń, a z drugiej strony nie muszą zgłaszać ciągów znaków rozszerzeń, których nie obsługują.

Pamiętaj, że Android obsługuje opcjonalne określanie przez aplikacje wymaganych formatów kompresji tekstur OpenGL. Te formaty są zwykle specyficzne dla dostawcy. Implementacje na urządzeniach nie muszą implementować żadnego konkretnego formatu kompresji tekstur. Należy jednak dokładnie podać wszystkie obsługiwane formaty kompresji tekstur za pomocą metody getString() w interfejsie OpenGL API.

Android zawiera mechanizm, który umożliwia aplikacjom oświadczenie, że chcą włączyć przyspieszenie sprzętowe grafiki 2D na poziomie aplikacji, aktywności, okna lub widoku za pomocą tagu manifestu android:hardwareAccelerated lub bezpośrednich wywołań interfejsu API.

Implementacje urządzeń MUSZĄ domyślnie włączać akcelerację sprzętową i MUSZĄ ją wyłączać, jeśli deweloper zażąda tego, ustawiając android:hardwareAccelerated = „false” lub wyłączając akcelerację sprzętową bezpośrednio za pomocą interfejsów View API na Androida.

Ponadto implementacje na urządzeniach MUSZĄ zachowywać się zgodnie z dokumentacją pakietu Android SDK dotyczącą akceleracji sprzętowej .

Android zawiera obiekt TextureView, który umożliwia deweloperom bezpośrednią integrację tekstur OpenGL ES przyspieszanych sprzętowo jako celów renderowania w hierarchii interfejsu. Implementacje na urządzeniu MUSZĄ obsługiwać interfejs TextureView API i MUSZĄ zachowywać się zgodnie z implementacją na Androidzie.

Android obsługuje EGL_ANDROID_RECORDABLE, czyli atrybut EGLConfig, który wskazuje, czy EGLConfig obsługuje renderowanie do okna ANativeWindow, które zapisuje obrazy w filmie. Implementacje urządzeń MUSZĄ obsługiwać rozszerzenie EGL_ANDROID_RECORDABLE.

7.1.5. Tryb zgodności ze starszymi wersjami aplikacji

Android określa „tryb zgodności”, w którym framework działa w trybie „normalnego” rozmiaru ekranu (szerokość 320 dp) na potrzeby starszych aplikacji, które nie zostały opracowane na potrzeby starszych wersji Androida, które nie obsługują niezależności od rozmiaru ekranu.

• Android Automotive nie obsługuje starszego trybu zgodności.
• Wszystkie inne implementacje urządzeń MUSZĄ zawierać obsługę starszego trybu zgodności aplikacji, który jest implementowany przez kod źródłowy Androida w ramach upstream. Oznacza to, że implementacje na urządzeniach NIE MOGĄ zmieniać wyzwalaczy ani progów, przy których aktywowany jest tryb zgodności, ani zmieniać działania samego trybu zgodności.

7.1.6. Technologia ekranu

Platforma Android zawiera interfejsy API, które umożliwiają aplikacjom renderowanie bogatych grafik na ekranie. Urządzenia MUSZĄ obsługiwać wszystkie te interfejsy API zgodnie z definicją w pakiecie SDK Androida, chyba że w tym dokumencie jest to wyraźnie dozwolone.

• Urządzenia MUSZĄ obsługiwać wyświetlacze, które mogą renderować 16-bitową grafikę kolorową, i POWINNY obsługiwać wyświetlacze, które mogą renderować 24-bitową grafikę kolorową.
• Urządzenia MUSZĄ obsługiwać wyświetlacze, które mogą renderować animacje.
• Używana technologia wyświetlania MUSI mieć współczynnik proporcji pikseli (PAR) w zakresie od 0,9 do 1,15. Oznacza to, że współczynnik proporcji piksela MUSI być zbliżony do kwadratu (1,0) z tolerancją 10–15%.

7.1.7. Wyświetlacze dodatkowe

Android obsługuje wyświetlacz dodatkowy, aby umożliwić udostępnianie multimediów, oraz interfejsy API dla programistów, aby umożliwić dostęp do wyświetlaczy zewnętrznych. Jeśli urządzenie obsługuje wyświetlacz zewnętrzny przez połączenie przewodowe, bezprzewodowe lub za pomocą wbudowanego dodatkowego wyświetlacza, implementacja urządzenia MUSI implementować interfejs API menedżera wyświetlacza zgodnie z opisem w dokumentacji pakietu SDK Androida.

7.2. Urządzenia wejściowe

Urządzenia MUSZĄ obsługiwać ekran dotykowy lub spełniać wymagania wymienione w sekcji 7.2.2 dotyczące nawigacji bezdotykowej.

7.2.1. Klawiatura

Implementacje na urządzeniu:

• MUSI zawierać obsługę platformy Input Management Framework (która umożliwia deweloperom zewnętrznym tworzenie edytorów metod wprowadzania, czyli klawiatur wirtualnych), zgodnie z informacjami na stronie http://developer.android.com.
• Musisz udostępnić co najmniej 1 implementację klawiatury ekranowej (niezależnie od tego, czy jest dostępna klawiatura fizyczna), z wyjątkiem urządzeń z Androidem Watch, na których rozmiar ekranu nie pozwala na korzystanie z klawiatury ekranowej.
• MOŻE zawierać dodatkowe implementacje klawiatury ekranowej.
• MOŻE zawierać klawiaturę sprzętową.
• Nie można używać klawiatury sprzętowej, która nie pasuje do jednego z formatów określonych w android.content.res.Configuration.keyboard (QWERTY lub 12 klawiszy).

7.2.2. Nawigacja bezdotykowa

Implementacje na urządzeniu:

• MOŻNA pominąć opcję nawigacji bezdotykowej (kulka, pad kierunkowy lub koło) w przypadku implementacji urządzenia, która nie jest urządzeniem z Androidem TV.
• Musisz podać prawidłową wartość dla android.content.res.Configuration.navigation .
• MUSI zawierać rozsądny alternatywny mechanizm interfejsu użytkownika do zaznaczania i edytowania tekstu, który jest zgodny z silnikami zarządzania danymi wejściowymi. W ramach implementacji open source Androida dodany został mechanizm wyboru odpowiedni do korzystania z urządzeń, które nie mają elementów sterujących dotykowych.

7.2.3. Klawisze nawigacyjne

Funkcje Home, Recents i Back (odpowiednio mapowane na zdarzenia KEYCODE_HOME, KEYCODE_APP_SWITCH i KEYCODE_BACK) są niezbędne w ramach paradygmatu nawigacji w Androidzie, dlatego:

• Implementacje urządzeń przenośnych z Androidem MUSZĄ zawierać funkcje ekranu głównego, ostatnich i wstecz.
• Implementacje urządzeń z Androidem TV MUSZĄ zapewniać funkcje ekranu głównego i wstecz.
• Implementacje urządzeń z Androidem Watch MUSZĄ zawierać funkcję Główna dostępną dla użytkownika oraz funkcję Wstecz, z wyjątkiem trybu UI_MODE_TYPE_WATCH .
• Implementacje urządzeń z Androidem Watch (a nie innych typów urządzeń z Androidem) MOGĄ używać zdarzenia długiego naciśnięcia klawisza KEYCODE_BACK i nie wysyłać go do aplikacji na pierwszym planie.
• Implementacje Androida Automotive MUSZĄ zawierać funkcję Home oraz MOGĄ zawierać funkcje Wstecz i Ostatnie.
• Wszystkie inne typy implementacji urządzeń MUSZĄ zawierać funkcje Wróć i Strona główna.

Te funkcje MOGĄ być realizowane za pomocą specjalnych przycisków fizycznych (takich jak mechaniczne lub pojemnościowe przyciski dotykowe) lub MOGĄ być realizowane za pomocą specjalnych klawiszy programowych na określonej części ekranu, gestów, panelu dotykowego itp. Android obsługuje obie implementacje. Wszystkie te funkcje MUSZĄ być dostępne po wykonaniu pojedynczej czynności (np. kliknięcia, podwójnego kliknięcia lub gestu).

Funkcja Ostatnie (jeśli jest dostępna) MUSI mieć widoczny przycisk lub ikonę, chyba że jest ukryta razem z innymi funkcjami nawigacji w trybie pełnoekranowym. Nie dotyczy to urządzeń, które są aktualizowane z wcześniejszych wersji Androida i mają fizyczne przyciski do nawigacji, ale nie mają przycisku Ostatnie.

Funkcje Home i Back (jeśli są dostępne) MUSZĄ mieć widoczny przycisk lub ikonę, chyba że są ukryte razem z innymi funkcjami nawigacji w trybie pełnoekranowym lub gdy parametr uiMode UI_MODE_TYPE_MASK ma wartość UI_MODE_TYPE_WATCH.

Funkcja menu została wycofana na rzecz paska czynności od wersji Androida 4.0. Dlatego nowe urządzenia z Androidem 7.1 i nowszym NIE MOGĄ mieć dedykowanego przycisku fizycznego do funkcji menu. Na starszych urządzeniach NIE należy implementować dedykowanego fizycznego przycisku menu. Jeśli jednak taki przycisk jest dostępny, a urządzenie obsługuje aplikacje z wartością targetSdkVersion > 10, implementacja urządzenia:

• NALEŻY wyświetlić przycisk menu czynności na pasku czynności, gdy jest on widoczny, a wyskakujące menu czynności nie jest puste. W przypadku implementacji na urządzeniu wprowadzonej przed Androidem 4.4, ale z aktualizacją do Androida 7.1, zalecamy to rozwiązanie.
• Nie wolno modyfikować pozycji wyskakującego okienka akcji wyświetlanego po kliknięciu przycisku akcji na pasku działań.
• MOŻE wyświetlić wyskakujące okienko z dodatkowymi działaniami w zmodyfikowanej pozycji na ekranie, gdy zostanie wyświetlone po kliknięciu fizycznego przycisku menu.

Ze względu na zgodność wsteczną implementacje urządzeń MUSZĄ udostępnić aplikacjom funkcję menu, gdy wartość targetSdkVersion jest mniejsza niż 10, za pomocą przycisku fizycznego, klawisza programowego lub gestów. Ta funkcja menu powinna być wyświetlana, chyba że jest ukryta razem z innymi funkcjami nawigacji.

Implementacje urządzeń z Androidem obsługujące działanie asystenta lub VoiceInteractionService MUSZĄ umożliwiać uruchamianie aplikacji asystenta za pomocą pojedynczej interakcji (np. dotknięcia, podwójnego kliknięcia lub gestu), gdy inne klawisze nawigacyjne są widoczne. ZDECYDOWANIE POLECAMY użycie przycisku ekranu głównego. Wyznaczona interakcja MUSI uruchamiać wybraną przez użytkownika aplikację pomocniczą, czyli aplikację, która implementuje interfejs VoiceInteractionService, lub aktywność obsługującą działanie ACTION_ASSIST.

Implementacje urządzeń MOGĄ używać oddzielnej części ekranu do wyświetlania klawiszy nawigacyjnych, ale w takim przypadku MUSZĄ spełniać te wymagania:

• Klawisze nawigacyjne w implementacji urządzenia MUSZĄ używać oddzielnej części ekranu, niedostępnej dla aplikacji. Nie mogą one zasłaniać ani w inny sposób zakłócać części ekranu dostępnej dla aplikacji.
• Implementacje urządzeń MUSZĄ udostępniać część ekranu aplikacjom, które spełniają wymagania określone w sekcji 7.1.1 .
• Implementacje urządzeń MUSZĄ wyświetlać klawisze nawigacyjne, gdy aplikacje nie określają trybu interfejsu systemu lub określają SYSTEM_UI_FLAG_VISIBLE.
• Implementacje urządzeń MUSZĄ wyświetlać klawisze nawigacyjne w nieinwazyjnym trybie „niskiego profilu” (np. przyciemnionym), gdy aplikacje określają flagę SYSTEM_UI_FLAG_LOW_PROFILE.
• Implementacje na urządzeniu MUSZĄ ukrywać klawisze nawigacji, gdy aplikacje określają flagę SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Dotykowe wprowadzanie danych

Implementacje urządzeń powinny mieć system wskaźnika (podobny do myszy lub dotykowy). Jeśli jednak implementacja urządzenia nie obsługuje systemu wprowadzania danych za pomocą wskaźnika, nie może zgłaszać stałej funkcji android.hardware.touchscreen ani android.hardware.faketouch. Implementacje urządzeń, które zawierają system wprowadzania danych za pomocą wskaźnika:

• NALEŻY obsługiwać wskaźniki śledzone niezależnie, jeśli system wejściowy urządzenia obsługuje wiele wskaźników.
• MUSI raportować wartość android.content.res.Configuration.touchscreen odpowiadającą typowi konkretnego ekranu dotykowego na urządzeniu.

Android obsługuje różne ekrany dotykowe, panele dotykowe i urządzenia dotykowe z fałszywym dotykiem. Implementacje urządzeń z ekranem dotykowym są powiązane z ekranem w taki sposób, aby użytkownik miał wrażenie bezpośredniej manipulacji elementami na ekranie. Ponieważ użytkownik dotyka ekranu bezpośrednio, system nie wymaga żadnych dodatkowych elementów, które wskazywałyby na obiekty, którymi można manipulować. Natomiast fałszywy interfejs dotykowy zapewnia system wprowadzania danych, który w przybliżeniu naśladuje możliwości ekranu dotykowego. Na przykład mysz lub pilot, który steruje kursorem na ekranie, umożliwia działanie zbliżone do dotyku, ale wymaga od użytkownika najpierw wskazania lub skupienia się na obiekcie, a potem kliknięcia. Wiele urządzeń wejściowych, takich jak mysz, trackpad, mysz powietrzna z użyciem żyroskopu, wskaźnik z użyciem żyroskopu, joystick i trackpad wielodotykowy, może obsługiwać fałszywe interakcje dotykowe. Android zawiera stałą android.hardware.faketouch, która odpowiada urządzeniu do wprowadzania danych niebędącemu urządzeniem dotykowym (z wskaźnikiem), np. myszce lub trackpadowi, które może odpowiednio emulować dane dotykowe (w tym obsługę podstawowych gestów) i wskazuje, że urządzenie obsługuje emulowany podzbiór funkcji ekranu dotykowego. Implementacje urządzeń, które deklarują funkcję fałszywego dotyku, MUSZĄ spełniać wymagania dotyczące fałszywego dotyku podane w sekcji 7.2.5 .

Implementacje urządzeń MUSZĄ zgłaszać prawidłową funkcję odpowiadającą używanemu typowi danych wejściowych. Implementacje urządzeń, które zawierają ekran dotykowy (jednodotykowy lub lepszy), MUSZĄ zgłaszać stałą funkcję platformy android.hardware.touchscreen. Implementacje urządzeń, które raportują stałą platformy android.hardware.touchscreen, MUSZĄ również raportować stałą platformy android.hardware.faketouch. Implementacje urządzeń, które nie mają ekranu dotykowego (i korzystają tylko z wskaźnika), NIE MOGĄ zgłaszać żadnych funkcji ekranu dotykowego. Muszą zgłaszać tylko android.hardware.faketouch, jeśli spełniają wymagania dotyczące fałszywego dotyku podane w sekcji 7.2.5.

7.2.5. Symulowane dotykowe wprowadzanie danych

Implementacje urządzeń, które deklarują obsługę android.hardware.faketouch:

• MUSI raportować pozycję kursora na ekranie w uwzględnieniu osi X i Y oraz wyświetlać wizualny wskaźnik na ekranie.
• Musisz zgłaszać zdarzenie dotyku z kodem działania, który określa stan zmiany, jaka zachodzi w wskaźniku przesuwającym się w dół lub w górę po ekranie .
• MUSI obsługiwać kursor w dół i w górę na obiekcie na ekranie, co pozwala użytkownikom na emulowanie dotknięcia obiektu na ekranie.
• MUSI obsługiwać w tym samym miejscu na ekranie w ramach określonego progu czasowego wciśnięcie i puszczenie wskaźnika, a następnie wciśnięcie i puszczenie wskaźnika w tym samym miejscu na ekranie, co pozwala użytkownikom zasymulować dwukrotne kliknięcie na ekranie.
• MUSI obsługiwać wciśnięcie wskaźnika w dowolnym miejscu na ekranie, przesuwanie wskaźnika do dowolnego innego miejsca na ekranie, a następnie zwolnienie wskaźnika, co pozwala użytkownikom emulować przeciąganie palcem.
• MUSI obsługiwać wskaźnik w dół, a następnie musi umożliwiać użytkownikom szybkie przenoszenie obiektu w inne miejsce na ekranie, a następnie wskaźnik w górę na ekranie, co pozwala użytkownikom przenosić obiekty na ekranie.

Urządzenia, które deklarują obsługę android.hardware.faketouch.multitouch.distinct, MUSZĄ spełniać wymagania dotyczące obsługi faketouch podane powyżej. Muszą też obsługiwać śledzenie oddzielnie co najmniej 2 niezależnych urządzeń wskaźnikowych.

7.2.6. Obsługa kontrolera gier

Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać mapowanie przycisków kontrolerów gier zgodnie z poniższą listą. Wdrożenie na Androidzie obejmuje sterowanie kontrolerem, które spełnia ten wymóg.

7.2.6.1. Mapowania przycisków

Implementacje urządzeń z Androidem TV MUSZĄ obsługiwać te mapowania klawiszy:

Przycisk	Użycie HID 2	Przycisk Android
A 1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B 1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X 1	0x09 0x0004	KEYCODE_BUTTON_X (99)
T 1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Joystick w górę 1 Joystick w dół 1	0x01 0x0039 3	AXIS_HAT_Y 4
Przycisk w lewo na padzie kierunkowym 1 Przycisk w prawo na padzie kierunkowym 1	0x01 0x0039 3	AXIS_HAT_X 4
Przycisk lewego uchwytu 1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Przycisk na prawym uchwycie 1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Kliknięcie lewej gałki analogowej 1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Kliknięcie prawej gałki analogowej 1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Strona główna 1	0x0c 0x0223	KEYCODE_HOME (3)
Wstecz 1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Powyższe zastosowania HID muszą być zadeklarowane w ramach CA kontrolera do gier (0x01 0x0005).

3 Ta wartość musi mieć minimalną wartość logiczną 0, maksymalną wartość logiczną 7, minimalną wartość fizyczną 0, maksymalną wartość fizyczną 315, jednostki w stopniach oraz rozmiar raportu 4. Wartość logiczna jest zdefiniowana jako obrót zgodnie z ruchem wskazówek zegara od osi pionowej. Na przykład wartość logiczna 0 oznacza brak obrotu i wciśnięcie przycisku w górę, a wartość logiczna 1 oznacza obrót o 45° i wciśnięcie przycisków w górę i w lewo.

4. MotionEvent

Analog Controls 1	Użycie HID	Przycisk Android
Lepiej:	0x02 0x00C5	AXIS_LTRIGGER
Prawy spust	0x02 0x00C4	AXIS_RTRIGGER
Lewy joystick	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Prawy joystick	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Pilot

Implementacje urządzeń z Androidem TV powinny zawierać pilota, który umożliwi użytkownikom dostęp do interfejsu telewizora. Pilot może być pilotem fizycznym lub opartym na oprogramowaniu, dostępnym z telefonu komórkowego lub tabletu. Pilot sterujący MUSI spełniać poniższe wymagania.

• Funkcjonalność wyszukiwania . Implementacje urządzeń MUSZĄ wywołać KEYCODE_SEARCH (lub KEYCODE_ASSIST, jeśli urządzenie obsługuje asystenta), gdy użytkownik wywoła wyszukiwanie głosowe na pilocie zdalnym fizycznym lub opartym na oprogramowaniu.
• Nawigacja . Wszystkie piloty do Androida TV MUSZĄ zawierać przyciski Wstecz, Ekran główny i Wybierz oraz obsługiwać zdarzenia D-pada .

7.3. Czujniki

Android zawiera interfejsy API umożliwiające dostęp do różnych typów czujników. Implementacje urządzeń zazwyczaj mogą pomijać te czujniki, jak opisano w następnych podrozdziałach. Jeśli urządzenie zawiera określony typ czujnika, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, implementacja urządzenia MUSI implementować ten interfejs API zgodnie z dokumentacją pakietu Android SDK i dokumentacją Androida na temat źródeł otwartych dotyczącą czujników . Na przykład implementacje na urządzeniach:

• MUSI prawidłowo raportować obecność lub brak czujników zgodnie z klasą android.content.pm.PackageManager.
• MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody SensorManager.getSensorList() lub podobnych.
• MUSI działać prawidłowo w przypadku wszystkich innych interfejsów API czujników (np. zwracać wartość „true” lub „false” w odpowiednich przypadkach, gdy aplikacje próbują zarejestrować słuchaczy, nie wywoływać słuchaczy czujników, gdy nie ma odpowiednich czujników itp.).
• Zgłoszenia wszystkich pomiarów czujników muszą być zgłaszane za pomocą odpowiednich wartości z Międzynarodowego Systemu Jednostek (metrycznych) dla każdego typu czujnika zgodnie z definicją w dokumentacji Android SDK.
• Raportuje czas zdarzenia w nanosekundach zgodnie z definicją w dokumentacji Android SDK, reprezentujący czas wystąpienia zdarzenia i zsynchronizowany z zegarem SystemClock.elapsedRealtimeNano(). ZALECAMY, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, ponieważ dzięki temu będą mogły przejść na przyszłe wersje platformy, w których mogą stać się wymaganym komponentem. Błąd synchronizacji powinien być mniejszy niż 100 ms.
• Musi przekazywać dane z czujnika z maksymalnym opóźnieniem 100 ms + 2 * sample_time w przypadku danych z przesyłanego czujnika z minimalnym wymaganym opóźnieniem 5 ms + 2 * sample_time, gdy aktywny jest procesor aplikacji. To opóźnienie nie obejmuje opóźnień związanych z filtrowaniem.
• Pierwsza próbka czujnika MUSI zostać zgłoszona w ciągu 400 milisekund + 2 * sample_time od momentu aktywacji czujnika. W przypadku tej próbki dopuszczalna jest dokładność 0.

Powyższa lista nie jest wyczerpująca. Należy wziąć pod uwagę udokumentowane działanie pakietu Android SDK i dokumentację na temat czujników w dokumentacji do Androida w wersji open source.

Niektóre typy czujników są złożone, co oznacza, że mogą być wyprowadzone z danych pochodzących z co najmniej jednego innego czujnika. (np. czujnik orientacji i czujnik przyspieszenia liniowego). Implementacje urządzeń powinny wykorzystywać te typy czujników, jeśli zawierają wymagane czujniki fizyczne opisane w sekcji Typy czujników . Jeśli implementacja urządzenia zawiera czujnik złożony, MUSI ona być zaimplementowana zgodnie z opisem w dokumentacji Androida Open Source dotyczącej czujników złożonych .

Niektóre czujniki Androida obsługują tryb ciągłego wyzwalania , który zwraca dane w ciągły sposób. Aby interfejs API wskazany w dokumentacji pakietu Android SDK był czujnikiem ciągłym, implementacje na urządzeniu MUSZĄ stale dostarczać okresowe próbki danych, które POWINNY mieć jitter poniżej 3%, gdzie jitter jest zdefiniowany jako odchylenie standardowe różnicy wartości raportowanych sygnatur czasowych między kolejnymi zdarzeniami.

Pamiętaj, że implementacje urządzeń MUSZĄ zapewnić, aby strumień zdarzeń czujnika NIE blokował procesora urządzenia w przechodzeniu w stan zawieszenia lub budzenia z tego stanu.

W przypadku aktywnych czujników zużycie energii NIE POWINNA przekraczać sumy zużycia energii poszczególnych czujników.

7.3.1. Akcelerometr

Implementacje na urządzeniach powinny zawierać 3-osiowy akcelerometr. W przypadku urządzeń przenośnych z Androidem, implementacji Androida Automotive i urządzeń z Androidem Watch MOCNO zaleca się uwzględnienie tego czujnika. Jeśli implementacja urządzenia zawiera 3-osiowy akcelerometr, to:

• NALEŻY zaimplementować i zgłosić czujnik TYPE_ACCELEROMETER .
• W przypadku zegarków z Androidem aplikacja MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 50 Hz, ponieważ takie urządzenia mają bardziej rygorystyczne ograniczenia dotyczące zużycia energii. W przypadku wszystkich innych typów urządzeń częstotliwość ta powinna wynosić 100 Hz.
• Powinny raportować zdarzenia z częstotliwością co najmniej 200 Hz.
• MUSI być zgodny z systemem współrzędnych czujników Androida opisanym w interfejsach API Androida. Implementacje Androida Automotive MUSZĄ być zgodne z systemem współrzędnych czujników samochodowych Androida .
• MUSI być w stanie mierzyć od swobodnego spadania do 4-krotnego przyspieszenia ziemskiego (4 g) lub więcej w dowolnej osi.
• Rozdzielczość musi wynosić co najmniej 12 bitów, a najlepiej 16 bitów.
• POWINIEN być kalibrowany podczas użytkowania, jeśli jego właściwości zmieniają się w trakcie cyklu życia, oraz kompensować i zachowywać parametry kompensacji między ponownymi uruchamieniami urządzenia.
• POWINIEN być kompensowany temperaturowo.
• Musi mieć odchylenie standardowe nie większe niż 0,05 m/s2, gdzie odchylenie standardowe należy obliczyć dla każdej osi na podstawie próbek zebranych w ciągu co najmniej 3 sekund z najwyższą częstotliwością próbkowania.
• NALEŻY zaimplementować czujniki złożone TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER zgodnie z opisem w dokumentacji pakietu SDK Androida. W przypadku obecnych i nowych urządzeń z Androidem ZALECAMY implementację czujnika złożonego TYPE_SIGNIFICANT_MOTION. Jeśli w urządzeniu zastosowano któryś z tych czujników, suma ich poboru mocy MUSI być zawsze mniejsza niż 4 mW, a każdy z nich powinien być mniejszy niż 2 mW i 0,5 mW w stanie dynamicznym lub stałym.
• Jeśli uwzględniono czujnik żyroskopu, MUSISZ zaimplementować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION oraz POWINIEN implementować czujnik złożony TYPE_GAME_ROTATION_VECTOR. Zalecamy implementację czujnika TYPE_GAME_ROTATION_VECTOR na istniejących i nowych urządzeniach z Androidem.
• W przypadku czujnika żyroskopu i czujnika magnetometru MUSISZ zaimplementować czujnik złożony TYPE_ROTATION_VECTOR.

7.3.2. Magnetometr

Implementacje urządzeń powinny zawierać 3-osiowy magnetometr (kompas). Jeśli urządzenie ma 3-osiowy magnetometr:

• NALEŻY zaimplementować czujnik TYPE_MAGNETIC_FIELD i MOŻNA zaimplementować czujnik TYPE_MAGNETIC_FIELD_UNCALIBRATED. Zalecamy implementację czujnika TYPE_MAGNETIC_FIELD_UNCALIBRATED na istniejących i nowych urządzeniach z Androidem.
• Musi być w stanie raportować zdarzenia z częstotliwością co najmniej 10 Hz i powinna raportować zdarzenia z częstotliwością co najmniej 50 Hz.
• MUSI być zgodny z systemem współrzędnych czujników Androida opisanym w interfejsach API Androida.
• MUSI być w stanie mierzyć wartości od -900 µT do +900 µT na każdej osi przed nasyceniem.
• Wartość przesunięcia dla stałego żelaza MUSI być mniejsza niż 700 µT, a powinna być mniejsza niż 200 µT. Aby to osiągnąć, należy umieścić magnetometr z dala od pól magnetycznych dynamicznych (wywołanych przez prąd) i statycznych (wywołanych przez magnes).
• Rozdzielczość musi być równa lub większa niż 0,6 µT, a zalecana rozdzielczość powinna być równa lub większa niż 0,2 µT.
• POWINIEN być kompensowany temperaturowo.
• MUSI obsługiwać kalibrację online i kompensację błędów na poziomie sprzętu oraz zachowywać parametry kompensacji po ponownym uruchomieniu urządzenia.
• NALEŻY zastosować kompensację miękkiego żelaza. Kalibrację można przeprowadzić podczas użytkowania lub podczas produkcji urządzenia.
• ODCHYLENIE STANDARDOWE obliczone na podstawie próbek zebranych w ciągu co najmniej 3 sekund z najwyższą częstotliwością próbkowania nie powinno przekraczać 0,5 µT.
• NALEŻY zaimplementować czujnik złożony TYPE_ROTATION_VECTOR, jeśli czujnik przyspieszeniomierza i czujnik żyroskopu są również uwzględnione.
• MOŻESZ zaimplementować czujnik TYPE_GEOMAGNETIC_ROTATION_VECTOR, jeśli masz też akcelerometr. Jednak jeśli jest ona stosowana, musi zużywać mniej niż 10 mW, a powinna zużywać mniej niż 3 mW, gdy czujnik jest zarejestrowany w trybie zbiorczym z częstotliwością 10 Hz.

7.3.3. GPS

Implementacje urządzeń powinny zawierać odbiornik GPS/GNSS. Jeśli implementacja urządzenia zawiera odbiornik GPS/GNSS i zgłasza tę funkcję aplikacjom za pomocą flagi funkcji android.hardware.location.gps:

• MOCNO zalecamy, aby podczas połączenia alarmowego urządzenie nadal dostarczało aplikacjom normalne dane GPS/GNSS i aby dane o lokalizacji nie były blokowane podczas połączenia alarmowego.
• Musi obsługiwać dane wyjściowe lokalizacji z częstotliwością co najmniej 1 Hz, gdy zostanie o to poproszony za pomocą interfejsu LocationManager#requestLocationUpdate .
• Urządzenie MUSI być w stanie określić lokalizację w warunkach otwartego nieba (silne sygnały, pomijalny efekt wielościeżkowy, HDOP < 2) w ciągu 10 sekund (szybki czas do pierwszego wyznaczenia pozycji) po połączeniu z internetem o szybkości co najmniej 0,5 Mb/s. Wymaganie to jest zwykle realizowane przez użycie jakiejś formy wspomaganego lub przewidywanego GPS-u/GNSS w celu zminimalizowania czasu ustalania pozycji przez GPS-a/GNSS (dane wspomagania obejmują czas odniesienia, lokalizację odniesienia i ephemeridy satelity/zegar).
  • Po obliczeniu lokalizacji zalecamy, aby urządzenie mogło określić swoją lokalizację na otwartej przestrzeni w ciągu 10 sekund od ponownego rozpoczęcia żądań lokalizacji, nawet jeśli kolejne żądanie zostanie wysłane bez połączenia z internetem lub po wyłączeniu i ponownie włączeniu urządzenia.
• W warunkach otwartego nieba po określeniu lokalizacji, w stanie nieruchomym lub w ruchu z przyspieszeniem mniejszym niż 1 m/s²:
  • W co najmniej 95% czasu musi być w stanie określić lokalizację z dokładnością do 20 metrów i prędkość z dokładnością do 0,5 metra na sekundę.
  • Musi jednocześnie śledzić i przekazywać informacje o co najmniej 8 satelitach z jednej konstelacji za pomocą funkcji GnssStatus.Callback.
  • Urządzenie POWINNA być w stanie śledzić jednocześnie co najmniej 24 satelity z różnych konstelacji (np. GPS + co najmniej 1 z Glonas, BeiDou, Galileo).
• Musisz podać generację technologii GNSS za pomocą testowego interfejsu API „getGnssYearOfHardware”.
• BARDZO ZALECAMY spełnienie wszystkich wymagań wymienionych poniżej, jeśli generacja technologii GNSS jest raportowana jako „2016” lub nowsza.
  • Musi raportować pomiary GPS, gdy tylko je znajdzie, nawet jeśli lokalizacja obliczona na podstawie GPS/GNSS nie została jeszcze zgłoszona.
  • Musi raportować pseudozakresy i pseudozakresy GPS, które w warunkach otwartego nieba po określeniu lokalizacji, w stanie spoczynku lub w ruchu z przyspieszeniem poniżej 0,2 metra na sekundę kwadratową, wystarczają do obliczenia pozycji z dokładnością do 20 metrów i prędkości z dokładnością do 0,2 metra na sekundę w co najmniej 95% czasu.

Pamiętaj, że chociaż niektóre z wymienionych powyżej wymagań dotyczących GPS-a są opisane jako „Zalecane”, w definicji zgodności w przyszłej głównej wersji wymagania te zostaną zmienione na „Wymagane”.

7.3.4. Żyroskop

Implementacje na urządzeniach POWINNY zawierać żyroskop (czujnik zmiany kątowej). Urządzenia NIE powinny mieć czujnika żyroskopu, chyba że mają też akcelerometr 3-osiowy. Jeśli implementacja urządzenia zawiera żyroskop:

• Musisz zaimplementować czujnik TYPE_GYROSCOPE i powinieneś zaimplementować też czujnik TYPE_GYROSCOPE_UNCALIBRATED. W przypadku istniejących i nowych urządzeń z Androidem MOCNO zalecamy implementację czujnika SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
• MUSI być w stanie mierzyć zmiany orientacji do 1000 stopni na sekundę.
• W przypadku zegarków z Androidem aplikacja MUSI mieć możliwość raportowania zdarzeń z częstotliwością co najmniej 50 Hz, ponieważ takie urządzenia mają bardziej rygorystyczne ograniczenia dotyczące zużycia energii. W przypadku wszystkich innych typów urządzeń częstotliwość ta powinna wynosić 100 Hz.
• Powinny raportować zdarzenia z częstotliwością co najmniej 200 Hz.
• Musi mieć rozdzielczość co najmniej 12 bitów, a najlepiej 16 bitów.
• MUSI być wyposażony w kompensację temperatury.
• MUSI być skalibrowany i skompensowany podczas użytkowania oraz zachowywać parametry kompensacji po ponownym uruchomieniu urządzenia.
• Musi mieć odchylenie standardowe nie większe niż 1e-7 rad^2 / s^2 na Hz (odchylenie standardowe na Hz lub rad^2 / s). Odchylenie może się zmieniać wraz z częstotliwością próbkowania, ale musi być ograniczone do tej wartości. Inaczej mówiąc, jeśli zmierzymy odchylenie standardowe żyroskopu przy częstotliwości próbkowania 1 Hz, nie powinno ono przekraczać 1 e-7 rad^2/s^2.
• NALEŻY zaimplementować czujnik złożony TYPE_ROTATION_VECTOR, jeśli czujnik przyspieszeniomierza i czujnik magnetometru są również uwzględnione.
• Jeśli uwzględniono czujnik akcelerometru, MUSISZ zaimplementować czujniki złożone TYPE_GRAVITY i TYPE_LINEAR_ACCELERATION oraz POWINIEN implementować czujnik złożony TYPE_GAME_ROTATION_VECTOR. Zalecamy implementację czujnika TYPE_GAME_ROTATION_VECTOR na istniejących i nowych urządzeniach z Androidem.

7.3.5. barometr;

Implementacje urządzenia POWINNY zawierać barometr (czujnik ciśnienia powietrza otoczenia). Jeśli implementacja urządzenia zawiera barometr, musi:

• NALEŻY wdrożyć i zgłaszać czujnik TYPE_PRESSURE.
• MUSI być w stanie przesyłać zdarzenia z częstotliwością co najmniej 5 Hz.
• Musi mieć odpowiednią dokładność, aby umożliwić oszacowanie wysokości.
• MUSI być wyposażony w kompensację temperatury.

7.3.6. Termometr

Implementacje urządzenia MOGĄ zawierać termometr otoczenia (czujnik temperatury). Jeśli jest obecny, musi być zdefiniowany jako SENSOR_TYPE_AMBIENT_TEMPERATURE i musi mierzyć temperaturę otoczenia (w pomieszczeniu) w stopniach Celsjusza.

Implementacje urządzeń MOGĄ, ale NIE POWINNY zawierać czujnika temperatury procesora. Jeśli jest obecny, MUSI być zdefiniowany jako SENSOR_TYPE_TEMPERATURE, MUSI mierzyć temperaturę procesora urządzenia i NIE MOŻE mierzyć żadnej innej temperatury. Pamiętaj, że typ czujnika SENSOR_TYPE_TEMPERATURE został wycofany w Androidzie 4.0.

7.3.7. Fotometr

Implementacje urządzeń MOGĄ zawierać fotometr (czujnik jasności otoczenia).

7.3.8. Czujnik zbliżeniowy

Urządzenia mogą być wyposażone w czujnik zbliżeniowy. Urządzenia, które mogą nawiązywać połączenia głosowe i zwracać dowolną wartość inną niż PHONE_TYPE_NONE w getPhoneType, powinny mieć czujnik zbliżeniowy. Jeśli implementacja urządzenia obejmuje czujnik zbliżeniowy, musi:

• MUSI mierzyć odległość obiektu w tym samym kierunku co ekran. Oznacza to, że czujnik zbliżeniowy MUSI być zorientowany tak, aby wykrywać obiekty w pobliżu ekranu, ponieważ głównym celem tego typu czujnika jest wykrywanie telefonu używanego przez użytkownika. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy o dowolnej innej orientacji, NIE MOŻE być on dostępny za pomocą tego interfejsu API.
• Musi mieć co najmniej 1 bita dokładności.

7.3.9. Czujniki o wysokiej wierności

Implementacje urządzeń obsługujące zestaw czujników o wyższej jakości, które mogą spełniać wszystkie wymagania wymienione w tej sekcji, MUSZĄ wskazywać obsługę za pomocą flagi funkcji android.hardware.sensor.hifi_sensors.

Urządzenie deklarujące android.hardware.sensor.hifi_sensors MUSI obsługiwać wszystkie te typy czujników, które spełniają wymagania dotyczące jakości:

• SENSOR_TYPE_ACCELEROMETER
  • Zakres pomiarowy musi wynosić co najmniej -8 g do +8 g.
  • Rozdzielczość pomiaru MUSI wynosić co najmniej 1024 LSB/G.
  • Częstotliwość pomiaru musi wynosić co najmniej 12,5 Hz.
  • Musi mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz.
  • Szum pomiarowy nie może przekraczać 400 µG/√Hz.
  • MUSI implementować niebudzącą formę tego czujnika z możliwością buforowania co najmniej 3000 zdarzeń czujnika.
  • Musisz mieć ustawienie batchingu z poziomem poboru mocy nie większym niż 3 mW.
  • Powinny mieć stałą stabilność błędu wynikającego z szumów na poziomie poniżej 15 μg √Hz na podstawie 24-godzinnego statycznego zbioru danych.
  • Zmiana polaryzacji w zależności od temperatury powinna wynosić ≤ +/- 1 mg / °C.
  • USTAWIĆ nieliniowości linii dopasowania najlepszego do danych na poziomie ≤ 0,5% oraz zmianę czułości w zależności od temperatury na poziomie ≤ 0,03%/°C.

• SENSOR_TYPE_GYROSCOPE

  • Zakres pomiarowy musi wynosić co najmniej -1000 do +1000 dps.
  • Rozdzielczość pomiaru MUSI wynosić co najmniej 16 LSB/dps.
  • Częstotliwość pomiaru musi wynosić co najmniej 12,5 Hz.
  • Musi mieć maksymalną częstotliwość pomiaru wynoszącą co najmniej 400 Hz.
  • Szum pomiarowy nie może być większy niż 0,014°/s/√Hz.
  • Powinien on być stabilny w stosunku do stałego przesunięcia o mniej niż 0,0002°/s √Hz na podstawie 24-godzinnego statycznego zbioru danych.
  • Zmiana przesunięcia w zależności od temperatury powinna wynosić ≤ ± 0,05°/s/°C.
  • Zmiana czułości w zależności od temperatury powinna wynosić ≤ 0,02% / °C.
  • Współczynnik nieliniowości linii najlepszego dopasowania powinien być mniejszy niż 0,2%.
  • gęstość szumów powinna wynosić ≤ 0,007 °/s/√Hz;

• SENSOR_TYPE_GYROSCOPE_UNCALIBRATED z tymi samymi wymaganiami dotyczącymi jakości co SENSOR_TYPE_GYROSCOPE.

• SENSOR_TYPE_GEOMAGNETIC_FIELD
  • Zakres pomiarowy musi wynosić co najmniej -900 do +900 uT.
  • Rozdzielczość pomiaru musi wynosić co najmniej 5 LSB/uT.
  • Częstotliwość pomiaru MUSI wynosić co najmniej 5 Hz.
  • Maksymalna częstotliwość pomiaru musi wynosić co najmniej 50 Hz.
  • Szum pomiarowy nie może przekraczać 0,5 uT.
• SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED z tymi samymi wymaganiami dotyczącymi jakości co SENSOR_TYPE_GEOMAGNETIC_FIELD, a dodatkowo:
  • MUSI implementować niebudzącą formę tego czujnika z możliwością buforowania co najmniej 600 zdarzeń czujnika.
• SENSOR_TYPE_PRESSURE
  • Zakres pomiarowy musi wynosić co najmniej 300–1100 hPa.
  • Musi mieć rozdzielczość pomiaru co najmniej 80 LSB/hPa.
  • Częstotliwość pomiaru MUSI wynosić co najmniej 1 Hz.
  • Maksymalna częstotliwość pomiaru musi wynosić co najmniej 10 Hz.
  • Szum pomiarowy nie może przekraczać 2 Pa/√Hz.
  • NALEŻY wdrożyć niebudzącą formę tego czujnika z możliwością buforowania co najmniej 300 zdarzeń czujnika.
  • Musisz mieć ustawienie poboru mocy w ramach przetwarzania w partiach nie większe niż 2 mW.
• SENSOR_TYPE_GAME_ROTATION_VECTOR
  • NALEŻY wdrożyć niebudzącą formę tego czujnika z możliwością buforowania co najmniej 300 zdarzeń czujnika.
  • Musi mieć zużycie energii na etapie grupowania nie większe niż 4 mW.
• SENSOR_TYPE_SIGNIFICANT_MOTION
  • MUSI mieć zużycie energii nie większe niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
• SENSOR_TYPE_STEP_DETECTOR
  • NALEŻY wdrożyć tę funkcję w formie niewybudzającej z możliwością buforowania co najmniej 100 zdarzeń czujnika.
  • MUSI mieć zużycie energii nie większe niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
  • Musi mieć zużycie energii na etapie grupowania nie większe niż 4 mW.
• SENSOR_TYPE_STEP_COUNTER
  • MUSI mieć zużycie energii nie większe niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.
• SENSOR_TILT_DETECTOR
  • MUSI mieć zużycie energii nie większe niż 0,5 mW w stanie spoczynku i 1,5 mW w ruchu.

Takie urządzenie musi też spełniać te wymagania dotyczące podsystemu czujników:

• Sygnatury czasowe tego samego zdarzenia fizycznego zarejestrowane przez akcelerometr, czujnik żyroskopu i magnetometr MUSZĄ być oddalone od siebie o nie więcej niż 2,5 milisekundy.
• Sygnatury czasowe zdarzeń czujnika żyroskopu MUSZĄ być oparte na tej samej podstawie czasowej co podsystem kamery i mieć błąd nieprzekraczający 1 milisekundy.
• Czujniki o wysokiej wierności MUSZĄ przesyłać próbki do aplikacji w ciągu 5 milisekund od momentu, gdy dane są dostępne w czujniku fizycznym, do aplikacji.
• Zużycie energii NIE MOŻE być wyższe niż 0,5 mW, gdy urządzenie jest nieruchome, i 2,0 mW, gdy urządzenie się porusza, przy włączonej dowolnej kombinacji tych czujników:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

Pamiętaj, że wszystkie wymagania dotyczące zużycia energii w tej sekcji nie obejmują zużycia energii przez procesor aplikacji. Obejmuje to moc pobieraną przez cały łańcuch czujników: czujnik, wszelkie układy pomocnicze, dedykowany system przetwarzania czujników itp.

W implementacji urządzenia deklarującej interfejs android.hardware.sensor.hifi_sensors MOŻNA również obsługiwać te typy czujników, ale jeśli są one obecne, MUSZĄ spełniać te minimalne wymagania dotyczące możliwości buforowania:

• SENSOR_TYPE_PROXIMITY: 100 zdarzeń czujnika

7.3.10. Czytnik linii papilarnych

Urządzenia z bezpieczną blokadą ekranu POWINNY zawierać czytnik linii papilarnych. Jeśli implementacja urządzenia zawiera czytnik linii papilarnych i odpowiednią usługę API dla deweloperów zewnętrznych, musi:

• MUSI deklarować obsługę funkcji android.hardware.fingerprint.
• Odpowiednią usługę API należy w pełni zaimplementować zgodnie z opisem w dokumentacji pakietu Android SDK.
• Wskaźnik fałszywych akceptacji NIE MOŻE być wyższy niż 0,002%.
• ZALECAMY, aby odsetek błędów odrzucenia na podstawie pomiarów na urządzeniu był mniejszy niż 10%.
• W przypadku jednego zarejestrowanego palca zalecamy, aby opóźnienie było krótsze niż 1 s (mierzone od momentu dotknięcia czytnika linii papilarnych do momentu odblokowania ekranu).
• W przypadku weryfikacji odcisków palców po 5 nieudanych próbach należy ZAWSZE ograniczyć liczbę prób do co najmniej 30 sekund.
• Musisz mieć implementację magazynu kluczy opartą na sprzęcie i wykonywać dopasowywanie odcisków palców w zaufanym środowisku wykonawczym (TEE) lub na chipie z bezpiecznym kanałem do TEE.
• Wszystkie dane identyfikacyjne odcisku palca muszą być zaszyfrowane i uwierzytelnione kryptograficznie, tak aby nie można było ich pozyskać, odczytać ani zmienić poza bezpiecznym środowiskiem wykonawczym (TEE), zgodnie z opisem w wytycznych dotyczących implementacji na stronie projektu Android Open Source.
• Musisz uniemożliwić dodanie odcisku palca bez uprzedniego ustanowienia łańcucha zaufania, prosząc użytkownika o potwierdzenie istniejącego lub dodanie nowego elementu danych logowania urządzenia (kodu PIN, wzoru lub hasła) chronionego przez TEE. W ramach implementacji projektu Android Open Source udostępniono mechanizm umożliwiający wykonanie tej czynności.
• NIE WOLNO zezwalać aplikacjom innych firm na rozróżnianie poszczególnych odcisków palców.
• MUSI honorować flagę DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• W przypadku uaktualnienia z wersji starszej niż Android 6.0 należy bezpiecznie przenieść dane odcisków palców, aby spełniały powyższe wymagania, lub je usunąć.
• NALEŻY użyć ikony odcisku palca Androida udostępnionej w projekcie Android Open Source.

7.3.11. Czujniki dostępne tylko w Androidzie Automotive

Czujniki związane z motoryzacją są definiowane w pliku android.car.CarSensorManager API .

7.3.11.1. Aktualny sprzęt

W implementacjach Androida Automotive NALEŻY podać bieżący bieg jako SENSOR_TYPE_GEAR.

7.3.11.2. Tryb dzienny/nocny

Implementacje Androida Automotive MUSZĄ obsługiwać tryb dzień/noc zdefiniowany jako SENSOR_TYPE_NIGHT. Wartość tego parametru MUSI być zgodna z trybem dziennym/nocnym w panelu, a także POWINNA być oparta na danych z czujnika światła otoczenia. Podrzędny czujnik jasności otoczenia MOŻE być taki sam jak fotometr .

7.3.11.3. Stan jazdy

Implementacje Androida Automotive MUSZĄ obsługiwać stan jazdy zdefiniowany jako SENSOR_TYPE_DRIVING_STATUS, z wartością domyślną DRIVE_STATUS_UNRESTRICTED, gdy pojazd jest całkowicie zatrzymany i zaparkowany. Konfigurowanie parametru SENSOR_TYPE_DRIVING_STATUS zgodnie ze wszystkimi przepisami i zasadami obowiązującymi na rynkach, na których sprzedawany jest produkt, jest obowiązkiem producentów urządzeń.

7.3.11.4. Prędkość koła

Implementacje Androida Automotive MUSZĄ podawać prędkość pojazdu zdefiniowaną jako SENSOR_TYPE_CAR_SPEED.

7.3.12. Czujnik postawy

Implementacje urządzeń MOGĄ obsługiwać czujnik postawy z 6 stopniami swobody. Zaleca się, aby urządzenia przenośne z Androidem obsługiwały ten czujnik. Jeśli implementacja urządzenia obsługuje czujnik postawy z 6 stopniami swobody, to:

• NALEŻY wdrożyć i zgłosić czujnik TYPE_POSE_6DOF.
• MUSI być dokładniejszy niż sam wektor rotacji.

7.4. Łączność z danymi

7.4.1. Połączenia telefoniczne

Termin „telefonia” używany w interfejsach API Androida i w tym dokumencie odnosi się konkretnie do sprzętu związanego z nawiązywaniem połączeń głosowych i wysyłaniem SMS-ów za pomocą sieci GSM lub CDMA. Podczas gdy te połączenia głosowe mogą być przełączane pakietowo, w przypadku Androida są one traktowane niezależnie od połączeń danych, które mogą być stosowane w ramach tej samej sieci. Innymi słowy, funkcje i interfejsy API „telefonii” w Androidzie odnoszą się wyłącznie do połączeń głosowych i SMS-ów. Na przykład implementacje urządzeń, które nie mogą nawiązywać połączeń ani wysyłać/odbierać SMS-ów, NIE MOGĄ zgłaszać funkcji android.hardware.telephony ani żadnych podfunkcji, niezależnie od tego, czy do przesyłania danych używają sieci komórkowej.

Android MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego. Oznacza to, że Android jest zgodny z urządzeniami, które nie są telefonami. Jeśli jednak implementacja urządzenia obejmuje telefonię GSM lub CDMA, MUSI ona w pełni obsługiwać interfejs API tej technologii. W przypadku implementacji na urządzeniach, które nie zawierają sprzętu telefonicznego, należy wdrożyć pełne interfejsy API jako niewykonujące żadnych operacji.

7.4.1.1. Zgodność z blokowaniem numeru

Implementacje urządzeń z Androidem Telephony MUSZĄ obsługiwać blokowanie numerów i zawierać:

• NALEŻY w pełni zaimplementować interfejs BlockedNumberContract i odpowiednią usługę API zgodnie z opisem w dokumentacji pakietu SDK.
• MUSI blokować wszystkie połączenia i wiadomości z numeru telefonu w ramach usługi BlockedNumberProvider bez żadnej interakcji z aplikacjami. Jedynym wyjątkiem jest tymczasowe odblokowanie blokady numeru zgodnie z opisem w dokumentacji pakietu SDK.
• W przypadku zablokowanego połączenia NIE MOŻESZ zapisywać danych w rejestratorze połączeń platformy.
• NIE MOŻESZ napisać do dostawcy usług telefonicznych w sprawie zablokowanej wiadomości.
• NALEŻY wdrożyć interfejs zarządzania zablokowanymi numerami, który otwiera się za pomocą intencji zwracanej przez metodę TelecomManager.createManageBlockedNumbersIntent().
• Nie wolno zezwalać użytkownikom dodatkowym na wyświetlanie ani edytowanie zablokowanych numerów na urządzeniu, ponieważ platforma Android zakłada, że użytkownik główny ma pełną kontrolę nad usługami telefonicznymi, w jednym wystąpieniu na urządzeniu. Wszystkie elementy interfejsu związane z blokowaniem MUSZĄ być ukryte dla użytkowników dodatkowych, a lista zablokowanych użytkowników MUSI być nadal uwzględniana.
• Blokowane numery NALEŻY przenieść do dostawcy, gdy urządzenie zostanie zaktualizowane do Androida 7.0.

7.4.2. IEEE 802.11 (Wi-Fi)

Wszystkie implementacje urządzeń z Androidem POWINNA obejmować obsługę co najmniej jednej formy 802.11. Jeśli implementacja urządzenia obejmuje obsługę 802.11 i udostępnia tę funkcję aplikacji innej firmy, MUSI ona zaimplementować odpowiedni interfejs API Androida i:

• MUSI zawierać flagę funkcji sprzętowej android.hardware.wifi.
• Interfejs multicast API MUSI być zaimplementowany zgodnie z opisem w dokumentacji pakietu SDK.
• MUSI obsługiwać multicast DNS (mDNS) i NIE MOŻE filtrować pakietów mDNS (224.0.0.251) w żadnym momencie działania, w tym:
  • nawet wtedy, gdy ekran nie jest aktywny.
  • W przypadku implementacji urządzeń z Androidem TV nawet w stanie gotowości.

7.4.2.1. Wi-Fi Direct

Implementacje urządzeń powinny obsługiwać Wi-Fi Direct (Wi-Fi peer-to-peer). Jeśli implementacja urządzenia obejmuje obsługę Wi-Fi Direct, MUSI ona implementować odpowiednie interfejsy API Androida zgodnie z opisem w dokumentacji pakietu SDK. Jeśli implementacja urządzenia obejmuje obsługę Wi-Fi Direct, urządzenie:

• MUSI raportować funkcję sprzętową android.hardware.wifi.direct.
• MUSI obsługiwać zwykłe połączenia Wi-Fi.
• NALEŻY obsługiwać jednoczesne działanie Wi-Fi i Wi-Fi Direct.

7.4.2.2. Konfiguracja połączenia bezpośredniego z tunelowaniem Wi-Fi

Implementacje urządzeń powinny obejmować obsługę konfiguracji tunelu bezpośredniego Wi-Fi (TDLS) zgodnie z opisem w dokumentacji pakietu Android SDK. Jeśli implementacja urządzenia obejmuje obsługę TDLS, a TDLS jest włączone przez interfejs API WiFiManager, urządzenie:

• NALEŻY używać TDLS tylko wtedy, gdy jest to możliwe i korzystne.
• Powinien zawierać heurystyki i NIE używać TDLS, gdy jego wydajność może być gorsza niż w przypadku korzystania z punktu dostępu Wi-Fi.

7.4.3. Bluetooth

Implementacje urządzeń obsługujące funkcję android.hardware.vr.high_performance MUSZĄ obsługiwać rozszerzenie długości danych Bluetooth 4.2 i Bluetooth LE.

Android obsługuje Bluetooth i Bluetooth Low Energy . Implementacje urządzeń, które obejmują obsługę Bluetooth i Bluetooth Low Energy, MUSZĄ zadeklarować odpowiednie funkcje platformy (odpowiednio android.hardware.bluetooth i android.hardware.bluetooth_le) oraz zaimplementować interfejsy API platformy. Implementacje urządzeń POWINNY implementować odpowiednie profile Bluetooth, takie jak A2DP, AVCP, OBEX itp., w sposób odpowiedni dla danego urządzenia.

Implementacje Androida Automotive POWINNY obsługiwać profil dostępu do wiadomości (MAP). Implementacje Androida Automotive MUSZĄ obsługiwać te profile Bluetooth:

• Połączenia telefoniczne przez profil zestawu głośnomówiącego (HFP).
• Odtwarzanie multimediów za pomocą profilu dystrybucji audio (A2DP).
• sterowanie odtwarzaniem multimediów za pomocą profilu zdalnego sterowania (AVRCP);
• Udostępnianie kontaktów za pomocą profilu dostępu do książki telefonicznej (PBAP).

Implementacje urządzeń z obsługą Bluetooth Low Energy:

• NALEŻY zadeklarować funkcję sprzętową android.hardware.bluetooth_le.
• NALEŻY włączyć interfejsy API Bluetooth oparte na GATT (profil ogólny atrybutów) zgodnie z opisem w dokumentacji pakietu SDK i android.bluetooth .
• MOCNO zalecamy wdrożenie limitu czasu adresu prywatnego, który można rozwiązać (RPA), nie dłuższego niż 15 minut, oraz rotację adresu po upływie tego czasu, aby chronić prywatność użytkowników.
• Aplikacja MUSI obsługiwać przenoszenie logiki filtrowania na chipset Bluetooth podczas implementowania interfejsu API ScanFilter. W przypadku zapytania przesłanego za pomocą metody android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() musi raportować prawidłową wartość miejsca , w którym zaimplementowano logikę filtrowania.
• Metoda powinna obsługiwać przenoszenie skanowania zbiorczego na procesor Bluetooth, ale jeśli nie jest to możliwe, MUSI zwracać wartość „false” (fałsz) w przypadku zapytania za pomocą metody android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported().
• Powinien obsługiwać wiele reklam z co najmniej 4 miejscami, ale jeśli nie obsługuje, MUSI zwracać „false” w przypadku zapytania za pomocą metody android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported().

7.4.4. Komunikacja Near Field Communication

Urządzenia powinny zawierać transceiver i powiązany sprzęt do komunikacji Near Field Communication (NFC). Jeśli implementacja urządzenia obejmuje sprzęt NFC i planuje udostępnienie go aplikacjom innych firm, musi:

• Musisz zgłosić funkcję android.hardware.nfc za pomocą metody android.content.pm.PackageManager.hasSystemFeature() .
• MUSI być w stanie odczytywać i zapisywać komunikaty NDEF za pomocą tych standardów NFC:
  • MUSI być w stanie działać jako czytnik/nagrywarka NFC Forum (zgodnie ze specyfikacją techniczną NFC Forum NFCForum-TS-DigitalProtocol-1.0) za pomocą tych standardów NFC:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • Typy tagów NFC Forum 1, 2, 3 i 4 (zdefiniowane przez NFC Forum)
  • ZDECYDOWANIE POLECAMY, aby aplikacja była w stanie odczytywać i zapisywać wiadomości NDEF oraz dane w postaci binarnej za pomocą tych standardów NFC. Pamiętaj, że chociaż poniższe standardy NFC są opisane jako „MOCNO ZALECANE”, w przyszłej wersji definicji zgodności mają być wymagane. Te standardy są opcjonalne w tej wersji, ale będą wymagane w przyszłych wersjach. Zachęcamy, aby i obecne, i nowe urządzenia z tą wersją Androida spełniały te wymagania, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.
    • NfcV (ISO 15693)
  • POWINIEN odczytywać kody kreskowe i adresy URL (jeśli są zakodowane) produktów z kodami kreskowymi Thinfilm NFC.
  • MUSI umożliwiać przesyłanie i odbieranie danych za pomocą tych standardów i protokołów peer-to-peer:
    • ISO 18092
    • LLCP 1.2 (zdefiniowany przez NFC Forum)
    • SDP 1.0 (zdefiniowana przez NFC Forum)
    • Protokół NDEF Push
    • SNEP 1.0 (zdefiniowany przez NFC Forum)
  • MUSI zawierać obsługę Android Beam .
  • MUSI implementować serwer domyślny SNEP. Prawidłowe komunikaty NDEF otrzymane przez domyślny serwer SNEP MUSZĄ zostać wysłane do aplikacji za pomocą intencji android.nfc.ACTION_NDEF_DISCOVERED. Wyłączenie funkcji Android Beam w ustawieniach NIE MOŻE spowodować wyłączenia wysyłania przychodzących wiadomości NDEF.
  • MUSI obsługiwać intent android.settings.NFCSHARING_SETTINGS, aby wyświetlić ustawienia udostępniania NFC .
  • MUSI implementować serwer NPP. Wiadomości odbierane przez serwer NPP MUSZĄ być przetwarzane w taki sam sposób jak przez serwer domyślny SNEP.
  • W przypadku włączonego Android Beam MUSI zaimplementować klienta SNEP i spróbować wysłać wychodzące NDEF P2P na domyślny serwer SNEP. Jeśli nie zostanie znaleziony domyślny serwer SNEP, klient MUSI spróbować wysłać wiadomość na serwer NPP.
  • Musisz zezwolić aktywnościom na pierwszym planie na ustawianie wychodzących wiadomości P2P NDEF za pomocą android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback i android.nfc.NfcAdapter.enableForegroundNdefPush.
  • NALEŻY użyć gestu lub potwierdzenia na ekranie (np. „Dotknij, aby przesłać”) przed wysłaniem wychodzących wiadomości P2P NDEF.
  • NALEŻY włączyć Android Beam domyślnie i MUSI być możliwe wysyłanie i odbieranie za pomocą Android Beam, nawet gdy włączony jest inny zastrzeżony tryb NFC P2P.
  • MUSI obsługiwać przekazywanie połączenia NFC do Bluetooth, gdy urządzenie obsługuje profil przesyłania obiektów Bluetooth. Implementacje urządzeń MUSZĄ obsługiwać przekazywanie połączenia do Bluetooth podczas używania android.nfc.NfcAdapter.setBeamPushUris, poprzez implementację specyfikacji „Connection Handover version 1.2” i „Bluetooth Secure Simple Pairing Using NFC version 1.0” z Forum NFC. Takie wdrożenie MUSI implementować usługę LLCP z nazwą „urn:nfc:sn:handover” do wymiany żądania przekazania/rekordów wyboru przez NFC i MUSI używać profilu Bluetooth Object Push do faktycznego przesyłania danych przez Bluetooth. Ze względów historycznych (aby zachować zgodność z urządzeniami z Androidem 4.1) implementacja powinna nadal akceptować żądania SNEP GET w celu wymiany żądania przekazania lub wybranych rekordów za pomocą NFC. Jednak sama implementacja NIE POWINNA wysyłać żądań SNEP GET w celu przejęcia połączenia.
  • W trybie wykrywania NFC MUSI sprawdzać wszystkie obsługiwane technologie.
  • NALEŻY ustawić tryb wykrywania NFC, gdy urządzenie jest aktywne, ekran jest włączony, a ekran blokady odblokowany.

(pamiętaj, że publicznie dostępne linki nie są dostępne w przypadku wymienionych powyżej specyfikacji JIS, ISO i NFC Forum).

Android obsługuje tryb hosta karty NFC (HCE). Jeśli implementacja urządzenia zawiera chipset kontrolera NFC obsługujący HCE (dla NfcA lub NfcB) i obsługuje routing identyfikatora aplikacji (AID), to:

• Musisz podać stałą funkcję android.hardware.nfc.hce.
• MUSI obsługiwać interfejsy API NFC HCE zgodnie z definicją w pakiecie Android SDK.

Jeśli implementacja urządzenia obejmuje chipset kontrolera NFC obsługujący HCE dla NfcF i implementuje tę funkcję w przypadku aplikacji innych firm, to:

• MUSI raportować stałą funkcję android.hardware.nfc.hcef.
• Musisz zaimplementować interfejsy API do emulacji karty NfcF zgodnie z definicją w pakiecie SDK Androida.

Dodatkowo implementacje urządzeń MOGĄ zawierać obsługę czytnika/nagrywarki dla tych technologii MIFARE:

• MIFARE Classic
• MIFARE Ultralight
• NDEF na kartach MIFARE Classic

Pamiętaj, że Android zawiera interfejsy API dla tych typów MIFARE. Jeśli implementacja urządzenia obsługuje MIFARE w roli czytnika/nagrywarki, to:

• Musisz zaimplementować odpowiednie interfejsy API Androida zgodnie z dokumentacją pakietu Android SDK.
• NALEŻY zgłaszać funkcję com.nxp.mifare z metody android.content.pm.PackageManager.hasSystemFeature(). Pamiętaj, że nie jest to standardowa funkcja Androida i nie jest widoczna jako stała w klasie android.content.pm.PackageManager.
• NIE WOLNO implementować odpowiednich interfejsów API Androida ani zgłaszać funkcji com.nxp.mifare, chyba że implementuje się też ogólną obsługę NFC zgodnie z opisem w tej sekcji.

Jeśli implementacja urządzenia nie zawiera sprzętu NFC, NIE MOŻE deklarować funkcji android.hardware.nfc w ramach metody android.content.pm.PackageManager.hasSystemFeature() i MUSI zaimplementować interfejs NFC Androida jako no-op.

Klasy android.nfc.NdefMessage i android.nfc.NdefRecord reprezentują format reprezentacji danych niezależny od protokołu, dlatego implementacje na urządzeniach MUSZĄ implementować te interfejsy API, nawet jeśli nie obsługują NFC ani nie deklarują funkcji android.hardware.nfc.

7.4.5. Minimalna funkcjonalność sieci

Implementacje urządzeń MUSZĄ obejmować obsługę co najmniej jednej formy sieci danych. W szczególności implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 standard danych o przepustowości co najmniej 200 kbps. Przykłady technologii, które spełniają to wymaganie, to EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN itp.

W przypadku implementacji urządzeń, w których podstawowym połączeniem danych jest standard sieci fizycznej (np. Ethernet), NALEŻY uwzględnić obsługę co najmniej jednego popularnego standardu transmisji danych bezprzewodowej, np. 802.11 (Wi-Fi).

Urządzenia mogą wykorzystywać więcej niż 1 formę łączności danych.

Urządzenia MUSZĄ zawierać stos sieciowy IPv6 i obsługiwać komunikację IPv6 za pomocą zarządzanych interfejsów API, takich jak java.net.Socket i java.net.URLConnection , a także natywnych interfejsów API, takich jak gniazda AF_INET6. Wymagany poziom obsługi IPv6 zależy od typu sieci:

• Urządzenia obsługujące sieci Wi-Fi MUSZĄ obsługiwać służyć do pracy w sieci Wi-Fi w sposób podwójny i tylko z IPv6.
• Urządzenia obsługujące sieci Ethernet MUSZĄ obsługiwać działanie w ramach podwójnego stosu w sieci Ethernet.
• Urządzenia, które obsługują dane komórkowe, POWINNY obsługiwać IPv6 (tylko IPv6 lub stos podwójny) w przypadku danych komórkowych.
• Gdy urządzenie jest jednocześnie połączone z kilkoma sieciami (np. Wi-Fi i komórkowej transmisji danych), MUSI jednocześnie spełniać te wymagania w każdej sieci, z którą jest połączone.

IPv6 MUSI być domyślnie włączony.

Aby zapewnić taką samą niezawodność komunikacji IPv6 jak w przypadku IPv4, pakiety unicast IPv6 wysyłane na urządzenie NIE MOGĄ być odrzucane, nawet gdy ekran nie jest aktywny. Zbędne pakiety IPv6 w ramach transmisji wielodostępnej, takie jak powtarzające się identyczne reklamacje routera, MOGĄ być ograniczane pod względem szybkości w sprzęcie lub oprogramowaniu układowym, jeśli jest to konieczne ze względu na oszczędność energii. W takich przypadkach ograniczenie szybkości NIE MOŻE spowodować utraty połączenia IPv6 w żadnej sieci zgodnej z IPv6, która używa okresów ważności RA wynoszących co najmniej 180 sekund.

W trybie Doze musisz zachować połączenie IPv6.

7.4.6. Ustawienia synchronizacji

W implementacji urządzenia ustawienie głównej autosynchronizacji MUSI być domyślnie włączone, aby metoda getMasterSyncAutomatically() zwracała wartość „true”.

7.4.7. Oszczędzanie danych

W przypadku implementacji urządzeń z połączeniem z ograniczoną przepustowością MOCNO zalecamy korzystanie z trybu oszczędzania danych.

Jeśli implementacja urządzenia zapewnia tryb oszczędzania danych, to:

• MUSI obsługiwać wszystkie interfejsy API z klasy ConnectivityManager zgodnie z opisem w dokumentacji pakietu SDK.

• Musisz udostępnić w ustawieniach interfejs, który umożliwia użytkownikom dodawanie aplikacji do listy dozwolonych lub usuwanie ich z tej listy.

Jeśli implementacja urządzenia nie zapewnia trybu oszczędzania danych, urządzenie:

• W przypadku parametru ConnectivityManager.getRestrictBackgroundStatus() ZAWSZE musi zwracać wartość RESTRICT_BACKGROUND_STATUS_DISABLED.

• NIE MOŻNA nadawać ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

• Musisz mieć aktywność, która obsługuje intencję Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, ale MOŻESZ ją zaimplementować jako no-op.

7.5. Aparaty

Implementacje urządzeń powinny zawierać tylny aparat, a opcjonalnie także przedni. Tylny aparat znajduje się po przeciwnej stronie urządzenia niż wyświetlacz, czyli rejestruje obrazy po drugiej stronie urządzenia, tak jak tradycyjny aparat. Przedni aparat to aparat znajdujący się po tej samej stronie urządzenia co wyświetlacz, czyli aparat zwykle używany do robienia zdjęć użytkownikowi, na przykład w przypadku konferencji wideo i podobnych aplikacji.

Jeśli implementacja urządzenia obejmuje co najmniej 1 kamerę, aplikacja MUSI mieć możliwość jednoczesnego przydzielenia 3 bitmap RGBA_888 o rozmiarze równym rozmiarowi obrazów generowanych przez czujnik aparatu o największej rozdzielczości na urządzeniu, gdy kamera jest otwarta na potrzeby podstawowego podglądu i robienia zdjęć.

7.5.1. Tylny aparat

Implementacje urządzeń powinny zawierać tylny aparat. Jeśli implementacja urządzenia zawiera co najmniej 1 aparat skierowany do tyłu:

• MUSI zawierać flagę funkcji android.hardware.camera i android.hardware.camera.any.
• Rozdzielczość musi wynosić co najmniej 2 Mpix.
• W sterowniku aparatu powinien być ZREALIZOWANY autofokus sprzętowy lub automatyczny autofokus oprogramowania (niewidoczny dla oprogramowania aplikacji).
• MOŻE mieć sprzęt z ostrzością stałą lub EDOF (rozszerzoną głębią ostrości).
• MOŻE zawierać błysk. Jeśli aparat ma lampę błyskową, nie może ona świecić, gdy na podglądowej powierzchni aparatu zarejestrowany jest obiekt android.hardware.Camera.PreviewCallback, chyba że aplikacja wyraźnie włączyła lampę błyskową, włączając atrybuty FLASH_MODE_AUTO lub FLASH_MODE_ON obiektu Camera.Parameters. Pamiętaj, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu, ale tylko aplikacji innych firm, które korzystają z Camera.PreviewCallback.

7.5.2. Przedni aparat

Implementacje urządzeń MOGĄ zawierać przedni aparat. Jeśli implementacja urządzenia zawiera co najmniej 1 przedni aparat:

• MUSI zawierać flagę funkcji android.hardware.camera.any i android.hardware.camera.front.
• Rozdzielczość musi wynosić co najmniej VGA (640 x 480 pikseli).
• Domyślnie w interfejsie Camera API NIE MOŻNA używać przedniego aparatu. Interfejs Camera API w Androidzie obsługuje w szczególny sposób przednie aparaty. Implementacje urządzeń NIE MOGĄ konfigurować interfejsu Camera API tak, aby traktował przedni aparat jako domyślny tylny aparat, nawet jeśli jest to jedyny aparat na urządzeniu.
• MOŻE zawierać funkcje (takie jak autofokus czy lampa błyskowa) dostępne dla tylnych kamer zgodnie z opisem w sekcji 7.5.1.
• Musisz odwrócić poziomo (czyli odbić lustrzaniem) strumień danych wyświetlany przez aplikację w ramce CameraPreview:
  • Jeśli implementacja urządzenia umożliwia użytkownikowi obracanie urządzenia (np. automatycznie za pomocą akcelerometru lub ręcznie za pomocą danych wejściowych użytkownika), podgląd aparatu MUSI być lustrzany w orientacji poziomej względem bieżącej orientacji urządzenia.
  • Jeśli bieżąca aplikacja wyraźnie poprosiła o obrócenie wyświetlacza aparatu za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation(), podgląd aparatu MUSI być odbiciem lustrzanym w orientacji poziomej względem orientacji określonej przez aplikację.
  • W przeciwnym razie podgląd MUSI być odbiciem lustrzanym wzdłuż domyślnej osi poziomej urządzenia.
• Obraz wyświetlany przez postview MUSI być lustrzany w taki sam sposób jak strumień obrazu z podglądu kamery. Jeśli implementacja na urządzeniu nie obsługuje postview, ten wymóg oczywiście nie ma zastosowania.
• Nie wolno odzwierciedlać końcowego obrazu nieruchomego ani strumieni wideo z powrotem do aplikacji lub do magazynu multimediów.

7.5.3. Kamera zewnętrzna

Implementacje urządzeń MOGĄ obejmować obsługę kamery zewnętrznej, która nie zawsze musi być podłączona. Jeśli urządzenie obsługuje kamerę zewnętrzną, to:

• NALEŻY zadeklarować flagi funkcji platformy android.hardware.camera.external i android.hardware camera.any .
• MOŻE obsługiwać wiele kamer.
• Musi obsługiwać USB Video Class (UVC 1.0 lub nowszy), jeśli kamera zewnętrzna łączy się przez port USB.
• POWINIEN obsługiwać kompresję wideo, np. MJPEG, aby umożliwić przesyłanie nieskompresowanych strumieni o wysokiej jakości (czyli strumieni nieprzetworzonych lub niezależnie skompresowanych).
• MOŻE obsługiwać kodowanie wideo na podstawie kamery. Jeśli jest obsługiwane, na urządzeniu MUSI być dostępny jednoczesny strumień niekodowany lub MJPEG (w rozdzielczości QVGA lub wyższej).

7.5.4. Zachowanie interfejsu Camera API

Android zawiera 2 pakiety interfejsów API umożliwiające dostęp do aparatu. Nowszy interfejs android.hardware.camera2 API udostępnia aplikacji niższy poziom kontroli nad aparatem, w tym wydajne przepływy zdjęć seryjnych/strumieniowych bez kopiowania i kontroli na poziomie pojedynczego klatki dotyczące ekspozycji, wzmocnienia, balansu bieli, konwersji kolorów, redukcji szumów i wyostrzenia.

Starszy pakiet interfejsu API android.hardware.Camera jest oznaczony jako przestarzały w Androidzie 5.0, ale powinien być nadal dostępny, aby aplikacje korzystające z implementacji na urządzeniach z Androidem mogły nadal korzystać z tego interfejsu API. W tym celu należy zapewnić jego obsługę zgodnie z opisem w tej sekcji i w pakiecie SDK do Androida.

Implementacje urządzeń MUSZĄ implementować te zachowania w przypadku interfejsów API związanych z aparatem w przypadku wszystkich dostępnych aparatów:

• Jeśli aplikacja nigdy nie wywołała metody android.hardware.Camera.Parameters.setPreviewFormat(int), urządzenie MUSI używać android.hardware.PixelFormat.YCbCr_420_SP do danych podglądu przekazywanych do wywołań zwrotnych aplikacji.
• Jeśli aplikacja rejestruje instancję android.hardware.Camera.PreviewCallback i system wywołuje metodę onPreviewFrame(), gdy format podglądu to YCbCr_420_SP, dane w byte[] przekazane do onPreviewFrame() muszą być w dalszym ciągu w formacie kodowania NV21. Oznacza to, że NV21 MUSI być ustawiony jako domyślny.
• W przypadku interfejsu android.hardware.Camera implementacje urządzeń MUSZĄ obsługiwać format YV12 (oznaczony za pomocą stałej android.graphics.ImageFormat.YV12) w przypadku podglądów aparatu zarówno przedniego, jak i tylnego. (Sprzętowy koder wideo i kamera mogą używać dowolnego natywnego formatu pikseli, ale implementacja urządzenia MUSI obsługiwać konwersję do YV12).
• W przypadku interfejsu android.hardware.camera2 implementacje na urządzeniu muszą obsługiwać formaty android.hardware.ImageFormat.YUV_420_888 i android.hardware.ImageFormat.JPEG jako dane wyjściowe w interfejsie API android.media.ImageReader.

Implementacje na urządzeniach MUSZĄ nadal wykorzystywać pełny interfejs Camera API zawarty w dokumentacji pakietu Android SDK, niezależnie od tego, czy urządzenie ma sprzętowy autofokus lub inne funkcje. Na przykład kamery bez autofokusa MUSZĄ wywoływać wszystkie zarejestrowane instancje android.hardware.Camera.AutoFocusCallback (chociaż nie ma to zastosowania do kamer bez autofokusa). Pamiętaj, że dotyczy to również przednich aparatów. Na przykład mimo że większość przednich aparatów nie obsługuje autofokusa, wywołania interfejsu API muszą być „fałszowane” w sposób opisany powyżej.

Implementacje urządzeń MUSZĄ rozpoznawać i szanować nazwy parametrów zdefiniowane jako stałe w klasie android.hardware.Camera.Parameters, jeśli sprzęt obsługuje tę funkcję. Jeśli sprzęt urządzenia nie obsługuje danej funkcji, interfejs API musi działać zgodnie z dokumentacją. Z drugiej strony implementacje urządzeń NIE MOGĄ obsługiwać ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters() innych niż te, które są udokumentowane jako stałe w interfejsie android.hardware.Camera.Parameters. Oznacza to, że implementacje urządzeń MUSZĄ obsługiwać wszystkie standardowe parametry aparatu, jeśli sprzęt na to pozwala, i NIE MOGĄ obsługiwać niestandardowych typów parametrów aparatu. Na przykład implementacje urządzeń, które obsługują rejestrowanie obrazu za pomocą technik obrazowania o wysokim zakresie dynamicznym (HDR), MUSZĄ obsługiwać parametr aparatu Camera.SCENE_MODE_HDR.

Nie wszystkie implementacje urządzeń mogą w pełni obsługiwać wszystkie funkcje interfejsu android.hardware.camera2 API, dlatego implementacje urządzeń MUSZĄ zgłaszać odpowiedni poziom obsługi za pomocą właściwości android.info.supportedHardwareLevel zgodnie z opisem w pakiecie Android SDK i zgłaszać odpowiednie flagi funkcji platformy .

Implementacje urządzeń MUSZĄ również zadeklarować indywidualne funkcje kamery android.hardware.camera2 za pomocą właściwości android.request.availableCapabilities i zadeklarować odpowiednie flagi funkcji. Urządzenie musi zdefiniować flagę funkcji, jeśli którekolwiek z podłączonych kamer obsługuje tę funkcję.

Implementacje urządzeń MUSZĄ nadawać intencję Camera.ACTION_NEW_PICTURE za każdym razem, gdy aparat zrobi nowe zdjęcie i jego wpis zostanie dodany do magazynu multimediów.

Implementacje na urządzeniu MUSZĄ nadawać intencję Camera.ACTION_NEW_VIDEO za każdym razem, gdy kamera nagra nowy film i doda wpis z obrazem do magazynu multimediów.

7.5.5. Orientacja aparatu

Przedni i tylny aparat (jeśli są dostępne) MUSZĄ być zorientowane tak, aby dłuższy wymiar aparatu był zgodny z dłuższym wymiarem ekranu. Oznacza to, że gdy urządzenie jest trzymane w orientacji poziomej, aparaty MUSZĄ robić zdjęcia w orientacji poziomej. Dotyczy to niezależnie od naturalnej orientacji urządzenia, czyli zarówno urządzeń z główną orientacją poziomą, jak i z główną orientacją pionową.

7.6. Pamięć i miejsce na dane

7.6.1. Minimalna ilość pamięci i miejsca na dane

Pamięć dostępna dla jądra i przestrzeni użytkownika w implementacjach na urządzeniu MUSI być co najmniej równa wartościom minimalnym określonym w tabeli poniżej lub większa od nich. (Definicje rozmiaru i gęstości ekranu znajdziesz w sekcji 7.1.1).

Gęstość i rozmiar ekranu	Urządzenie 32-bitowe	Urządzenie 64-bitowe
urządzenia z Androidem Watch (ze względu na mniejsze ekrany);	416 MB	Nie dotyczy
280 dpi lub mniej na małych/normalnych ekranach mdpi lub niższym na dużych ekranach. ldpi lub niższą na bardzo dużych ekranach.	512 MB	816 MB
xhdpi lub wyższa na małych/normalnych ekranach hdpi lub wyższa na dużych ekranach. mdpi lub wyższa na bardzo dużych ekranach.	608 MB	944 MB
400 dpi lub więcej na małych/normalnych ekranach xhdpi lub wyższa na dużych ekranach tvdpi lub wyższa na bardzo dużych ekranach.	896 MB	1280 MB
560 dpi lub więcej na małych/normalnych ekranach 400 dpi lub więcej na dużych ekranach. xhdpi lub wyższa na bardzo dużych ekranach.	1344 MB	1824 MB

Wartości minimalnej pamięci MUSZĄ być dodatkiem do pamięci już przeznaczonej na komponenty sprzętowe, takie jak radio, wideo itp., które nie są kontrolowane przez jądro.

Implementacje urządzeń z mniej niż 512 MB pamięci dostępnej dla jądra i przestrzeni użytkownika, z wyjątkiem zegarka z Androidem, MUSZĄ zwracać wartość „true” dla metody ActivityManager.isLowRamDevice().

Urządzenia z Androidem TV muszą mieć co najmniej 4 GB pamięci, a inne implementacje muszą mieć co najmniej 3 GB pamięci nieulotnej dostępnej dla danych prywatnych aplikacji. Oznacza to, że na urządzeniach z Androidem TV partycja /data MUSI mieć co najmniej 4 GB, a na innych urządzeniach co najmniej 3 GB. W przypadku implementacji urządzeń z Androidem ZALECAMY, aby na potrzeby prywatnych danych aplikacji było dostępne co najmniej 4 GB pamięci nieulotnej, co umożliwi aktualizację do przyszłych wersji platformy.

Interfejsy API Androida zawierają Menedżera pobierania, którego aplikacje MOGĄ używać do pobierania plików danych. Implementacja menedżera pobierania na urządzeniu MUSI umożliwiać pobieranie pojedynczych plików o rozmiarze co najmniej 100 MB do domyślnej lokalizacji „bufora”.

7.6.2. Pamięć współdzielona aplikacji

Implementacje urządzeń MUSZĄ oferować współdzielone miejsce na dane dla aplikacji, które często nazywane jest „współdzielonym miejscem na dane zewnętrzne”.

Implementacje urządzeń MUSZĄ być skonfigurowane z pamięcią współdzieloną zamontowaną domyślnie „z fabryki”. Jeśli pamięć współdzielona nie jest zamontowana w ścieżce Linux /sdcard, urządzenie MUSI zawierać symboliczny link Linux z katalogu /sdcard do rzeczywistego punktu zamontowania.

Urządzenia mogą mieć sprzęt umożliwiający użytkownikom dostęp do wymiennych nośników danych, takich jak gniazdo kart SD. Jeśli ten slot jest używany do spełnienia wymagań dotyczących wspólnego miejsca na dane, implementacja urządzenia:

• NALEŻY wdrożyć toast lub wyskakujące okienko w interfejsie, aby ostrzec użytkownika, gdy nie ma karty SD.
• MUSI zawierać kartę SD w formacie FAT o pojemności co najmniej 1 GB LUB musi być na opakowaniu i w innych materiałach dostępnych w momencie zakupu wyraźnie zaznaczone, że karta SD musi być kupiona osobno.
• MUSI domyślnie zamontować kartę SD.

Implementacje urządzeń mogą też przydzielić pamięć wewnętrzną (nieusuwalną) jako pamięć współdzielona dla aplikacji zawartych w poprzednim projekcie Android Open Source. Implementacje urządzeń powinny używać tej konfiguracji i implementacji oprogramowania. Jeśli implementacja na urządzeniu korzysta z wewnętrznego (nieusuwalny) miejsca na dane, aby spełnić wymagania dotyczące współdzielonego miejsca na dane, a miejsce na dane MOŻE być współdzielone z danymi prywatnymi aplikacji, musi mieć rozmiar co najmniej 1 GB i być zamontowane w katalogu /sdcard (lub /sdcard MUSI być linkiem symbolicznym do fizycznej lokalizacji, jeśli jest zamontowane gdzie indziej).

Implementacje urządzeń MUSZĄ egzekwować uprawnienia android.permission.WRITE_EXTERNAL_STORAGE w pamięci współdzielonej zgodnie z dokumentacją. W przeciwnym razie pamięć współdzielona MUSI być dostępna do zapisu dla każdej aplikacji, która uzyskała to uprawnienie.

Implementacje urządzeń, które zawierają wiele ścieżek do współdzielonej pamięci (np. gniazdo karty SD i wspólna pamięć wewnętrzna), MUSZĄ zezwalać na zapisywanie na zewnętrznej pamięci tylko w przypadku wstępnie zainstalowanych i uprzywilejowanych aplikacji na Androida z uprawnieniem WRITE_EXTERNAL_STORAGE, z wyjątkiem sytuacji, gdy zapisywanie odbywa się w katalogach konkretnych pakietów lub w folderze URI zwracanym przez wywołanie intencji ACTION_OPEN_DOCUMENT_TREE.

Implementacje urządzeń powinny jednak udostępniać treści z obu ścieżek pamięci w przejrzysty sposób za pomocą usługi skanowania multimediów w Androidzie i android.provider.MediaStore.

Niezależnie od formy używanej pamięci współdzielonej, jeśli implementacja urządzenia ma port USB z obsługą trybu urządzenia peryferyjnego USB, MUSI ona zapewniać jakiś mechanizm dostępu do zawartości pamięci współdzielonej z komputera hosta. Implementacje urządzeń MOGĄ używać pamięci masowej USB, ale powinny używać protokołu Media Transfer Protocol, aby spełnić ten wymóg. Jeśli implementacja na urządzeniu obsługuje protokół Media Transfer Protocol, to:

• Powinien być zgodny z hostem MTP na Androidzie, czyli z aplikacją Android File Transfer .
• NALEŻY podać klasę urządzenia USB 0x00.
• Powinien zwracać nazwę interfejsu USB „MTP”.

7.6.3. Pamięć dostosowywana

W przypadku implementacji urządzeń ZALECAMY stosowanie przenośnego miejsca na dane, jeśli port wymiennego urządzenia do przechowywania danych znajduje się w stabilnej lokalizacji, np. w komorze baterii lub innej osłonie ochronnej.

W przypadku implementacji urządzeń, takich jak telewizor, MOŻNA umożliwić korzystanie z portów USB, ponieważ urządzenie ma być nieruchome, a nie przenośne. W przypadku innych implementacji urządzeń mobilnych MOCNO ZALECAMY implementację pamięci adoptowanej w stabilnej lokalizacji, ponieważ jej przypadkowe odłączenie może spowodować utratę lub uszkodzenie danych.

7.7. USB

Implementacje urządzeń POWINNY obsługiwać tryb urządzenia USB i tryb hosta USB.

7.7.1. Tryb urządzenia peryferyjnego USB

Jeśli implementacja urządzenia zawiera port USB obsługujący tryb peryferyjny:

• Port MUSI umożliwiać podłączenie do hosta USB z standardowym portem USB typu A lub C.
• Port powinien być w formacie micro-B, micro-AB lub USB typu C. Zalecamy, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.
• Port powinien znajdować się na dole urządzenia (w zależności od naturalnej orientacji) lub umożliwiać obrócenie ekranu w ramach oprogramowania we wszystkich aplikacjach (w tym na ekranie głównym), aby wyświetlacz był prawidłowo wyświetlany, gdy port znajduje się na dole. Zalecamy, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, aby można było uaktualnić je do przyszłych wersji platformy.
• Musi on umożliwiać hostowi USB połączonemu z urządzeniem z Androidem dostęp do zawartości wspólnego woluminu pamięci masowej za pomocą pamięci masowej USB lub protokołu Media Transfer Protocol.
• Powinien on implementować interfejs API i specyfikację Android Open Accessory (AOA) zgodnie z dokumentacją pakietu Android SDK. Jeśli jest to urządzenie przenośne z Androidem, MUSI implementować interfejs AOA API. Implementacje urządzeń zgodne ze specyfikacją AOA:
  • MUSI deklarować obsługę funkcji sprzętowej android.hardware.usb.accessory .
  • MUSI implementować klasę audio USB zgodnie z dokumentacją pakietu SDK Androida.
  • Klasa USB Mass Storage MUSI zawierać ciąg tekstowy „android” na końcu ciągu tekstowego iInterface opisu interfejsu pamięci masowej USB.
• NALEŻY wdrożyć obsługę poboru prądu 1, 5 A podczas szumowania i przesyłania danych w trybie HS zgodnie z specyfikacją ładowania akumulatora USB (wersja 1.2). Zalecamy, aby i dotychczasowe, i nowe urządzenia z Androidem spełniały te wymagania, ponieważ dzięki temu będą mogły korzystać z przyszłych wersji platformy.
• Urządzenia typu C MUSZĄ wykrywać ładowarki 1,5 A i 3,0 A zgodnie ze standardem rezystorów typu C i muszą wykrywać zmiany w reklamie.
• W przypadku urządzeń typu C, które obsługują też tryb hosta USB, MOCNO zalecamy obsługę funkcji Power Delivery do przesyłania danych i przełączania ról zasilania.
• Urządzenia z gniazdem typu C powinny obsługiwać Power Delivery do ładowania pod wysokim napięciem oraz tryby alternatywne, takie jak wyświetlacz zewnętrzny.
• Wartość iSerialNumber w standardowym opisie urządzenia USB MUSI być równa wartości android.os.Build.SERIAL.
• W przypadku urządzeń z portem typu C MOCNO zaleca się, aby nie obsługiwały one zastrzeżonych metod ładowania, które modyfikują napięcie Vbus poza domyślne poziomy lub zmieniają role odbiornika/źródła, ponieważ może to spowodować problemy z współdziałaniem z ładowarkami lub urządzeniami, które obsługują standardowe metody USB Power Delivery. Chociaż jest to „ZALECANA” opcja, w przyszłych wersjach Androida możemy wymagać, aby wszystkie urządzenia z typem C obsługiwały pełną interoperacyjność ze standardowymi ładowarkami typu C.

7.7.2. Tryb hosta USB

Jeśli implementacja urządzenia zawiera port USB obsługujący tryb hosta, to:

• NALEŻY użyć portu USB typu C, jeśli implementacja urządzenia obsługuje USB 3.1.
• MOŻE używać niestandardowego formatu portu, ale w takim przypadku MUSI być dostarczany z kablem lub kablami umożliwiającymi podłączenie do standardowego portu USB typu A lub C.
• MOŻE używać portu micro-AB USB, ale w takim przypadku DOSTARCZAJĄCY prawidłowo podłączony kabel lub kable do portu USB typu A lub C.
• ZALECAMY zaimplementowanie klasy audio USB zgodnie z dokumentacją pakietu Android SDK.
• Musisz zaimplementować interfejs API hosta USB Androida zgodnie z dokumentacją do pakietu Android SDK i zadeklarować obsługę funkcji sprzętowej android.hardware.usb.host .
• POWINNA obsługiwać ładowanie urządzenia w trybie hosta; reklamować prąd źródła co najmniej 1, 5 A zgodnie z sekcją Parametry zakończenia w [specyfikacji kabla i złącza USB typu C w wersji 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) w przypadku złączy USB typu C lub używać zakresu prądu wyjściowego portu CDP(portu doprowadzającego do ładowania) zgodnie z specyfikacją ładowania baterii USB w wersji 1.2 w przypadku złączy Micro-AB.
• Urządzenia USB typu C powinny obsługiwać DisplayPort, USB SuperSpeed i Power Delivery (w tym wymianę ról danych i zasilania).
• Urządzenia z portami typu A lub typu AB NIE MOGĄ być dostarczane z adapterem umożliwiającym konwersję z tego portu na gniazdo typu C.
• MUSI rozpoznawać wszystkie urządzenia połączone zdalnie przez protokół MTP (Media Transfer Protocol) i uzyskiwać dostęp do ich zawartości za pomocą intencji ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT i ACTION_CREATE_DOCUMENT, jeśli jest obsługiwana platforma Storage Access Framework (SAF).
• Jeśli używasz portu USB typu C i obsługujesz tryb peryferyjny, MUSISZ zaimplementować funkcję portu podwójnego zastosowania zgodnie ze specyfikacją USB typu C (sekcja 4.5.1.3.3).
• NALEŻY, jeśli funkcja Dual Role Port jest obsługiwana, zaimplementować model Try.*, który jest najbardziej odpowiedni dla danego formatu urządzenia. Na przykład urządzenie ręczne POWINNA stosować model Try.SNK.

7.8. Audio

7.8.1. mikrofon

Implementacje na urządzeniu MOGĄ pomijać mikrofon. Jeśli jednak implementacja urządzenia pomija mikrofon, NIE MOŻE ona raportować stałej android.hardware.microphone i MUSI zaimplementować interfejs API do nagrywania dźwięku co najmniej jako no-ops zgodnie z sekcją 7 . Natomiast w przypadku implementacji urządzeń z mikrofonem:

• Musisz podać stałą funkcję android.hardware.microphone.
• MUSI spełniać wymagania dotyczące nagrywania dźwięku podane w sekcji 5.4 .
• Muszą być spełnione wymagania dotyczące opóźnienia dźwięku podane w sekcji 5.6 .
• ZDECYDOWANIE POLECAMY obsługę nagrywania w przybliżeniu w ultradźwiękach zgodnie z opisem w sekcji 7.8.3 .

7.8.2. Wyjście audio

Implementacje urządzeń z głośnikiem lub z wyjściami audio/multimedialnymi dla urządzeń peryferyjnych z wyjściami audio, takich jak zestawy słuchawkowe lub głośniki zewnętrzne:

• MUSI raportować stałą funkcję android.hardware.audio.output.
• Muszą być spełnione wymagania dotyczące odtwarzania dźwięku podane w sekcji 5.5 .
• Muszą być spełnione wymagania dotyczące opóźnienia dźwięku podane w sekcji 5.6 .
• ZDECYDOWANIE POLECAMY obsługę odtwarzania z częstotliwością zbliżoną do ultradźwięków zgodnie z opisem w sekcji 7.8.3 .

Jeśli implementacja urządzenia nie zawiera głośnika ani portu wyjściowego audio, NIE MOŻE zgłaszać funkcji android.hardware.audio i musi zaimplementować interfejsy API związane z wyjściami audio jako no-ops.

Implementacja urządzenia Android Watch MOŻE, ALE NIE MUSI mieć wyjście audio, ale inne typy implementacji urządzeń z Androidem MUSZĄ mieć wyjście audio i deklarację android.hardware.audio.output.

7.8.2.1. Gniazda analogowe

Aby zapewnić zgodność z zestawami słuchawkowymi i innymi akcesoriami audio korzystającymi z gniazda słuchawek 3,5 mm w ekosystemie Androida, jeśli implementacja urządzenia zawiera co najmniej 1 port analogowy, co najmniej 1 z tych portów powinien być 4-żyłowym gniazdem słuchawek 3,5 mm. Jeśli implementacja urządzenia ma 4-przewodowe złącze jack 3,5 mm, to:

• Muszą obsługiwać odtwarzanie dźwięku w słuchawkach stereo i zestawach słuchawkowych stereo z mikrofonem oraz powinny obsługiwać nagrywanie dźwięku w zestawach słuchawkowych stereo z mikrofonem.
• MUSI obsługiwać wtyczki audio TRRS z kolejnością styków CTIA i POWINNA obsługiwać wtyczki audio z kolejnością styków OMTP.
• W przypadku implementacji urządzenia obsługującej mikrofon, musi ono obsługiwać wykrywanie mikrofonu w podłączonym akcesorium audio i przesyłać dane android.intent.action.HEADSET_PLUG z wartością dodatkową mikrofonu ustawioną na 1.
• MUSI obsługiwać wykrywanie i mapowanie na kody klawiszy dla 3 zakresów równoważnego oporu między mikrofonem a ziemią na wtyczce audio:
  • 70 Ohm lub mniej : KEYCODE_HEADSETHOOK
  • 210–290 Ohm : KEYCODE_VOLUME_UP
  • 360–680 Ohm : KEYCODE_VOLUME_DOWN
• ZDECYDOWANIE POLECAMY wykrywanie i mapowanie kodu klucza dla następującego zakresu impedancji równoważnej między przewodami mikrofonu i uziemienia w przewodzie audio:
  • 110–180 Ohm: KEYCODE_VOICE_ASSIST
• Musi wywołać ACTION_HEADSET_PLUG po włożeniu wtyczki, ale dopiero po tym, jak wszystkie styki wtyczki dotkną odpowiednich segmentów gniazda.
• MUSI być w stanie wygenerować co najmniej 150 mV ± 10% napięcia wyjściowego przy impedancji głośnika 32 Ohm.
• Napięcie polaryzacji mikrofonu MUSI mieścić się w zakresie 1,8–2,9 V.

7.8.3. Zbliżenie ultradźwiękowe

Dźwięk w zakresie ultradźwięku to pasmo 18,5–20 kHz. Implementacje urządzeń MUSZĄ prawidłowo zgłaszać obsługę funkcji dźwięku w zakresie ultradźwięków za pomocą interfejsu AudioManager.getProperty API w ten sposób:

• Jeśli PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND ma wartość „true”, źródła audio VOICE_RECOGNITION i UNPROCESSED muszą spełniać te wymagania:
  • Średnia moc wyjściowa mikrofonu w zakresie 18,5–20 kHz MUSI być niższa o nie więcej niż 15 dB od wartości w zakresie 2 kHz.
  • Stosunek sygnału do szumu mikrofonu bez ważenia w zakresie 18,5–20 kHz dla tonu 19 kHz przy -26 dBFS MUSI wynosić co najmniej 50 dB.
• Jeśli parametr PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND ma wartość „true”, średnia odpowiedź głośnika w zakresie 18,5–20 kHz MUSI być niższa o co najmniej 40 dB od odpowiedzi w zakresie 2 kHz.

7.9. Rzeczywistość wirtualna

Android zawiera interfejsy API i funkcje do tworzenia aplikacji do rzeczywistości wirtualnej (VR), w tym aplikacji do mobilnej rzeczywistości wirtualnej o wysokiej jakości. Implementacje na urządzeniach MUSZĄ prawidłowo wdrażać te interfejsy API i zachowania zgodnie z opisem w tej sekcji.

7.9.1. Tryb rzeczywistości wirtualnej

Implementacje urządzeń przenośnych z Androidem, które obsługują tryb aplikacji VR, który obsługuje renderowanie stereoskopowe powiadomień i wyłącza monokularne komponenty interfejsu systemu, gdy aplikacja VR ma skupioną uwagę użytkownika, MUSZĄ zadeklarować funkcję android.software.vr.mode. Urządzenia deklarujące tę funkcję MUSZĄ zawierać aplikację implementującą android.service.vr.VrListenerService, którą można włączyć za pomocą aplikacji VR za pomocą android.app.Activity#setVrModeEnabled .

7.9.2. Wysoka wydajność w rzeczywistości wirtualnej

Wdrożenia na urządzeniach przenośnych z Androidem MUSZĄ wskazywać obsługę wysokiej jakości rzeczywistości wirtualnej przez dłuższy czas użytkowania za pomocą flagi funkcji android.hardware.vr.high_performance i spełniać te wymagania.

• Implementacje urządzeń MUSZĄ mieć co najmniej 2 rdzenie fizyczne.
• Implementacje urządzeń MUSZĄ deklarować funkcję android.software.vr.mode.
• Implementacje urządzeń MOGĄ udostępniać procesor wyłącznie aplikacji na pierwszym planie i MOGĄ obsługiwać interfejs Process.getExclusiveCores API, aby zwracać liczby rdzeni procesora, które są używane wyłącznie przez aplikację na pierwszym planie. Jeśli obsługiwane jest wyłączne rdzeń, rdzeń NIE MOŻE zezwalać na uruchamianie na nim żadnych innych procesów w przestrzeni użytkownika (z wyjątkiem sterowników urządzeń używanych przez aplikację), ale MOŻE zezwalać na uruchamianie niektórych procesów jądra w razie potrzeby.
• Implementacje urządzeń MUSZĄ obsługiwać tryb stałej wydajności.
• Implementacje na urządzeniach MUSZĄ obsługiwać OpenGL ES 3.2.
• Implementacje urządzeń MUSZĄ obsługiwać poziom sprzętowy Vulkan 0 i POWINNY obsługiwać poziom sprzętowy Vulkan 1.
• Implementacje urządzeń MUSZĄ implementować EGL_KHR_mutable_render_buffer i EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, EGL_KHR_fence_sync i EGL_KHR_wait_sync, aby można było ich używać w trybie wspólnego bufora. Należy też udostępnić te rozszerzenia na liście dostępnych rozszerzeń EGL.
• GPU i wyświetlacz MUSZĄ być w stanie zsynchronizować dostęp do wspólnego bufora przedniego, tak aby renderowanie treści VR z wyświetlaniem naprzemiennym oczu z częstotliwością 60 FPS z dwoma kontekstami renderowania było wyświetlane bez widocznych artefaktów rozrywania obrazu.
• Implementacje na urządzeniu MUSZĄ implementować EGL_IMG_context_priority i umieszczać rozszerzenie na liście dostępnych rozszerzeń EGL.
• Implementacje na urządzeniach MUSZĄ zawierać funkcje GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2 i GL_OVR_multiview_multisampled_render_to_texture oraz udostępniać je na liście dostępnych rozszerzeń GL.
• Implementacje na urządzeniach MUSZĄ implementować EGL_EXT_protected_content i GL_EXT_protected_textures, aby można było ich używać do odtwarzania zabezpieczonego wideo z teksturą. Należy też udostępnić te rozszerzenia na liście dostępnych rozszerzeń EGL i GL.
• Implementacje urządzeń MUSZĄ obsługiwać dekodowanie H.264 z co najmniej rozdzielczością 3840 × 2160 przy 30 fps i 40 Mb/s (co odpowiada 4 przypadkom 1920 × 1080 przy 30 fps i 10 Mb/s lub 2 przypadkom 1920 × 1080 przy 60 fps i 20 Mb/s).
• Implementacje urządzeń MUSZĄ obsługiwać HEVC i VP9, MUSZĄ być w stanie dekodować co najmniej 1920 x 1080 przy 30 fps i 10 Mb/s oraz POWINNY być w stanie dekodować 3840 x 2160 przy 30 fps i 20 Mb/s (co odpowiada 4 przypadkom 1920 x 1080 przy 30 fps i 5 Mb/s).
• W przypadku implementacji na urządzeniu ZALECAMY obsługę funkcji android.hardware.sensor.hifi_sensors. Należy też spełnić wymagania dotyczące żyroskopu, akcelerometru i magnetometru dla android.hardware.hifi_sensors.
• Implementacje urządzeń MUSZĄ obsługiwać interfejs API HardwarePropertiesManager.getDeviceTemperatures i zwracać dokładne wartości temperatury skóry.
• Urządzenie MUSI mieć wbudowany ekran o rozdzielczości co najmniej FullHD(1080p). ZALECAMY, aby rozdzielczość wynosiła QuadHD (1440p) lub więcej.
• Wyświetlacz MUSI mieć przekątną o długości od 4,7 do 6 cali.
• W trybie VR wyświetlacz MUSI odświeżać obraz z częstotliwością co najmniej 60 Hz.
• Czas reakcji wyświetlacza na przejście z szarego na szary, z białego na czarny i z czarnego na biały MUSI wynosić ≤ 3 ms.
• Wyświetlacz MUSI obsługiwać tryb o niskiej trwałości z trwałością do 5 ms, przy czym trwałość jest definiowana jako czas, przez który piksel emituje światło.
• Implementacje urządzeń MUSZĄ obsługiwać rozszerzenie długości danych Bluetooth 4.2 i Bluetooth LE sekcja 7.4.3 .

8. Wydajność i moc

Niektóre kryteria dotyczące minimalnej wydajności i mocy są kluczowe dla wrażeń użytkowników i mają wpływ na założenia, które programiści powinni przyjąć podczas tworzenia aplikacji. Zegarki z Androidem powinny spełniać te kryteria, a inne typy urządzeń muszą je spełniać.

8.1. Spójność w interfejsie użytkownika

Implementacje urządzeń MUSZĄ zapewniać płynny interfejs użytkownika poprzez zapewnienie spójnej liczby klatek i czasu odpowiedzi w przypadku aplikacji i gier. Implementacje urządzeń MUSZĄ spełniać te wymagania:

• Stały czas opóźnienia klatek. Niespójny czas oczekiwania na wyświetlenie lub opóźnienie w renderowaniu klatek NIE MOŻE występować częściej niż 5 razy na sekundę, a liczba klatek na sekundę powinna być mniejsza niż 1.
• Opóźnienia w interfejsie użytkownika . Implementacje urządzeń MUSZĄ zapewniać użytkownikom niskie opóźnienia, umożliwiając przewijanie listy 10 tys. pozycji na liście w mniej niż 36 sekund, zgodnie z definicją w pakiecie testów zgodności (CTS) Androida.
• Przełączanie zadań . Gdy uruchomionych jest kilka aplikacji, ponowne uruchomienie już uruchomionej aplikacji MUSI zająć mniej niż 1 sekundę.

8.2. Wydajność dostępu do plikowego wejścia/wyjścia

Implementacje urządzeń MUSZĄ zapewniać spójność wydajności dostępu do plików w pamięci wewnętrznej w przypadku operacji odczytu i zapisu.

• Sekwencyjny zapis . Implementacje urządzeń MUSZĄ zapewniać wydajność sekwencyjnego zapisu na poziomie co najmniej 5 MB/s w przypadku pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
• Losowe zapisywanie . Implementacje urządzeń MUSZĄ zapewniać wydajność zapisu losowego na poziomie co najmniej 0,5 MB/s w przypadku pliku o rozmiary 256 MB przy użyciu bufora zapisu o rozmiary 4 KB.
• Czytanie sekwencyjne . Implementacje urządzeń MUSZĄ zapewniać wydajność odczytu sekwencyjnego na poziomie co najmniej 15 MB/s w przypadku pliku o rozmiarze 256 MB przy użyciu bufora zapisu o rozmiarze 10 MB.
• Losowe czytanie . Implementacje urządzeń MUSZĄ zapewniać wydajność losowego odczytu na poziomie co najmniej 3,5 MB/s w przypadku pliku o rozmiary 256 MB przy użyciu bufora zapisu o rozmiary 4 KB.

8.3. Tryby oszczędzania energii

W Androidzie 6.0 wprowadzono tryby w oczekujących aplikacjach i Doze, które optymalizują zużycie baterii. Wszystkie aplikacje zwolnione z tych trybów MUSZĄ być widoczne dla użytkownika końcowego. Ponadto uruchamianie, konserwacja, algorytmy budzenia i użycie globalnych ustawień systemu tych trybów oszczędzania energii NIE mogą odbiegać od projektu Android Open Source.

Oprócz trybów oszczędzania energii implementacje urządzeń z Androidem MOGĄ stosować dowolne lub wszystkie 4 stany uśpienia zdefiniowane przez interfejs ACPI (Advanced Configuration and Power Interface), ale jeśli implementują stany S3 i S4, mogą wejść w te stany tylko po zamknięciu pokrywy, która jest fizyczną częścią urządzenia.

8.4. Rachunkowość zużycia energii

Dokładniejsze rozliczanie i raportowanie zużycia energii daje deweloperowi aplikacji zarówno zachęty, jak i narzędzia do optymalizacji wzorców zużycia energii przez aplikację. Dlatego implementacje na urządzeniach:

• Musi być możliwe śledzenie zużycia energii przez komponent sprzętowy i przypisywanie tego zużycia do konkretnych aplikacji. W szczególności:
  • Musisz podać profil zasilania dla każdego komponentu, który definiuje wartość bieżącego zużycia energii dla każdego komponentu sprzętowego oraz przybliżone zużycie energii przez komponenty w czasie, zgodnie z dokumentacją na stronie projektu Android Open Source.
  • Wszystkie wartości zużycia energii MUSZĄ być podawane w miliamperogodzinach (mAh).
  • POWINIEN być przypisany do samego komponentu sprzętowego, jeśli nie można przypisać zużycia energii komponentu sprzętowego do aplikacji.
  • MUSI zgłaszać zużycie energii przez procesor dla każdego identyfikatora UID procesu. Projekt Android Open Source spełnia to wymaganie dzięki implementacji modułu jądra uid_cputime.
• Musisz udostępnić ten pobór mocy deweloperowi aplikacji za pomocą polecenia adb shell dumpsys batterystats w powłoce.
• MUSI obsługiwać działanie android.intent.action.POWER_USAGE_SUMMARY i wyświetlać menu ustawień, które pokazuje zużycie energii.

8.5. Spójna wydajność

Wydajność może się znacznie wahać w przypadku aplikacji o wysokiej wydajności i długim czasie działania z powodu innych aplikacji działających w tle lub ograniczania procesora z powodu limitów temperatury. Android zawiera interfejsy programowe, dzięki którym aplikacja na pierwszym planie może poprosić system o zoptymalizowanie przydziału zasobów w celu łagodzenia takich wahań.

Implementacje urządzeń powinny obsługiwać tryb ciągłej wydajności, który może zapewnić najwyższej aplikacji na pierwszym planie stały poziom wydajności przez dłuższy czas, gdy zostanie to zażądane za pomocą metody interfejsu API Window.setSustainedPerformanceMode(). Wdrożenie na urządzeniu MUSI prawidłowo zgłaszać obsługę trybu ciągłej wydajności za pomocą metody interfejsu API PowerManager.isSustainedPerformanceModeSupported().

Implementacje urządzeń z co najmniej 2 rdzeniami procesora POWINNY mieć co najmniej 1 rdzeń, który może być zarezerwowany przez główną aplikację na pierwszym planie. W razie potrzeby implementacje MUSZĄ spełniać te wymagania:

• Implementacje MUSZĄ zgłaszać za pomocą metody interfejsu API Process.getExclusiveCores() numery identyfikatorów rdzeni zastrzeżonych, które mogą być zarezerwowane przez główną aplikację na pierwszym planie.
• Implementacje urządzeń NIE MOGĄ zezwalać na uruchamianie na rdzeniach zastrzeżonych żadnych procesów w przestrzeni użytkownika z wyjątkiem sterowników urządzeń używanych przez aplikację, ale MOGĄ zezwalać na uruchamianie niektórych procesów jądra w razie potrzeby.

Jeśli implementacja urządzenia nie obsługuje rdzenia wyłącznego, MUSI zwrócić pustą listę za pomocą metody interfejsu API Process.getExclusiveCores().

9. Zgodność modelu zabezpieczeń

Implementacje urządzeń MUSZĄ stosować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji interfejsów API w dokumentacji dla deweloperów Androida. Implementacje urządzeń MUSZĄ obsługiwać instalowanie samodzielnie podpisanych aplikacji bez konieczności uzyskiwania dodatkowych uprawnień lub certyfikatów od stron trzecich lub organów. W szczególności kompatybilne urządzenia MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w następnych podrozdziałach.

9.1. Uprawnienia

Implementacje urządzeń MUSZĄ obsługiwać model uprawnień Androida zgodnie z definicją w dokumentacji dla deweloperów Androida. W szczególności implementacje MUSZĄ egzekwować każde uprawnienie zdefiniowane zgodnie z opisem w dokumentacji pakietu SDK. Żadnego uprawnienia nie można pominąć, zmienić ani zignorować. Implementacje MOGĄ dodawać dodatkowe uprawnienia, o ile nowe ciągi identyfikatorów uprawnień nie znajdują się w przestrzeni nazw android.*.

Uprawnienia z protectionLevel PROTECTION_FLAG_PRIVILEGED MUSZĄ być przyznawane tylko aplikacjom wstępnie załadowanym w dozwolonych ścieżkach uprzywilejowanych obrazu systemu, takich jak ścieżka system/priv-app w implementacji AOSP.

Uprawnienia z poziomem ochrony niebezpieczny to uprawnienia czasu działania. Aplikacje z wartością targetSdkVersion > 22 wysyłają je w czasie wykonywania. Implementacje na urządzeniu:

• MUSI wyświetlać specjalny interfejs, aby użytkownik mógł zdecydować, czy przyznać żądane uprawnienia w czasie działania, a także udostępnić interfejs do zarządzania uprawnieniami w czasie działania.
• Musisz mieć jedną i tylko jedną implementację obu interfejsów użytkownika.
• NIE MOŻESZ przyznawać żadnych uprawnień na czas działania aplikacjiom wstępnie zainstalowanym, chyba że:
  • zgoda użytkownika może zostać uzyskana przed użyciem danych przez aplikację;
  • uprawnienia w czasie działania są powiązane z wzorcem intencji, dla którego domyślnym modułem obsługi jest wstępnie zainstalowana aplikacja.

9.2. UID i izolacja procesów

Implementacje urządzeń MUSZĄ obsługiwać model piaskownicy aplikacji Androida, w którym każda aplikacja działa jako unikalny identyfikator UID w stylu Unixa i w oddzielnym procesie. Implementacje urządzeń MUSZĄ obsługiwać uruchamianie wielu aplikacji z tym samym identyfikatorem użytkownika Linuksa, pod warunkiem że aplikacje są prawidłowo podpisane i skonstruowane zgodnie z definicją w dokumentacji dotyczącej zabezpieczeń i uprawnień .

9.3. Uprawnienia do systemu plików

Implementacje urządzeń MUSZĄ obsługiwać model uprawnień dostępu do plików Androida zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień .

9.4. Alternatywne środowiska wykonawcze

Implementacje urządzeń mogą zawierać środowiska uruchomieniowe, które wykonują aplikacje za pomocą innego oprogramowania lub innej technologii niż format wykonywalny Dalvik lub kod natywny. Jednak takie alternatywne środowiska wykonania NIE MOGĄ naruszać modelu zabezpieczeń Androida ani zabezpieczeń zainstalowanych aplikacji na Androida, jak opisano w tej sekcji.

Alternatywny czas wykonywania MUSI być aplikacją na Androida i stosować się do standardowego modelu zabezpieczeń Androida, jak opisano w sekcji 9 .

Alternatywnym środowiskom uruchomieniowym NIE wolno przyznawać dostępu do zasobów chronionych przez uprawnienia, których nie żądano w pliku AndroidManifest.xml środowiska uruchomieniowego za pomocą mechanizmu <uses-permission>.

Alternatywny czas działania NIE MOŻE zezwalać aplikacjom na korzystanie z funkcji chronionych przez uprawnienia Androida, które są ograniczone do aplikacji systemowych.

Alternatywne środowisko uruchomieniowe MUSI być zgodne z modelem piaskownicy Androida. W szczególności alternatywne środowiska wykonawcze:

• NALEŻY instalować aplikacje za pomocą menedżera pakietów w oddzielnych piaskownicach Androida (identyfikatory użytkowników Linuksa itp.).
• MOŻE udostępniać jedną piaskownicę Androida, która jest używana przez wszystkie aplikacje korzystające z alternatywnego środowiska wykonawczego.
• Zainstalowane aplikacje korzystające z alternatywnego środowiska uruchomieniowego NIE MOGĄ ponownie używać piaskownicy żadnej innej aplikacji zainstalowanej na urządzeniu, z wyjątkiem standardowych mechanizmów Androida dotyczących udostępnionego identyfikatora użytkownika i certyfikatu podpisywania.
• NIE MOŻE uruchamiać, przyznawać ani uzyskiwać dostępu do piaskownicy odpowiadającej innym aplikacjom na Androida.
• NIE MOŻE być uruchamiana z uprawnieniami superużytkownika (root) ani nie może przyznawać takich uprawnień innym aplikacjom. Nie może też przyznawać innym aplikacjom żadnych uprawnień superużytkownika (root) ani żadnych innych identyfikatorów użytkownika.

Pliki .apk alternatywnych środowisk uruchomieniowych MOGĄ być uwzględnione w pliku obrazu systemu implementacji urządzenia, ale MUSZĄ być podpisane za pomocą klucza innego niż klucz używany do podpisywania innych aplikacji zawartych w implementacji urządzenia.

Podczas instalowania aplikacji alternatywne środowisko uruchomieniowe MUSI uzyskać zgodę użytkownika na uprawnienia Androida używane przez aplikację. Jeśli aplikacja musi korzystać z zasobu urządzenia, do którego dostęp jest możliwy dzięki odpowiedniemu uprawnieniu Androida (np. aparat, GPS itp.), alternatywny czas wykonywania MUSI informować użytkownika, że aplikacja będzie mieć dostęp do tego zasobu. Jeśli środowisko uruchomieniowe nie rejestruje w taki sposób możliwości aplikacji, MUSI ono podać wszystkie uprawnienia posiadane przez środowisko uruchomieniowe podczas instalowania dowolnej aplikacji korzystającej z tego środowiska.

9,5. Pomoc dla wielu użytkowników

Android obsługuje wielu użytkowników i pozwala na pełną izolację użytkowników. W ramach implementacji urządzenia MOŻNA włączyć obsługę wielu użytkowników, ale w takim przypadku należy spełnić te wymagania dotyczące obsługi wielu użytkowników :

• Wdrożenia urządzeń z Androidem Automotive z włączonym wsparciem dla wielu użytkowników MUSZĄ zawierać konto gościa, które umożliwia korzystanie ze wszystkich funkcji systemu pojazdu bez konieczności logowania się użytkownika.
• Implementacje urządzeń, które nie deklarują flagi funkcji android.hardware.telephony, MUSZĄ obsługiwać profile ograniczone. Jest to funkcja, która pozwala właścicielom urządzeń zarządzać dodatkowymi użytkownikami i ich możliwościami na urządzeniu. Dzięki profilom z ograniczeniami właściciele urządzeń mogą szybko konfigurować oddzielne środowiska dla dodatkowych użytkowników, a także zarządzać bardziej szczegółowymi ograniczeniami w aplikacjach dostępnych w tych środowiskach.
• Z drugiej strony implementacje urządzeń, które deklarują flagę funkcji android.hardware.telephony, NIE MOGĄ obsługiwać profili ograniczonych, ale MUSZĄ być zgodne z implementacją kontroli AOSP, aby umożliwić lub zablokować innym użytkownikom dostęp do połączeń głosowych i SMS-ów.
• Implementacje urządzeń MUSZĄ dla każdego użytkownika implementować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Androida określonym w dokumentacji referencyjnej Bezpieczeństwo i uprawnienia dostępu dotyczącej interfejsów API.
• Każdy użytkownik na urządzeniu z Androidem MUSI mieć osobne i odizolowane katalogi pamięci zewnętrznej. Implementacje urządzeń MOGĄ przechowywać dane wielu użytkowników w tym samym woluminie lub systemie plików. Implementacja urządzenia MUSI jednak zapewniać, że aplikacje należące do danego użytkownika i działające w jego imieniu nie mogą wyświetlać, odczytywać ani zapisywać danych należących do innego użytkownika. Pamiętaj, że wymienne nośniki, takie jak gniazda kart SD, mogą umożliwiać jednemu użytkownikowi dostęp do danych innego użytkownika za pomocą komputera hosta. Z tego powodu implementacje urządzeń, które używają wymiennych nośników dla interfejsów API zewnętrznej pamięci, MUSZĄ szyfrować zawartość karty SD, jeśli włączono tryb wieloużytkownika, za pomocą klucza przechowywanego tylko na niewymiennym nośniku dostępnym tylko dla systemu. Ponieważ spowoduje to, że media nie będą czytelne dla komputera hosta, implementacje urządzeń będą musiały przejść na MTP lub podobny system, aby zapewnić komputerom hosta dostęp do danych bieżącego użytkownika. W związku z tym implementacje urządzeń MOGĄ, ALE NIE POWINNY umożliwiać korzystania z wielu użytkowników, jeśli używają wymiennych nośników danych jako głównej pamięci zewnętrznej.

9,6. Ostrzeżenie dotyczące SMS-ów specjalnych

Android obsługuje ostrzeżenia użytkowników o wysyłanych specjalnych SMS-ach . SMS-y premium to wiadomości tekstowe wysyłane do usługi zarejestrowanej u operatora, za którą może być pobierana opłata od użytkownika. Implementacje urządzeń, które deklarują obsługę android.hardware.telephony, MUSZĄ ostrzegać użytkowników przed wysyłaniem SMS-a na numery zdefiniowane za pomocą wyrażeń regularnych w pliku /data/misc/sms/codes.xml na urządzeniu. Dostępny w górę projektu Android Open Source Project zapewnia implementację, która spełnia ten wymóg.

9,7. Funkcje zabezpieczeń jądra

Piaskownica Androida zawiera funkcje korzystające z systemu kontroli dostępu (MAC) Security-Enhanced Linux (SELinux), piaskownicy seccomp i innych funkcji zabezpieczeń w jądrze systemu Linux. SELinux lub inne funkcje zabezpieczeń zaimplementowane poniżej platformy Android:

• MUSI być zgodna z dotychczasowymi aplikacjami.
• Nie wolno wyświetlać widocznego interfejsu użytkownika, gdy wykryto i zablokowano naruszenie zabezpieczeń, ale można wyświetlić widoczny interfejs użytkownika, gdy dochodzi do niezablokowanego naruszenia zabezpieczeń, które prowadzi do skutecznego wykorzystania luki.
• NIE powinny być konfigurowalne przez użytkownika ani dewelopera.

Jeśli interfejs API do konfiguracji zasad jest udostępniony aplikacji, która może wpływać na inną aplikację (np. interfejs API do zarządzania urządzeniami), interfejs API NIE MOŻE zezwalać na konfiguracje, które naruszają zgodność.

Urządzenia MUSZĄ implementować SELinux lub, jeśli używają jądra innego niż Linux, równoważny system obowiązkowego kontroli dostępu. Urządzenia MUSZĄ też spełniać te wymagania, które są spełnione przez implementację referencyjną w górnym projekcie Android Open Source.

Implementacje na urządzeniu:

• Musisz ustawić SELinux na tryb wymuszania globalnego.
• NALEŻY skonfigurować wszystkie domeny w trybie wymuszania. Niedozwolone są domeny w trybie dozwolonym, w tym domeny związane z urządzeniem lub dostawcą.
• Nie wolno modyfikować, pomijać ani zastępować reguł neverallow znajdujących się w folderze system/sepolicy udostępnianym w ramach projektu upstream Android Open Source (AOSP). Zasady muszą być zgodne ze wszystkimi regułami neverallow, zarówno w przypadku domen AOSP SELinux, jak i w przypadku domen konkretnych urządzeń lub dostawców.
• NALEŻY podzielić framework mediów na kilka procesów, aby umożliwić bardziej szczegółowe przyznawanie dostępu do poszczególnych procesów zgodnie z opisem na stronie projektu Android Open Source.

Implementacje urządzeń powinny zachować domyślną zasadę SELinux udostępnioną w folderze system/sepolicy w ramach projektu typu upstream Open Source na Androida i tylko dodać do tej zasady własną konfigurację. Implementacje urządzeń MUSZĄ być zgodne z poprzednim projektem Android Open Source.

Urządzenia MUSZĄ stosować mechanizm piaskownicy aplikacji jądra, który umożliwia filtrowanie wywołań systemowych za pomocą konfigurowalnych zasad z programów wielowątkowych. Projekt Android Open Source na upstreamie spełnia ten wymóg dzięki włączeniu seccomp-BPF z synchronizacją wątków grup (TSYNC), jak opisano w sekcji Konfiguracja jądra na stronie source.android.com .

9,8. Prywatność

Jeśli urządzenie implementuje funkcję w systemie, która rejestruje treści wyświetlane na ekranie lub nagrywa strumień audio odtwarzany na urządzeniu, MUSI stale informować użytkownika, gdy ta funkcja jest włączona i aktywnie rejestruje/nagrywa.

Jeśli implementacja urządzenia zawiera mechanizm, który domyślnie kieruje ruch danych sieciowych przez serwer proxy lub bramę VPN (np. w ramach wstępnego wczytania usługi VPN z przyznanym uprawnieniem android.permission.CONTROL_VPN), przed włączeniem tego mechanizmu implementacja urządzenia MUSI poprosić o zgodę użytkownika, chyba że VPN jest włączony przez kontroler zasad urządzenia za pomocą DevicePolicyManager.setAlwaysOnVpnPackage(). W takim przypadku użytkownik nie musi wyrażać osobnej zgody, ale MUSI zostać powiadomiony.

Implementacje urządzeń MUSZĄ być dostarczane z pustym magazynem urzędu certyfikacji dodanym przez użytkownika i MUSZĄ mieć wstępnie zainstalowane te same certyfikaty główne dla magazynu urzędu certyfikacji zaufanych przez system, które są dostępne w poprzednim projekcie Android Open Source.

Gdy urządzenia są kierowane przez VPN lub jest zainstalowany użytkownik z root CA, implementacja MUSI wyświetlać użytkownikowi ostrzeżenie o możliwości monitorowania ruchu w sieci.

Jeśli implementacja urządzenia ma port USB z obsługą trybu urządzenia peryferyjnego USB, MUSI wyświetlać interfejs z prośbą o zgodę użytkownika przed zezwoleniem na dostęp do zawartości współdzielonego miejsca na dane przez port USB.

9.9. Szyfrowanie danych przechowywanych

Jeśli implementacja urządzenia obsługuje bezpieczny ekran blokady zgodnie z opisem w sekcji 9.11.1, urządzenie MUSI obsługiwać szyfrowanie danych w pamięci aplikacji (partycja /data) oraz w wspólnej pamięci aplikacji (partycja /sdcard), jeśli jest to stała, nieusuwalna część urządzenia.

W przypadku implementacji urządzeń obsługujących szyfrowanie danych i mających wydajność szyfrowania Advanced Encryption Standard (AES) powyżej 50 MiB/s szyfrowanie danych MUSI być domyślnie włączone po zakończeniu konfiguracji urządzenia. Jeśli implementacja urządzenia została już uruchomiona w starszej wersji Androida z zaszyfrowaniem wyłączonym domyślnie, takie urządzenie nie może spełnić wymagań poprzez aktualizację oprogramowania systemowego i MOŻE być wyłączone z obowiązku.

Implementacje urządzeń powinny spełniać powyższy wymóg szyfrowania danych poprzez implementację szyfrowania na poziomie pliku (FBE).

9.9.1. Bezpośredni rozruch

Wszystkie urządzenia MUSZĄ implementować interfejsy API Tryb bezpośredniego rozruchu, nawet jeśli nie obsługują szyfrowania pamięci. W szczególności nadal muszą być nadawane intencje LOCKED_BOOT_COMPLETED i ACTION_USER_UNLOCKED, aby sygnalizować aplikacjom obsługującym bezpośrednie uruchamianie, że dostępne są szyfrowane miejsca na dane na urządzeniu (DE) i szyfrowane miejsce na dane z danymi logowania (CE).

9.9.2. Szyfrowanie oparte na plikach

Implementacje urządzeń obsługujące FBE:

• Musi się uruchamiać bez żądania od użytkownika danych logowania i umożliwiać aplikacjom obsługującym bezpośrednie uruchamianie dostęp do zaszyfrowanej pamięci urządzenia (DE) po przesłaniu komunikatu LOCKED_BOOT_COMPLETED.
• Musi zezwalać na dostęp do zaszyfrowanych danych uwierzytelniających (CE) dopiero po odblokowaniu urządzenia przez użytkownika za pomocą danych uwierzytelniających (np. kodu dostępu, kodu PIN, wzoru lub odcisku palca) i wysłaniu komunikatu ACTION_USER_UNLOCKED. Implementacje urządzeń NIE MOGĄ oferować żadnej metody odblokowania chronionego magazynu CE bez podania przez użytkownika danych logowania.
• MUSI obsługiwać weryfikację podczas uruchamiania i zapewniać, że klucze DE są związane kryptograficznie z sprzętowym korzeniami zaufania urządzenia.
• MUSI obsługiwać szyfrowanie zawartości pliku za pomocą algorytmu AES z kluczem o długości 256 bitów w trybie XTS.
• MUSI obsługiwać szyfrowanie nazwy pliku za pomocą algorytmu AES z kluczem o długości 256 bitów w trybie CBC-CTS.
• MOŻE obsługiwać alternatywne szyfry, długości kluczy i tryby szyfrowania zawartości plików i nazw plików, ale MUSI domyślnie używać obsługiwanych obligatoryjnie szyfrów, długości kluczy i trybów.
• NALEŻY zadbać o to, aby wstępnie zainstalowane niezbędne aplikacje (np. budzik, Telefon, Messenger) były świadome bezpośredniego uruchamiania.

Klucze chroniące obszary pamięci CE i DE:

• MUSI być przywiązany kryptograficznie do klucza sprzętowego. Klucze CE muszą być powiązane z danymi logowania użytkownika na ekranie blokady. Jeśli użytkownik nie podał danych logowania na ekranie blokady, klucze CE MUSZĄ być powiązane z domyślnym kodem dostępu.
• MUSI być unikalny i niepowtarzalny. Innymi słowy, klucz CE lub DE żadnego użytkownika nie może być taki sam jak klucz CE lub DE innego użytkownika.

Wspólny projekt Android Open Source udostępnia preferowaną implementację tej funkcji na podstawie funkcji szyfrowania ext4 jądra Linuksa.

9.9.3. Pełne szyfrowanie dysku

Implementacje urządzeń obsługujące pełne szyfrowanie dysku (FDE). NALEŻY użyć AES z kluczem 128-bitowym (lub większym) i trybem przeznaczonym do przechowywania (np. AES-XTS, AES-CBC-ESIV). Klucz szyfrowania NIE MOŻE być zapisywany w magazynie w niezaszyfrowanej formie. Użytkownik MUSI mieć możliwość zaszyfrowania klucza szyfrowania za pomocą AES, z wyjątkiem sytuacji, gdy jest on aktywnie używany, a dane logowania na ekranie blokady są rozciągnięte za pomocą algorytmu powolnego rozciągania (np. PBKDF2 lub scrypt). Jeśli użytkownik nie podał danych logowania na ekranie blokady lub wyłączył używanie kodu dostępu do szyfrowania, system powinien użyć domyślnego kodu dostępu do zapakowania klucza szyfrowania. Jeśli urządzenie udostępnia magazyn kluczy obsługiwany sprzętowo, algorytm rozciągania hasła MUSI być powiązany kryptograficznie z tym magazynem kluczy. Klucza szyfrowania NIE MOŻNA wysyłać z urządzenia (nawet gdy jest on zaszyfrowany za pomocą hasła użytkownika lub klucza powiązanego ze sprzętem). Wspólny projekt Android Open Source udostępnia preferowaną implementację tej funkcji na podstawie funkcji dm-crypt jądra Linuksa.

9.10. Integralność urządzenia

Wymagania te zapewniają przejrzystość stanu integralności urządzenia.

Implementacje urządzeń MUSZĄ prawidłowo zgłaszać za pomocą metody interfejsu API systemu PersistentDataBlockManager.getFlashLockState(), czy stan ich bootloadera zezwala na flashowanie obrazu systemu. Stan FLASH_LOCK_UNKNOWN jest zarezerwowany dla implementacji urządzeń uaktualnianych z wcześniejszej wersji Androida, w której nie istniała ta nowa metoda interfejsu API.

Weryfikacja podczas uruchamiania to funkcja, która gwarantuje integralność oprogramowania urządzenia. Jeśli implementacja urządzenia obsługuje tę funkcję, MUSI:

• Zadeklaruj flagę funkcji platformy android.software.verified_boot.
• Przeprowadzać weryfikację w ramach każdego sekwencji uruchamiania.
• Rozpocznij weryfikację od niezmiennego klucza sprzętowego, który jest źródłem zaufania, i przeprowadź ją aż do partycji systemowej.
• Zaimplementuj każdy etap weryfikacji, aby sprawdzić integralność i autentyczność wszystkich bajtów na następnym etapie przed wykonaniem kodu na tym etapie.
• Używaj algorytmów weryfikacji o tak dużej sile, jak zalecane przez NIST algorytmy szyfrowania (SHA-256) i kluczy publicznych (RSA-2048).
• NIE MOŻNA dopuścić do uruchomienia, gdy weryfikacja systemu się nie powiedzie, chyba że użytkownik wyrazi zgodę na próbę uruchomienia, w którym przypadku NIE MOŻNA używać danych z niezweryfikowanych bloków pamięci.
• Nie wolno modyfikować zweryfikowanych partycji na urządzeniu, chyba że użytkownik wyraźnie odblokuje program ładujący.

Projekt Android Open Source udostępnia preferowaną implementację tej funkcji na podstawie funkcji dm-verity jądra Linuksa.

Począwszy od Androida 6.0 implementacje urządzeń z wydajnością szyfrowania Advanced Encryption Standard (AES) powyżej 50 MiB/sekund MUSZĄ obsługiwać zweryfikowane uruchamianie w celu zapewnienia integralności urządzenia.

Jeśli implementacja urządzenia została już uruchomiona bez obsługi weryfikowanego uruchamiania w wersji Androida wcześniejszej niż 9.0, nie można dodać obsługi tej funkcji za pomocą aktualizacji oprogramowania systemowego. Takie urządzenie jest więc zwolnione z tego wymogu.

9.11. Klucze i dane logowania

System Keystore Androida umożliwia deweloperom aplikacji przechowywanie kluczy kryptograficznych w kontenerze i używanie ich w operacjach kryptograficznych za pomocą interfejsu KeyChain API lub Keystore API .

Wszystkie implementacje urządzeń z Androidem MUSZĄ spełniać te wymagania:

• NIE powinna ograniczać liczby generowanych kluczy i MUSI zezwalać na importowanie co najmniej 8192 kluczy.
• Uwierzytelnianie na ekranie blokady MUSI ograniczać liczbę prób i MUSI używać algorytmu wykładniczego. Po 150 nieudanych próbach opóźnienie musi wynosić co najmniej 24 godziny na próbę.
• Jeśli implementacja na urządzeniu obsługuje bezpieczny ekran blokady, MUSI ona tworzyć kopie zapasowe implementacji magazynu kluczy na bezpiecznym sprzęcie i spełniać te wymagania:
  • W ramach prawidłowego obsługiwania obsługiwanych algorytmów systemu Keystore na Androidzie w obszarze bezpiecznie odizolowanym od kodu działającego w jądrze lub wyżej MUSISZ mieć implementacje algorytmów kryptograficznych RSA, AES, ECDSA i HMAC oraz funkcji haszowania z rodziny MD5, SHA-1 i SHA-2. Bezpieczna izolacja MUSI blokować wszystkie potencjalne mechanizmy, za pomocą których kod jądra lub kodu przestrzeni użytkownika może uzyskać dostęp do stanu wewnętrznego odizolowanego środowiska, w tym DMA. Projekt upstream Android Open Source Project (AOSP) spełnia ten wymóg, ponieważ korzysta z implementacji Trusty, ale alternatywnym rozwiązaniem jest inne rozwiązanie oparte na ARM TrustZone lub bezpieczna implementacja odpowiedniej izolacji na poziomie hypervisora, która została sprawdzona przez zewnętrzną firmę.
  • NALEŻY przeprowadzić uwierzytelnianie na ekranie blokady w odizolowanym środowisku wykonywania i zezwolić na używanie kluczy powiązanych z uwierzytelnianiem tylko wtedy, gdy proces uwierzytelniania zakończy się pomyślnie. Wspólny projekt Android Open Source udostępnia interfejs HAL (Hardware Abstraction Layer) i Trusty, które można wykorzystać do spełnienia tego wymagania.

Pamiętaj, że jeśli implementacja urządzenia została już uruchomiona w poprzedniej wersji Androida, nie musi ona spełniać wymagania dotyczące posiadania magazynu kluczy obsługiwanego przez sprzęt, chyba że deklaruje funkcję android.hardware.fingerprint, która wymaga magazynu kluczy obsługiwanego przez sprzęt.

9.11.1. Bezpieczna blokada ekranu

Implementacje urządzeń MOGĄ dodawać lub modyfikować metody uwierzytelniania, aby odblokować ekran blokady, ale MUSZĄ spełniać te wymagania:

• Metoda uwierzytelniania, jeśli opiera się na znanym obiekcie tajnym, NIE MOŻE być traktowana jako bezpieczny ekran blokady, chyba że spełnia wszystkie te wymagania:
  • Entropia najkrótszych dozwolonych danych wejściowych MUSI być większa niż 10 bitów.
  • Maksymalna entropia wszystkich możliwych danych wejściowych MUSI być większa niż 18 bitów.
  • NIE MOŻE zastępować żadnej z dotychczasowych metod uwierzytelniania (kod PIN, wzór, hasło) zaimplementowanych i dostępnych w AOSP.
  • MUSI być wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) skonfigurowała zasady jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_SOMETHING .
• Metoda uwierzytelniania oparta na fizycznym tokenie lub lokalizacji NIE MOŻE być traktowana jako bezpieczny ekran blokady, chyba że spełnia wszystkie te wymagania:
  • Musi zawierać mechanizm zapasowy, który umożliwia korzystanie z jednej z podstawowych metod uwierzytelniania opartej na znanym kluczu tajnym i spełniającej wymagania dotyczące traktowania jako bezpieczny ekran blokady.
  • Musi być wyłączona i zezwalać na odblokowanie ekranu tylko przy użyciu uwierzytelniania podstawowego, gdy aplikacja Device Policy Controller (DPC) skonfigurowała zasady za pomocą metody DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) lub metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_UNSPECIFIED .
• Jeśli metoda uwierzytelniania opiera się na danych biometrycznych, NIE MOŻE być traktowana jako bezpieczny ekran blokady, chyba że spełnia wszystkie te wymagania:
  • Musi zawierać mechanizm zapasowy, który umożliwia korzystanie z jednej z podstawowych metod uwierzytelniania opartej na znanym kluczu tajnym i spełniającej wymagania dotyczące traktowania jako bezpieczny ekran blokady.
  • Musi być wyłączona i zezwalać na odblokowanie ekranu tylko za pomocą podstawowej metody uwierzytelniania, gdy aplikacja Device Policy Controller (DPC) ustawiła zasadę funkcji keguard, wywołując metodę DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) .
  • Musi on mieć współczynnik błędów równy lub wyższy niż wymagany dla czujnika odcisków palców zgodnie z opisem w sekcji 7.3.10. W przeciwnym razie musi być wyłączony i umożliwiać odblokowanie ekranu tylko za pomocą uwierzytelniania podstawowego, gdy aplikacja Device Policy Controller (DPC) ustawiła zasady jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_BIOMETRIC_WEAK.
• Jeśli metody uwierzytelniania nie można uznać za bezpieczną blokadę ekranu, nie spełnia ona tych kryteriów:
  • Musi zwracać wartość false zarówno w przypadku metody KeyguardManager.isKeyguardSecure(), jak i KeyguardManager.isDeviceSecure().
  • MUSI być wyłączona, gdy aplikacja kontrolera zasad dotyczących urządzeń (DPC) skonfigurowała zasady jakości hasła za pomocą metody DevicePolicyManager.setPasswordQuality() z bardziej restrykcyjną stałą jakości niż PASSWORD_QUALITY_UNSPECIFIED .
  • NIE NALEŻY resetować liczników czasu ważności hasła ustawionych przez DevicePolicyManager.setPasswordExpirationTimeout() .
  • NIE MOŻE uwierzytelniać dostępu do magazynów kluczy, jeśli aplikacja wywołała funkcję KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true).
• Jeśli metoda uwierzytelniania opiera się na fizycznym tokenie, lokalizacji lub danych biometrycznych, które mają wyższy wskaźnik błędów przyjęcia niż wymagany dla czujników odcisków palców zgodnie z opisem w sekcji 7.3.10, to:
  • NIE NALEŻY resetować liczników czasu ważności hasła ustawionych przez DevicePolicyManager.setPasswordExpirationTimeout() .
  • Nie wolno uwierzytelniać dostępu do repozytoriów kluczy, jeśli aplikacja wywołała funkcję KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) .

9.12. Usuwanie danych

Urządzenia MUSZĄ udostępniać użytkownikom mechanizm „przywracania do ustawień fabrycznych”, który umożliwia logiczne i fizyczne usunięcie wszystkich danych, z wyjątkiem:

• Obraz systemu
• wszelkie pliki systemu operacyjnego wymagane przez obraz systemu.

Wszystkie dane utworzone przez użytkowników MUSZĄ zostać usunięte. Musi być zgodny z odpowiednimi branżowymi standardami usuwania danych, takimi jak NIST SP800-88. Musisz go użyć do implementacji interfejsu wipeData() API (części interfejsu Android Device Administration API) opisanego w sekcji 3.9 Administracja urządzeniami .

Urządzenia mogą oferować szybkie czyszczenie danych, które polega na logicznym wymazaniu danych.

9.13. Tryb bezpiecznego rozruchu

Android udostępnia tryb, w którym użytkownicy mogą uruchomić tylko wstępnie zainstalowane aplikacje systemowe, a aplikacje innych firm są wyłączone. Ten tryb, znany jako „Tryb bezpiecznego uruchamiania”, umożliwia użytkownikowi odinstalowanie potencjalnie szkodliwych aplikacji innych firm.

W przypadku urządzeń z Androidem MOCNO zalecamy wdrożenie trybu bezpiecznego uruchamiania i spełnienie tych wymagań:

• Implementacje urządzeń POWINNY oferować użytkownikowi opcję uruchomienia trybu bezpiecznego uruchamiania z menu uruchamiania, które jest dostępne w ramach procesu różniącego się od normalnego uruchamiania.

• Implementacje urządzeń MUSZĄ oferować użytkownikowi opcję przejścia w tryb bezpiecznego rozruchu w sposób, który nie może być zakłócany przez aplikacje innych firm zainstalowane na urządzeniu, z wyjątkiem sytuacji, gdy aplikacja innej firmy jest kontrolerem zasad urządzenia i ma ustawiony parametr UserManager.DISALLOW_SAFE_BOOT jako prawda.

• Implementacje urządzeń MUSZĄ umożliwiać użytkownikowi odinstalowanie aplikacji innych firm w trybie bezpiecznym.

9.14. Izolacja systemów pojazdów samochodowych

Urządzenia z Androidem Automotive powinny wymieniać dane z krytycznymi podsystemami pojazdu, np. za pomocą interfejsu HAL pojazdu do wysyłania i odbierania wiadomości w sieciach pojazdu, takich jak magistrala CAN. Implementacje urządzeń z Androidem Automotive MUSZĄ zawierać funkcje zabezpieczeń poniżej warstw platformy Android, aby zapobiec złośliwej lub niezamierzonej interakcji między platformą Android lub aplikacjami innych firm a podsystemami pojazdu. Te funkcje bezpieczeństwa to:

• wiadomości z kontroli dostępu z podsystemów pojazdu w ramach frameworku Androida, np. zezwalanie na określone typy i źródła wiadomości;
• Watchdog chroni przed atakami typu DoS z ramek Androida lub aplikacji innych firm. Zapobiega to zasypywaniu sieci pojazdu przez złośliwe oprogramowanie, co może prowadzić do nieprawidłowego działania podsystemów pojazdu.

10. Testowanie zgodności oprogramowania

Implementacje urządzeń MUSZĄ przejść wszystkie testy opisane w tej sekcji.

Pamiętaj jednak, że żaden pakiet testów oprogramowania nie jest w pełni kompleksowy. Dlatego MOCNO zaleca się, aby implementujący urządzenia wprowadzali jak najmniej zmian w implementacji referencyjnej i preferowanej implementacji Androida dostępnej w ramach Projektu Android Open Source. Pozwoli to zminimalizować ryzyko wprowadzenia błędów, które powodują niezgodności wymagające ponownego wykonania i potencjalnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje urządzeń MUSZĄ przejść pakiet testów zgodności Androida (Compatibility Test Suite, CTS) dostępny w ramach projektu Android Open Source, przy użyciu oprogramowania dołączonego do urządzenia. Implementatorzy urządzeń powinni w jak największym stopniu korzystać z implementacji referencyjnej w drzewie Android Open Source oraz MUSZĄ zadbać o zgodność w przypadku niejednoznaczności w CTS i w przypadku każdej implementacji części kodu źródłowego referencyjnego.

Test CTS jest przeznaczony do uruchamiania na rzeczywistym urządzeniu. Podobnie jak inne oprogramowanie, CTS może zawierać błędy. Wersje CTS będą wydawane niezależnie od tej definicji zgodności, a w przypadku Androida 7.1 może być opublikowanych wiele wersji CTS. Implementacje urządzeń MUSZĄ przejść najnowszą wersję CTS dostępną w momencie ukończenia oprogramowania urządzenia.

10.2. Weryfikator CTS

Implementacje na urządzeniu MUSZĄ prawidłowo wykonywać wszystkie odpowiednie przypadki w weryfikatorze CTS. Narzędzie CTS Verifier jest dostępne w ramach pakietu Compatibility Test Suite i ma być używane przez operatora w celu testowania funkcji, których nie można przetestować za pomocą automatycznego systemu, np. prawidłowego działania kamery i czujników.

Narzędzie CTS Verifier zawiera testy wielu rodzajów sprzętu, w tym niektórych opcjonalnych. Implementacje urządzeń MUSZĄ przejść wszystkie testy sprzętu, które posiadają. Jeśli na przykład urządzenie ma akcelerometr, MUSI prawidłowo wykonać test akcelerometru w CTS Verifier. Przypadki testowe funkcji oznaczonych w tym dokumencie definicji zgodności jako opcjonalne MOGĄ zostać pominięte.

Jak wspomniano powyżej, na każdym urządzeniu i w przypadku każdej kompilacji musi działać narzędzie CTS Verifier. Ponieważ jednak wiele wersji jest bardzo podobnych, implementatorzy urządzeń nie muszą uruchamiać narzędzia CTS Verifier w przypadku wersji, które różnią się tylko nieznacznie. W szczególności implementacje urządzeń, które różnią się od implementacji, która przeszła weryfikację CTS Verifier, tylko pod względem zestawu obsługiwanych języków, marki itp., MOGĄ pominąć test CTS Verifier.

11. Oprogramowanie z możliwością aktualizacji

Implementacje urządzeń MUSZĄ zawierać mechanizm umożliwiający zastąpienie całego oprogramowania systemowego. Mechanizm nie musi wykonywać aktualizacji „na żywo”, czyli może być wymagane ponowne uruchomienie urządzenia.

Można użyć dowolnej metody, o ile pozwala ona na zastąpienie całego fabrycznie zainstalowanego oprogramowania. Na przykład dowolne z tych rozwiązań spełni to wymaganie:

• Bezprzewodowe (OTA) pobieranie z aktualizacją offline po ponownym uruchomieniu.
• „Przywiązane” aktualizacje przez USB z komputera hosta.
• Aktualizacje „offline” przez ponowne uruchomienie i aktualizację z pliku na nośniku wymiennym.

Jeśli jednak implementacja urządzenia obejmuje obsługę nielimitowanego połączenia danych, takiego jak 802.11 lub profil Bluetooth PAN (Personal Area Network), musi obsługiwać pobieranie OTA z możliwością aktualizacji offline przez ponowne uruchomienie.

Używany mechanizm aktualizacji MUSI obsługiwać aktualizacje bez kasowania danych użytkownika. Oznacza to, że mechanizm aktualizacji MUSI zachowywać prywatne i udostępnione dane aplikacji. Pamiętaj, że oprogramowanie Androida na poziomie dostawcy zawiera mechanizm aktualizacji, który spełnia ten wymóg.

W przypadku implementacji urządzeń z Androidem 6.0 lub nowszym mechanizm aktualizacji POWINIEN obsługiwać weryfikację, czy obraz systemu jest identyczny z oczekiwanym wynikiem po aktualizacji OTA. Implementacja OTA na podstawie bloków w ramach projektu źródłowego Android Open Source, dodanego w Androidzie 5.1, spełnia ten wymóg.

Implementacje urządzeń powinny też obsługiwać aktualizacje systemu A/B . AOSP wdraża tę funkcję za pomocą interfejsu HAL sterowania uruchamianiem.

Jeśli po wydaniu urządzenia, ale w ramach jego rozsądnego okresu użytkowania, który został określony w konsultacji z zespołem ds. zgodności Androida, zostanie znaleziony błąd wpływający na zgodność aplikacji innych firm, implementator urządzenia MUSI naprawić ten błąd, wprowadzając aktualizację oprogramowania, którą można zastosować zgodnie z omówionym mechanizmem.

Android zawiera funkcje, które umożliwiają aplikacji Właściciel urządzenia (jeśli jest dostępna) kontrolowanie instalacji aktualizacji systemu. Aby to umożliwić, podsystem aktualizacji systemu na urządzeniach, które zgłaszają android.software.device_admin, MUSI implementować zachowanie opisane w klasie SystemUpdatePolicy.

12. Historia zmian dokumentu

Aby uzyskać podsumowanie zmian w definicji zgodności w tej wersji:

• Zmiany w dokumentacji

Podsumowanie zmian w poszczególnych sekcjach:

1. Wprowadzenie
2. Typy urządzeń
3. Oprogramowanie
4. Opakowanie aplikacji
5. Multimedia
6. Narzędzia i opcje dla programistów
7. Zgodność sprzętowa
8. Wydajność i moc
9. Model zabezpieczeń
10. testy zgodności oprogramowania,
11. Oprogramowanie z możliwością aktualizacji
12. Historia zmian dokumentu
13. Skontaktuj się z nami

12.1. Wskazówki dotyczące wyświetlania historii zmian

Zmiany są oznaczone w ten sposób:

• CDD
  Znaczne zmiany wymagań dotyczących zgodności.

• Dokumenty
  Zmiany kosmetyczne lub związane z kompilacją.

Aby zapewnić najlepszą widoczność, dodaj parametry adresu URL pretty=full i no-merges do adresów URL strony z informacjami o zmianach.

13. Skontaktuj się z nami

Możesz dołączyć do forum dotyczącego zgodności z Androidem i poprosić o wyjaśnienia lub zgłosić problemy, które Twoim zdaniem nie zostały opisane w dokumencie.