Definicja zgodności z Androidem 4.3

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Wersja 1
Ostatnia aktualizacja: 23 lipca 2013 r.

Copyright © 2013 Google Inc. Wszelkie prawa zastrzeżone.
compatibility@android.com

Spis treści

1. Wprowadzenie

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

Użycie słów „must” (musi), „must not” (nie musi), „required” (wymagane), „shall” (powinien), „shall not” (nie powinien), „should” (powinien), „should not” (nie powinien), „recommended” (zalecane), „may” (można) i „optional” (opcjonalnie) jest zgodne ze standardem IETF zdefiniowanym w specyfikacji RFC2119 [Resources, 1].

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

Aby można było uznać implementację urządzenia za zgodną z Androidem 4.3, musi ona spełniać wymagania podane w tej definicji zgodności, w tym wszelkie dokumenty uwzględnione w dokumentacji.

Jeśli definicja lub testy oprogramowania opisane w sekcji 10 są niejasne, niepełne lub nieprecyzyjne, implementator urządzenia jest odpowiedzialny za zapewnienie zgodności z dotychczasowymi implementacjami.

Z tego powodu projekt Android Open Source [Zasoby, 3] jest zarówno referencją, jak i preferowaną implementacją Androida. W jak największym stopniu zalecamy, aby implementacje były oparte na „upstreamowym” kodzie źródłowym dostępnym w ramach Projektu Android Open Source. Chociaż teoretycznie niektóre komponenty można zastąpić innymi implementacjami, zdecydowanie odradzamy to robić, ponieważ znacznie utrudni to przejście testów oprogramowania. Obowiązkiem implementatora jest zapewnienie pełnej zgodności z zachowaniem standardowej implementacji Androida, w tym w ramach pakietu Compatibility Test Suite i poza nim. Pamiętaj, że niektóre zamiany i modyfikacje komponentów są wyraźnie zabronione w tym dokumencie.

2. Materiały

1. Poziomy wymagań IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
2. Omówienie programu zgodności z Androidem: http://source.android.com/docs/compatibility/index.html
3. Projekt Android Open Source: http://source.android.com/
4. Definicje i dokumentacja interfejsu API: http://developer.android.com/reference/packages.html
5. Informacje o uprawnieniach na Androida: http://developer.android.com/reference/android/Manifest.permission.html
6. Informacje o android.os.Build: http://developer.android.com/reference/android/os/Build.html
7. Dozwolone ciągi znaków wersji Androida 4.3: http://source.android.com/docs/compatibility/4.3/versions.html
8. Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html
9. Sprzętowa akceleracja: http://developer.android.com/guide/topics/graphics/hardware-accel.html
10. Klasa android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12. Funkcje offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13. Tag wideo HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14. Interfejs API geolokalizacji HTML5/W3C: http://www.w3.org/TR/geolocation-API/
15. Webdatabase API HTML5/W3C: http://www.w3.org/TR/webdatabase/
16. Interfejs API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/
17. Specyfikacja maszyny wirtualnej Dalvik: dostępna w kodzie źródłowym Androida w folderze dalvik/docs.
18. Widgety aplikacji: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19. Powiadomienia: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20. Zasoby aplikacji: http://code.google.com/android/reference/available-resources.html
21. Przewodnik po stylu ikon na pasku stanu: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22. Menedżer wyszukiwania: http://developer.android.com/reference/android/app/SearchManager.html.
23. Toasty: http://developer.android.com/reference/android/widget/Toast.html
24. Motywy: http://developer.android.com/guide/topics/ui/themes.html
25. Klasa R.style: http://developer.android.com/reference/android/R.style.html
26. Animowane tapety: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
27. Administracja urządzenia z Androidem: http://developer.android.com/guide/topics/admin/device-admin.html
28. Informacje o DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29. Interfejsy API usługi dostępności Androida: http://developer.android.com/reference/android/accessibilityservice/package-summary.html
30. Interfejsy API dostępności Androida: http://developer.android.com/reference/android/view/accessibility/package-summary.html
31. Projekt Eyes Free: http://code.google.com/p/eyes-free
32. Interfejsy Text-To-Speech API: http://developer.android.com/reference/android/speech/tts/package-summary.html
33. dokumentacja narzędzi (dla adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html
34. Opis pliku APK na Androida: http://developer.android.com/guide/topics/fundamentals.html
35. Pliki manifestu: http://developer.android.com/guide/topics/manifest/manifest-intro.html
36. Narzędzie do testowania Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
37. Klasa android.content.pm.PackageManager i lista funkcji sprzętowych: http://developer.android.com/reference/android/content/pm/PackageManager.html
38. Obsługa wielu ekranów: http://developer.android.com/guide/practices/screens_support.html
39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
40. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
41. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
42. Interfejs Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html
43. NDEF Push Protocol: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
44. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
49. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
50. Interfejs API orientacji aparatu: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51. Aparat: http://developer.android.com/reference/android/hardware/Camera.html
52. Akcesoria Open Accessories na Androida: http://developer.android.com/guide/topics/usb/accessory.html.
53. Interfejs USB Host API: http://developer.android.com/guide/topics/usb/host.html
54. Informacje o bezpieczeństwie i uprawnieniach w Androidzie: http://developer.android.com/guide/topics/security/security.html
55. Aplikacje na Androida: http://code.google.com/p/apps-for-android
56. Menedżer pobierania Androida: http://developer.android.com/reference/android/app/DownloadManager.html
57. Android File Transfer: http://www.android.com/filetransfer
58. Formaty multimediów na Androidzie: http://developer.android.com/guide/appendix/media-formats.html
59. Projekt protokołu HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
60. Przekazywanie połączenia NFC: http://www.nfc-forum.org/specs/spec_list/#conn_handover
61. Bezpieczne parowanie Bluetooth za pomocą NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62. Interfejs API multicastu Wi-Fi: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
63. Asystent działań: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64. Specyfikacja ładowania przez USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65. Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66. Dźwięk przez USB na Androidzie: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67. Ustawienia udostępniania NFC na Androidzie: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68. Wifi Direct (Wifi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69. Widżet ekranu blokady i ekranu głównego: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html
70. Informacje o klasie UserManager: http://developer.android.com/reference/android/os/UserManager.html
71. Informacje o pamięci zewnętrznej: https://source.android.com/docs/core/storage
72. Interfejsy API zewnętrznego magazynu: http://developer.android.com/reference/android/os/Environment.html
73. Krótki kod SMS-a: http://en.wikipedia.org/wiki/Short_code
74. Klient zdalnego sterowania multimediami: http://developer.android.com/reference/android/media/RemoteControlClient.html
75. Menedżer wyświetlacza: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
76. Marzenia: http://developer.android.com/reference/android/service/dreams/DreamService.html
77. Ustawienia związane z rozwojem aplikacji na Androida: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS
78. Aparat: http://developer.android.com/reference/android/hardware/Camera.Parameters.html
79. Rozszerzenie EGL EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt
80. Interfejs API Motion Event: http://developer.android.com/reference/android/view/MotionEvent.html
81. Konfiguracja dotykowego wejścia: http://source.android.com/docs/core/interaction/input/touch-devices.html

Wiele z tych zasobów pochodzi bezpośrednio lub pośrednio z Androida 4.3 SDK i będzie funkcjonalnie identyczne z informacjami w dokumentacji tego pakietu SDK. W każdym przypadku, gdy dokument definicji zgodności lub pakiet Compatibility Test Suite są niezgodne z dokumentacją pakietu SDK, decydująca jest dokumentacja pakietu SDK. Wszelkie szczegóły techniczne podane w wymienionych powyżej dokumentach są uznawane za część tej Definicji zgodności.

3. Oprogramowanie

3.1. Zgodność z zarządzanym interfejsem API

Zarządzane środowisko wykonawcze (oparte na Dalviku) jest głównym narzędziem do uruchamiania aplikacji na Androida. Interfejs programowania aplikacji (API) Androida to zbiór interfejsów platformy Androida udostępnionych aplikacjom działającym w zarządzanym środowisku maszyny wirtualnej. Implementacje na urządzeniu MUSZĄ zawierać kompletne implementacje, w tym wszystkie udokumentowane zachowania, interfejsów API opisanych w pakiecie SDK Androida 4.3 [Zasoby, 4].

Implementacje na urządzeniach NIE MOGĄ pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów API ani ich podpisów, odbiegać od udokumentowanego zachowania lub zawierać operacji niemających żadnego działania, 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. Szczegółowe wymagania dotyczące tego scenariusza znajdziesz w sekcji 7.

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

Oprócz zarządzanych interfejsów API wymienionych w sekcji 3.1 Android zawiera też istotne „miękkie” interfejsy API używane tylko w czasie wykonywania, takie jak intencje, uprawnienia i inne aspekty 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 informacjami na stronie referencyjnej dotyczącej uprawnień [Materiały, 5]. Pamiętaj, że w sekcji 9 wymieniono dodatkowe wymagania dotyczące modelu zabezpieczeń Androida.

3.2.2. Parametry tworzenia

Interfejsy API Androida zawierają kilka stałych wartości w klasie android.os.Build[Resources, 6], które mają opisywać bieżące urządzenie. Aby zapewnić spójne i znaczeniowe wartości we wszystkich implementacjach urządzeń, w tabeli poniżej znajdziesz dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi implementacje urządzeń MUSZĄ być zgodne.

Parametr	Komentarze
android.os.Build.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 [Resources, 7].
android.os.Build.VERSION.SDK	Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 4.3 to pole MUSI zawierać wartość całkowitą 18.
android.os.Build.VERSION.SDK_INT	Wersja aktualnie działającego systemu Android w formacie dostępnym dla kodu aplikacji innych firm. W przypadku Androida 4.3 to pole MUSI zawierać wartość całkowitą 18.
android.os.Build.VERSION.INCREMENTAL	Wartość wybrana przez implementatora urządzenia, która określa wersję bieżąco działającego systemu Android w czytelnym dla człowieka formacie. Tej wartości NIE MOŻNA używać ponownie w przypadku różnych wersji udostępnionych użytkownikom. Typowym zastosowaniem tego pola jest wskazanie, który numer kompilacji lub identyfikator zmiany w kontroli źródłowej posłużył do wygenerowania kompilacji. 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 („"”).
android.os.Build.BOARD	Wartość wybrana przez implementatora urządzenia, która identyfikuje konkretny wewnętrzny sprzęt 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 zgodna z wyrażeniem regularnym "^[a-zA-Z0-9.,_-]+$".
android.os.Build.BRAND	Wartość wybrana przez implementatora urządzenia, która identyfikuje nazwę firmy, organizacji, osoby itp., która wyprodukowała urządzenie, w formacie zrozumiałym dla człowieka. To pole można wykorzystać do wskazania OEM-a lub operatora, który sprzedał urządzenie. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego "^[a-zA-Z0-9.,_-]+$".
android.os.Build.CPU_ABI	Nazwa zestawu instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3: Zgodność z interfejsem API natywnej aplikacji.
android.os.Build.CPU_ABI2	Nazwa drugiej grupy instrukcji (typ procesora + konwencja ABI) kodu natywnego. Zobacz sekcję 3.3: Zgodność z interfejsem API natywnej aplikacji.
android.os.Build.DEVICE	Wartość wybrana przez implementatora urządzenia, która identyfikuje konkretną konfigurację lub wersję obudowy (czasami nazywaną „wzornictwem przemysłowym”) urządzenia. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego "^[a-zA-Z0-9.,_-]+$".
android.os.Build.FINGERPRINT	Ciąg znaków jednoznacznie identyfikujący tę kompilację. Powinien być w rozsądnym stopniu czytelny dla człowieka. Musi on być zgodny z tym szablonem: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Na przykład: acme/mydevice/generic:4.3/JRN53/3359:userdebug/test-keys Odcisk palca NIE może zawierać znaków odstępu. Jeśli inne pola w powyższym szablonie zawierają znaki odstępu, należy je zastąpić w pliku danych o budowaniu pliku danych o odciskach palców innym znakiem, np. podkreśleniem („_”). Wartość tego pola MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII.
android.os.Build.HARDWARE	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.,_-]+$".
android.os.Build.HOST	Ciąg znaków, który w czytelnym dla człowieka formacie jednoznacznie identyfikuje hosta, na którym została utworzona kompilacja. Nie ma żadnych wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono być puste ani nie może zawierać pustego ciągu znaków („”).
android.os.Build.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 istotną, aby użytkownicy mogli odróżnić różne wersje oprogramowania. Wartość w tym polu MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym "^[a-zA-Z0-9.,_-]+$".
android.os.Build.MANUFACTURER	Nazwa handlowa producenta oryginalnego sprzętu (OEM) produktu. Nie ma żadnych wymagań dotyczących formatu tego pola, z tym wyjątkiem, że: NIE MOŻE być ono puste ani zawierać pustego ciągu znaków („"”).
android.os.Build.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 użytkownikom. 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 („"").
android.os.Build.PRODUCT	Wartość wybrana przez implementatora urządzenia zawierająca nazwę rozwojową lub nazwę kodową produktu (SKU). MUSI być zrozumiała dla człowieka, ale nie musi być przeznaczona do wyświetlania użytkownikom. Wartość tego pola MUSI być możliwa do zakodowania w postaci 7-bitowego ASCII i musi być zgodna z wyrażeniem regularnym "^[a-zA-Z0-9.,_-]+$".
android.os.Build.SERIAL	numer seryjny sprzętu (jeśli jest dostępny). Wartość tego pola MUSI być kodowalna w postaci 7-bitowego ASCII i pasować do wyrażenia regularnego "^([a-zA-Z0-9]{0,20})$".
android.os.Build.TAGS	Lista tagów wybranych przez implementatora urządzenia, rozdzielona przecinkami, która dodatkowo rozróżnia kompilację. Na przykład „unsigned,debug”. Wartość w tym polu MUSI być możliwa do zakodowania jako 7-bitowy kod ASCII i musi być zgodna z wyrażeniem regularnym "^[a-zA-Z0-9.,_-]+$".
android.os.Build.TIME	Wartość reprezentująca sygnaturę czasową utworzenia kompilacji.
android.os.Build.TYPE	Wartość wybrana przez implementatora urządzenia określająca konfigurację środowiska wykonawczego kompilacji. To pole MUSI zawierać jedną z wartości odpowiadających 3 typowym konfiguracjom środowiska uruchomieniowego Androida: „user”, „userdebug” lub „eng”. Wartość tego pola MUSI być kodowalna jako 7-bitowy kod ASCII i pasować do wyrażenia regularnego "^[a-zA-Z0-9.,_-]+$".
android.os.Build.USER	Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował kompilację. Nie ma żadnych wymagań dotyczących formatu tego pola, z tym wyjątkiem, że NIE MOŻE być ono puste ani nie może zawierać pustego ciągu znaków („"").

3.2.3. Zgodność z zamiarem

Implementacje na urządzeniach MUSZĄ uwzględniać system intencji o luźnym powiązaniu w Androidzie, jak opisano w sekcjach poniżej. „Spełnianie” oznacza, że implementator urządzenia MUSI udostępnić aktywność lub usługę na Androida, która określa pasujący filtr intencji oraz wiąże się z każdym określonym wzorcem intencji i wdraża odpowiednie zachowanie.

3.2.3.1. Główne intencje aplikacji

Projekt Android upstream definiuje kilka podstawowych aplikacji, takich jak kontakty, kalendarz, galeria zdjęć, odtwarzacz muzyki itp. Implementatorzy urządzeń MOGĄ zastąpić te aplikacje ich alternatywnymi wersjami.

Jednak takie alternatywne wersje MUSZĄ przestrzegać tych samych wzorów intencji, które są dostarczane przez projekt źródłowy. Jeśli na przykład urządzenie ma alternatywny odtwarzacz muzyki, nadal musi obsługiwać wzór intencji wydawany przez aplikacje innych firm, aby wybrać utwór.

Te aplikacje są uważane za podstawowe aplikacje systemu Android:

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

Główne aplikacje systemu Android zawierają różne komponenty Activity lub Service, które są uważane za „publiczne”. Oznacza to, że atrybut „android:exported” może być nieobecny lub mieć wartość „true”.

W przypadku każdej aktywności lub usługi zdefiniowanej w jednej z podstawowych aplikacji systemowych Androida, która nie jest oznaczona jako prywatna za pomocą atrybutu android:exported o wartości „false”, implementacje na urządzeniu MUSZĄ zawierać komponent tego samego typu, który wdraża te same wzorce filtra intencji co podstawowa aplikacja systemowa Androida.

Innymi słowy, implementacja urządzenia MOŻE zastąpić podstawowe aplikacje systemowe Androida, ale jeśli tak się stanie, implementacja urządzenia MUSI obsługiwać wszystkie wzorce intencji zdefiniowane przez każdą podstawową aplikację systemową Androida, która zostanie zastąpiona.

3.2.3.2. Zastąpienia intencji

Ponieważ Android jest platformą rozszerzalną, implementacje urządzeń MUSZĄ umożliwiać zastąpienie każdego wzorca Intent, o którym mowa w sekcji 3.2.3.2, przez aplikacje innych firm. W ramach implementacji open source Androida jest to domyślnie dozwolone. Implementatorzy urządzeń NIE MOGĄ przypisywać 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 między innymi wyłączenie interfejsu „Selektor”, który umożliwia użytkownikowi wybór spośród kilku aplikacji, które obsługują ten sam wzór intencji.

Implementacje urządzeń MOGĄ jednak udostępniać domyślne czynności dla określonych wzorów identyfikatorów URI (np. http://play.google.com), jeśli domyślna czynność zapewnia bardziej szczegółowy filtr dla identyfikatora URI danych. Na przykład filtr intencji określający URI danych „http://www.android.com” jest bardziej szczegółowy niż filtr przeglądarki dla „http://”. Implementacje urządzeń MUSZĄ zawierać interfejs użytkownika umożliwiający modyfikowanie domyślnej aktywności dla intencji.

3.2.3.3. Przestrzenie nazw intencji

Implementacje urządzeń NIE MOGĄ zawierać żadnego komponentu Androida, który obsługuje nowe wzorce intencji lub intencji rozgłoszeniowych za pomocą działania, kategorii ani 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 wzorce intencji lub rozgłaszania intencji, używając akcji, kategorii lub innego kluczowego ciągu 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 korzystają z przestrzeni nazw wyraźnie i wyraźnie powiązanych z własną organizacją.

Ten zakaz jest analogiczny do zakazu określonego w sekcji 3.6 dotyczącego klas języka Java.

3.2.3.4. Zamiary związane z transmisją

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

3.3. Zgodność z natywnym interfejsem API

3.3.1 Interfejsy binarne aplikacji

Kod zarządzany działający w Dalviku może wywoływać kod natywny dostarczony w pliku aplikacji .apk jako plik .so ELF skompilowany dla odpowiedniej architektury sprzętowej urządzenia. Ponieważ kod natywny jest silnie zależny od podstawowej technologii procesora, Android definiuje w Android NDK w pliku docs/CPU-ARCH-ABIS.html kilka interfejsów binarnych aplikacji (ABI). Jeśli implementacja na urządzeniu jest zgodna z co najmniej 1 zdefiniowanym ABI, powinna być zgodna 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 za pomocą standardowej semanttyki 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.
• NALEŻY dokładnie podać natywny interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie za pomocą interfejsu API android.os.Build.CPU_ABI.
• NALEŻY zgłaszać tylko te ABI, które są udokumentowane w najnowszej wersji Android NDK w pliku docs/CPU-ARCH-ABIS.txt
• NALEŻY go skompilować, używając kodu źródłowego i plików nagłówkowych dostępnych w upstreamowym projekcie Android Open Source.

Te interfejsy API natywnego kodu MUSZĄ być dostępne dla aplikacji, które zawierają kod natywny:

• libc (biblioteka C)
• libm (biblioteka matematyczna)
• Minimalne wsparcie dla C++
• Interfejs JNI
• liblog (rejestrowanie na Androidzie)
• libz (kompresja Zlib)
• libdl (linker dynamiczny)
• libGLESv1_CM.so (OpenGL ES 1.0)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.0)
• libEGL.so (własne zarządzanie powierzchnią OpenGL)
• libjnigraphics.so
• libOpenSLES.so (obsługa dźwięku OpenSL ES 1.0.1)
• libOpenMAXAL.so (obsługa OpenMAX AL 1.0.1)
• libandroid.so (obsługa natywnej aktywności Androida)
• Obsługa OpenGL, jak opisano poniżej

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

Pamiętaj, że implementacje na urządzeniu MUSZĄ zawierać plik libGLESv3.so i MUSZĄ mieć symboliczny link (symbolic) do pliku libGLESv2.so. W przypadku implementacji na urządzeniu, które deklarują obsługę OpenGL ES 3.0, plik libGLESv2.so MUSI eksportować symbole funkcji OpenGL ES 3.0 oprócz symboli funkcji OpenGL ES 2.0.

Zgodność kodu natywnego jest trudna do osiągnięcia. Dlatego należy pamiętać, że implementatorzy urządzeń powinni bardzo mocno zachęcać do korzystania z implementacji bibliotek wymienionych powyżej, aby zapewnić zgodność.

3.4. Zgodność z przeglądarką

3.4.1. Zgodność WebView

Implementacja Androida Open Source korzysta z silnika renderowania WebKit do implementowania android.webkit.WebView [Resources, 10] . Ponieważ niemożliwe jest opracowanie kompleksowego zestawu testów dla systemu renderowania stron internetowych, implementatorzy urządzeń MUSZĄ używać określonej wersji WebKit w ramach implementacji WebView. Więcej szczegółów:

• Implementacje android.webkit.WebView na urządzeniach MUSZĄ być oparte na kompilacji WebKit 534.30 z gałęzi źródłowej Android Open Source na Androida 4.3. Ta kompilacja zawiera określony zestaw funkcji i poprawek zabezpieczeń dla WebView. Implementatorzy urządzeń MOGĄ dostosować implementację WebKit, ale wszelkie takie modyfikacje NIE MOGĄ zmieniać działania WebView, w tym renderowania.
• Ciąg znaków klienta użytkownika przesyłany przez WebView musi mieć format:
  Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
  • Wartość ciągu znaków $(VERSION) MUSI być taka sama jak wartość parametru android.os.Build.VERSION.RELEASE.
  • Wartość ciągu tekstowego $(LOCALE) powinna być zgodna z konwencjami ISO dotyczącymi kodu kraju i języka oraz odnosić się do aktualnie skonfigurowanej lokalizacji urządzenia.
  • Wartość ciągu znaków $(MODEL) MUSI być taka sama jak wartość android.os.Build.MODEL
  • Wartość ciągu znaków $(BUILD) MUSI być taka sama jak wartość parametru android.os.Build.ID.
  • Implementacje urządzeń MOGĄ pomijać Mobile w ciągu znaków klienta użytkownika

Komponent WebView powinien obsługiwać jak najwięcej funkcji HTML5 [Resources, 11]. Implementacje na urządzeniach MUSZĄ obsługiwać co najmniej te interfejsy API związane z HTML5 w WebView:

• pamięć podręczna aplikacji/działanie offline [Resources, 12]
• tag <video> [Materiały, 13]
• geolokalizacja [Resources, 14]

Implementacje na urządzeniach MUSZĄ obsługiwać interfejs API webstorage HTML5/W3C [Resources, 15] i POWINNY obsługiwać interfejs API IndexedDB HTML5/W3C [Resources, 16]. Pamiętaj, że organizacje opracowujące standardy w zakresie tworzenia stron internetowych przechodzą na IndexedDB zamiast webstorage, dlatego IndexedDB ma stać się wymaganym komponentem w przyszłej wersji Androida.

Interfejsy API HTML5, podobnie jak wszystkie interfejsy API JavaScriptu, muszą być domyślnie wyłączone w komponencie WebView, chyba że deweloper wyraźnie je włączy za pomocą zwykłych interfejsów API Androida.

3.4.2. Zgodność z przeglądarką

Wdrożenia na urządzeniach MUSZĄ zawierać samodzielną aplikację przeglądarki do ogólnego przeglądania internetu przez użytkownika. Samodzielna przeglądarka MOŻE być o zasadzie oparte na technologii przeglądarki innej 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.

Implementacje mogą zawierać niestandardowy ciąg znaków klienta użytkownika w samodzielnej aplikacji przeglądarki.

Samodzielna aplikacja przeglądarki (oparta na aplikacji WebKit Browser lub na zamienniku od zewnętrznego dostawcy) POWINNA obsługiwać jak najwięcej funkcji HTML5 [Zasoby, 11]. Implementacje na urządzeniach MUSZĄ obsługiwać co najmniej te interfejsy API związane z HTML5:

• pamięć podręczna aplikacji/działanie offline [Resources, 12]
• tag <video> [Materiały, 13]
• geolokalizacja [Resources, 14]

Implementacje na urządzeniach MUSZĄ obsługiwać interfejs API webstorage HTML5/W3C [Resources, 15] i POWINNY obsługiwać interfejs API IndexedDB HTML5/W3C [Resources, 16]. Pamiętaj, że organizacje opracowujące standardy w zakresie tworzenia stron internetowych przechodzą na IndexedDB zamiast webstorage, 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ą projektu Open Source Android [Resources, 3]. Oto niektóre obszary zgodności:

• 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 wszystkich. Implementator jest odpowiedzialny za zapewnienie zgodności behawioralnej z Android Open Source Project. Dlatego implementatorzy urządzeń powinni w miarę możliwości korzystać z kodu źródłowego dostępnego w ramach projektu Android Open Source, a nie ponownie implementować 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 tych przestrzeniach nazw pakietów:

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

Zakazane modyfikacje:

• Implementacje na urządzeniu NIE MOGĄ modyfikować publicznie udostępnionych interfejsów API na platformie Androida przez zmianę sygnatur metod lub klas albo usunięcie klas lub pól klas.
• Implementatorzy urządzeń MOGĄ modyfikować implementację interfejsów API, ale takie modyfikacje NIE MOGĄ wpływać na opisane zachowanie i podpis w języku Java interfejsów API udostępnionych publicznie.
• Implementatorzy urządzeń NIE MOGĄ dodawać do interfejsów API żadnych publicznie dostępnych elementów (takich jak klasy, interfejsy, pola czy 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 górnym 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ą wprowadzić zmiany przeznaczone tylko do użytku wewnętrznego, ale te zmiany 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 lub nawiązującej do niej. 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 obszaru nazw Androida, muszą one zostać zapakowane w bibliotece współdzielonej Androida, aby tylko aplikacje, które z nich wyraźnie korzystają (za pomocą mechanizmu <uses-library>), były objęte zwiększonym zużyciem pamięci przez te interfejsy API.

Jeśli implementator urządzenia zamierza ulepszyć jeden 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 wzmocnienie tych konwencji i uznanie ich za wiążące poprzez uwzględnienie w tej definicji zgodności.

3.7. Zgodność maszyny wirtualnej

Implementacje na urządzeniu MUSZĄ obsługiwać pełną specyfikację bajtkodów Dalvik Executable (DEX) i semantykę maszyny wirtualnej Dalvik [Resources, 17].

Implementacje na urządzeniu MUSZĄ skonfigurować Dalvik w taki sposób, aby przydzielał pamięć zgodnie z platformą Androida na wyższym poziomie i zgodnie z tabelą 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ń MOGĄ przydzielić więcej pamięci na aplikację.

Rozmiar ekranu	Gęstość ekranu	Pamięć aplikacji
małe / normalne / duże	ldpi / mdpi	16 MB
małe / normalne / duże	tvdpi / hdpi	32 MB
małe / normalne / duże	xhdpi	64 MB
bardzo duża	mdpi	32 MB
bardzo duża	tvdpi / hdpi	64 MB
bardzo duża	xhdpi	128 MB

3.8. Zgodność interfejsu

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

Android 4.3 zawiera aplikację uruchamiającą (ekran główny) oraz obsługę aplikacji innych firm, które mogą zastąpić aplikację uruchamiającą (ekran główny) urządzenia. Implementacje urządzeń, które umożliwiają aplikacjom innych firm zastąpienie ekranu głównego urządzenia, 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 użytkownikowi „widżetu aplikacji” [Zasoby, 18]. 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 funkcje obsługi 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 SDK na Androida (Zasoby, 18).
• Implementacje urządzeń, które obejmują obsługę ekranu blokady, MUSZĄ obsługiwać widżety aplikacji na ekranie blokady.

3.8.3. Powiadomienia

Android zawiera interfejsy API, które umożliwiają programistom powiadamianie użytkowników o istotnych wydarzeniach [Zasoby, 19] za pomocą funkcji sprzętowych i programowych urządzenia.

Niektóre interfejsy API umożliwiają aplikacjom wysyłanie 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 dokumentacją pakietu SDK oraz w takim zakresie, w jaki jest to możliwe w ramach sprzętu implementacji urządzenia. Jeśli na przykład implementacja urządzenia zawiera wibrator, MUSI prawidłowo implementować interfejsy API wibracji. Jeśli implementacja urządzenia nie zawiera sprzętu, odpowiednie interfejsy API MUSZĄ być zaimplementowane jako no-ops. Więcej informacji o takim zachowaniu znajdziesz w sekcji 7.

Ponadto implementacja MUSI prawidłowo renderować wszystkie zasoby (ikony, pliki dźwiękowe itp.) udostępnione w interfejsach API [Zasoby, 20] lub w przewodniku po stylu ikon w pasku stanu/systemowym [Zasoby, 21]. Implementatorzy urządzeń MOGĄ zapewnić użytkownikom inne powiadomienia niż te dostępne w referencyjnej implementacji Androida w wersji open source. Jednak takie alternatywne systemy powiadomień MUSZĄ obsługiwać istniejące zasoby powiadomień, jak opisano powyżej.

Android 4.3 obsługuje powiadomienia rozszerzone, takie jak interaktywne karty w przypadku powiadomień ciągłych. Implementacje na urządzeniach MUSZĄ prawidłowo wyświetlać i wykonywać powiadomienia multimedialne zgodnie z dokumentacją interfejsów API Androida.

3.8.4. Szukaj

Android zawiera interfejsy API [Resources, 22], które umożliwiają deweloperom dodawanie wyszukiwarki do aplikacji oraz udostępnianie danych aplikacji w globalnym wyszukiwaniu systemowym. Ogólnie rzecz biorąc, ta funkcja składa się z jednego interfejsu użytkownika obejmującego cały system, który umożliwia użytkownikom wpisywanie zapytań, wyświetlanie sugestii podczas wpisywania oraz 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ądzeniu MUSZĄ zawierać jeden wspólny interfejs użytkownika wyszukiwarki, który umożliwia wyświetlanie sugestii w czasie rzeczywistym w odpowiedzi na dane wejściowe użytkownika. Implementacje urządzeń MUSZĄ zawierać interfejsy API, które umożliwiają deweloperom ponowne użycie tego interfejsu użytkownika w celu udostępnienia wyszukiwania w ich własnych aplikacjach. Implementacje na urządzeniach 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, które korzystają z tej funkcji, domyślnie powinny być wyświetlane wyniki wyszukiwania w wyszukiwarce internetowej oraz sugestie.

3.8.5. Toasty

Aplikacje mogą używać interfejsu Toast API (zdefiniowanego w [Zasoby, 23]) do wyświetlania użytkownikowi krótkich niemodalnych ciągów znaków, które znikają po krótkim czasie. Implementacje na urządzeniach MUSZĄ wyświetlać komunikaty typu Toast aplikacji dla użytkowników w sposób dobrze widoczny.

3.8.6. Motywy

Android udostępnia „motywy” jako mechanizm umożliwiający aplikacjom stosowanie stylów w całym komponencie lub aplikacji. Android 4.3 zawiera motyw „Holo” lub „holograficzny” jako zestaw zdefiniowanych stylów, których deweloperzy aplikacji mogą używać, jeśli chcą dopasować wygląd i wrażenia do motywu Holo zdefiniowanego w Android SDK [Zasoby, 24]. Implementacje na urządzeniach NIE MOGĄ zmieniać żadnych atrybutów motywu Holo udostępnianych aplikacjom ([Zasoby, 25]).

Android 4.3 zawiera nowy motyw „Domyślny motyw urządzenia” jako zestaw zdefiniowanych stylów, z których deweloperzy aplikacji mogą korzystać, jeśli chcą dopasować wygląd i wrażenia do motywu urządzenia zdefiniowanego przez implementatora urządzenia. Implementacje na urządzeniu mogą modyfikować atrybuty motywu DeviceDefault udostępniane aplikacjom [Zasoby, 25].

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 „żywej tapety” [Resources, 26]. 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.

Sprzęt jest uznawany za zdolny do niezawodnego wyświetlania tapet na żywo, jeśli może wyświetlać wszystkie tapety na żywo bez ograniczeń funkcjonalności, przy rozsądnej liczbie klatek na sekundę i bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują, że tapety lub aplikacje ulegają awarii, działają nieprawidł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 wyświetlania tapety na żywo. Na przykład niektóre tapety na żywo mogą używać kontekstu Open GL 1.0 lub 2.0 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ż korzystanie z kontekstu OpenGL przez tapetę na żywo może powodować konflikty z innymi aplikacjami, które również korzystają z tego kontekstu.

Urządzenia, które mogą prawidłowo wyświetlać animowane tapety zgodnie z opisem powyżej, POWINNY obsługiwać animowane tapety. Urządzenia, które nie działają zgodnie z opisem powyżej, nie mogą wyświetlać animowanych tapet.

3.8.8. Wyświetlanie ostatnich aplikacji

Kod źródłowy Androida 4.3 zawiera interfejs użytkownika do wyświetlania ostatnich aplikacji za pomocą miniatury stanu graficznego aplikacji w momencie, gdy użytkownik ostatnio ją zamknął. Implementacje na urządzeniu MOGĄ zmienić lub usunąć ten interfejs użytkownika, ale w przyszłej wersji Androida planujemy bardziej rozbudowane wykorzystanie tej funkcji. W przypadku najnowszych aplikacji zdecydowanie zalecamy używanie interfejsu użytkownika z Androida 4.3 (lub podobnego interfejsu opartego na miniaturach) w dółtę do aplikacji, ponieważ w przeciwnym razie mogą one nie być zgodne z przyszłą wersją Androida.

3.8.9. Zarządzanie wejściami

Android 4.3 obsługuje zarządzanie wprowadzaniem danych oraz edytory metod wprowadzania 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 API IME zgodnie z opisem w dokumentacji pakietu Android SDK.

Implementacje urządzeń, które deklarują funkcję android.software.input_methods, MUSZĄ udostępniać użytkownikowi 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

Android 4.3 obsługuje interfejs Remote Control API, który umożliwia aplikacjom multimedialnym integrację z elementami sterowania odtwarzaniem wyświetlanymi w widoku zdalnym, np. na ekranie blokady urządzenia [Zasoby, 74]. Urządzenia, które obsługują ekran blokady i umożliwiają użytkownikom dodawanie widżetów na ekranie głównym, MUSZĄ obsługiwać umieszczanie elementów sterowania na ekranie blokady urządzenia [Zasoby, 69].

3.8.11. Sny

Android 4.3 obsługuje interaktywne wygaszacze ekranu o nazwie Dreams [Resources, 76]. Dreams umożliwia użytkownikom interakcję z aplikacjami, gdy urządzenie jest w stanie bezczynności lub podłączone do stacji dokującej. Implementacje urządzeń MUSZĄ obejmować obsługę Dreams i zapewniać użytkownikom opcję ustawień umożliwiającą konfigurowanie Dreams.

3.9 Administracja urządzeniem

Android 4.3 zawiera funkcje, które umożliwiają aplikacjom z funkcją zabezpieczeń wykonywanie funkcji administracyjnych na poziomie systemu, takich jak egzekwowanie zasad dotyczących haseł czy zdalne kasowanie danych, za pomocą interfejsu API administracji urządzenia z Androidem [Zasoby, 27]. Implementacje na urządzeniu MUSZĄ zawierać implementację klasy DevicePolicyManager [Zasoby, 28]. Implementacje urządzeń, które obejmują obsługę ekranu blokady, MUSZĄ obsługiwać pełny zakres zasad administracyjnych urządzeń zdefiniowanych w dokumentacji Android SDK [Resources, 27].

3.10. Ułatwienia dostępu

Android 4.3 udostępnia warstwę ułatwień dostępu, która ułatwia poruszanie się po urządzeniu użytkownikom z niepełnosprawnością. Dodatkowo Android 4.3 udostępnia interfejsy API platformy, które umożliwiają implementacjom usług ułatwień dostępu otrzymywanie 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ą kulki lub panelu dotykowego [Resources, 29]. Implementacje na urządzeniach MUSZĄ zawierać implementację platformy ułatwień dostępu w Androidzie zgodną z domyślną implementacją Androida. W szczególności implementacje urządzeń MUSZĄ spełniać te wymagania:

• Implementacje urządzeń MUSZĄ obsługiwać implementacje usług dostępności innych firm za pomocą interfejsów API android.accessibilityservice [Resources, 30].
• Implementacje na urządzeniu 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ń MUSZĄ udostępniać użytkownikowi mechanizm włączania i wyłączania usług ułatwień dostępu oraz MUSZĄ wyświetlać ten interfejs w odpowiedzi na intencję android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

Ponadto implementacje na urządzeniu POWINNA zawierać implementację usługi ułatwień dostępu na urządzeniu oraz mechanizm umożliwiający użytkownikom jej włączenie podczas konfiguracji urządzenia. Implementacja usługi ułatwień dostępu typu open source jest dostępna w ramach projektu Eyes Free [Zasoby, 31].

3.11 Zamiana tekstu na mowę

Android 4.3 zawiera interfejsy API, które umożliwiają aplikacjom korzystanie z usług zamiany tekstu na mowę (TTS), a także umożliwia dostawcom usług wdrażanie usług TTS [Zasoby, 32]. Implementacje na urządzeniu MUSZĄ spełniać te wymagania dotyczące mechanizmu TTS na Androida:

• Implementacje na urządzeniu MUSZĄ obsługiwać interfejsy API platformy TTS na Androida i POWINNY 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.
• Implementacje urządzeń MUSZĄ obsługiwać instalację silników TTS innych firm.
• Implementacje na urządzeniu MUSZĄ udostępniać interfejs dostępny dla użytkownika, który umożliwia wybór silnika TTS do użycia na poziomie systemu.

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 [Resources, 33].

Implementacje urządzeń NIE MOGĄ rozszerzać formatów plików .apk [Zasoby, 34], manifestu Androida [Zasoby, 35], kodu bajtowego Dalvik [Zasoby, 17] ani kodu bajtowego renderscript w taki sposób, aby uniemożliwić ich prawidłową instalację i działanie na innych zgodnych urządzeniach. Implementatorzy urządzeń powinni używać referencyjnej implementacji Dalvik na poziomie upstreamu oraz referencyjnego systemu zarządzania pakietami tej implementacji.

5. Zgodność multimedialna

Implementacje urządzeń MUSZĄ zawierać co najmniej 1 formę wyjścia audio, np. głośniki, gniazdo słuchawek, połączenie z głośnikiem zewnętrznym itp.

5.1. Kodeki multimedialne

Implementacje urządzeń MUSZĄ obsługiwać podstawowe formaty multimediów określone w dokumentacji pakietu Android SDK [Resources, 58], z wyjątkiem przypadków, w których jest to wyraźnie dozwolone w tym dokumencie. W szczególności implementacje urządzeń MUSZĄ obsługiwać formaty multimediów, kodery, dekodery, typy plików i formaty kontenerów zdefiniowane w tabelach poniżej. Wszystkie te kodeki są udostępniane jako implementacje oprogramowania w ramach preferowanej implementacji Androida z Android Open Source Project.

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

Pamiętaj, że te tabele nie zawierają konkretnych wymagań dotyczących szybkości transmisji danych w przypadku większości kodeków wideo, ponieważ obecny sprzęt niekoniecznie obsługuje szybkości transmisji danych, które dokładnie odpowiadają wymaganiom określonym w odpowiednich standardach. Zamiast tego implementacje urządzeń POWINNY obsługiwać najwyższą szybkość transmisji bitów, która jest praktyczna w przypadku danego sprzętu, do limitów określonych w specyfikacjach.

Typ	Format / kodek	za pomocą kodera.	Dekoder	Szczegóły	Typy plików/formaty kontenera
Audio	MPEG-4 AAC Profile (AAC LC)	WYMAGANE w przypadku implementacji urządzeń, które zawierają sprzętowy mikrofon i określają android.hardware.microphone.	WYMAGANE	Obsługa treści mono/stereo/5.0/5.1* ze standardową 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 w przypadku implementacji urządzeń, które zawierają sprzęt mikrofonowy i określają android.hardware.microphone	WYMAGANE	Obsługa treści mono/stereo/5.0/5.1* ze standardową częstotliwością próbkowania od 16 do 48 kHz.
	MPEG-4 HE AAC v2 Profile (ulepszona wersja AAC+)		WYMAGANE	Obsługa treści mono/stereo/5.0/5.1* ze standardową częstotliwością próbkowania od 16 do 48 kHz.
	MPEG-4 Audio Object Type ER AAC ELD (Enhanced Low Delay AAC)	WYMAGANE w przypadku implementacji urządzeń, które zawierają sprzęt mikrofonowy i określają android.hardware.microphone	WYMAGANE	Obsługa treści mono lub stereo ze standardową częstotliwością próbkowania od 16 do 48 kHz.
	AMR-NB	WYMAGANE w przypadku implementacji urządzeń, które zawierają sprzętowy mikrofon i określają android.hardware.microphone.	WYMAGANE	4,75–12,2 kb/s próbkowane z częstotliwością 8 kHz	3GPP (.3gp)
	AMR-WB	WYMAGANE w przypadku implementacji urządzeń, które zawierają sprzętowy mikrofon i określają android.hardware.microphone.	WYMAGANE	9 szybkości od 6,60 kb/s do 23,85 kb/s z próbkowaniem 16 kHz	3GPP (.3gp)
	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 zalecamy stosowanie częstotliwości do 44,1 kHz, ponieważ konwerter 48/44,1 kHz nie zawiera filtra dolnoprzepustowego). Zalecamy 16-bitową rozdzielczość. W przypadku 24-bitowej rozdzielczości nie stosuje się ditheringu.	Tylko FLAC (.flac)
	MP3		WYMAGANE	Mono/Stereo 8–320 kb/s CBR lub 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)
	PCM/WAVE	WYMAGANE	WYMAGANE	8-bitowy i 16-bitowy PCM liniowy** (częstotliwości do limitu sprzętowego). Urządzenia MUSZĄ obsługiwać częstotliwości próbkowania dla nieskompresowanego nagrywania PCM z częstotliwościami 8000,16000 i 44100 Hz.	WAVE (.wav)
Obraz	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),
Wideo	H.263	WYMAGANE w przypadku implementacji urządzeń z urządzeniem do rejestrowania obrazu i zdefiniowanymi wartościami android.hardware.camera lub android.hardware.camera.front.	WYMAGANE		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	WYMAGANE w przypadku implementacji urządzeń z urządzeniem do rejestrowania obrazu i zdefiniowanymi wartościami android.hardware.camera lub android.hardware.camera.front.	WYMAGANE	Profil podstawowy (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, tylko dźwięk AAC, nie można przeskakiwać, Android 3.0 lub nowszy)
	MPEG-4 SP		WYMAGANE		3GPP (.3gp)
	VP8	WYMAGANE (Android 4.3 lub nowszy)	WYMAGANE (Android 2.3.3 lub nowszy)		WebM (.webm) i Matroska (.mkv, Android 4.0 i nowsze)***

• *Uwaga: wymagany jest tylko downmix treści 5.0/5.1; nagrywanie lub renderowanie większej liczby niż 2 kanały jest opcjonalne.
• **Uwaga: obowiązkowe jest przechwytywanie 16-bitowego liniowego dźwięku PCM. Przechwytywanie dźwięku w formacie PCM w 8-bitowej linearnej rozdzielczości nie jest wymagane.
• ***Uwaga: implementacje urządzeń powinny obsługiwać zapisywanie plików Matroska WebM.

5.2 Kodowanie wideo

Implementacje urządzeń z Androidem, które mają tylną kamerę i deklarują, android.hardware.camera powinny obsługiwać te profile kodowania wideo H.264:

	SD (niska jakość)	SD (wysoka jakość)	HD (jeśli jest obsługiwane przez sprzęt)
Rozdzielczość wideo	176 x 144 pikseli	480 x 360 pikseli	1280 x 720 pikseli
liczba klatek na sekundę,	12 kl./s	30 klatek/s	30 klatek/s
Szybkość transmisji wideo	56 kb/s	500 kb/s lub więcej	2 Mb/s lub więcej
Kodek audio	AAC-LC	AAC-LC	AAC-LC
Kanały audio	1 (mono)	2 (stereo)	2 (stereo)
Szybkość transmisji dźwięku	24 Kb/s	128 Kb/s	192 kb/s

Implementacje urządzeń z Androidem, które mają tylny aparat i deklarują: android.hardware.camera POWINNA obsługiwać te profile kodowania wideo VP8

	SD (niska jakość)	SD (wysoka jakość)	HD 720p (jeśli jest obsługiwane przez sprzęt)	HD 1080p (jeśli sprzęt obsługuje tę rozdzielczość)
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

5.3. Dekodowanie wideo

Implementacje urządzeń z Androidem POWINNY obsługiwać te profile dekodowania wideo VP8 i H.264.

	SD (niska jakość)	SD (wysoka jakość)	HD 720p (jeśli jest obsługiwane przez sprzęt)	HD 1080p (jeśli sprzęt obsługuje tę rozdzielczość)
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	8 Mb/s	20 Mb/s

5.4. Nagrywanie dźwięku

Gdy aplikacja użyje interfejsu API android.media.AudioRecord, aby rozpocząć nagrywanie strumienia audio, implementacje na urządzeniach, które zawierają sprzęt mikrofonowy i deklarują android.hardware.microphone, MUSZĄ próbkować i nagrywać dźwięk z użyciem tych zachowań:

• Urządzenie POWINNA mieć charakterystyki zbliżone do płaskich charakterystyk amplitudy w zależności od częstotliwości, a precyzyjniej ±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 skali SPL 90 dB przy mikrofonie.
• Całkowite zniekształcenie harmoniczne POWINIEN być mniejszy niż 1% dla 1 kHz przy poziomie wejściowym 90 dB SPL.

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:

• Przetwarzanie redukcji szumów (jeśli występuje) MUSI być wyłączone.
• Automatyczna kontrola wzmocnienia (jeśli jest dostępna) MUSI być wyłączona.

Uwaga: chociaż niektóre z wymienionych powyżej wymagań w przypadku Androida 4.3 są oznaczone jako „NALEŻY”, w definicji zgodności przyszłej wersji te wymagania zostaną zmienione na „NALEŻY”. Oznacza to, że te wymagania są opcjonalne w Androidzie 4.3, ale staną się wymagane w przyszłej wersji. Istniejące i nowe urządzenia z Androidem 4.3 bardzo prosimy o spełnienie tych wymagań w Androidzie 4.3, ponieważ w przeciwnym razie nie będą kompatybilne z Androidem po przejściu na nowszą wersję.

5.5. 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.

Na potrzeby tej sekcji:

• „Opóźnienie wyjścia” to przedział czasu między zapisaniem przez aplikację ramki danych kodowanych w formacie PCM a chwilą, gdy odpowiedni dźwięk może być słyszalny dla zewnętrznego odbiorcy lub obserwowany przez przetwornik.
• „Czas oczekiwania na wyjście po uruchomieniu” to czas oczekiwania na wyjście w przypadku pierwszego obrazu, gdy system wyjścia audio był nieaktywny i wyłączony przed żądaniem.
• „Ciągła latencja wyjściowa” to latencja wyjściowa kolejnych klatek po tym, jak urządzenie już odtwarza dźwięk.
• „Opóźnienie wejścia” to przedział czasu między momentem, w którym zewnętrzny dźwięk jest prezentowany na urządzeniu, a momentem, w którym aplikacja odczytuje odpowiednią ramkę danych kodowanych w formacie PCM.
• „Opóźnienie wejścia po uruchomieniu” to suma utraconego czasu wejścia i opóźnienia wejścia dla pierwszej klatki, gdy system wejścia audio był nieaktywny i wyłączony przed żądaniem.
• „Ciągła latencja wejścia” to latencja wejścia w przypadku kolejnych klatek, gdy urządzenie już rejestruje dźwięk.
• „OpenSL ES PCM buffer queue API” to zestaw interfejsów OpenSL ES związanych z PCM w NDK Androida. Patrz NDK_root/docs/opensles/index.html

Zgodnie z sekcją 5 wszystkie kompatybilne implementacje urządzeń MUSZĄ zawierać co najmniej 1 formę wyjścia audio. Implementacje na urządzeniach powinny spełniać te wymagania dotyczące opóźnienia wyjściowego lub przekraczać je:

• 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

Jeśli implementacja urządzenia spełnia wymagania podane w tym rozdziale, po początkowej kalibracji przy użyciu interfejsu API kolejki bufora OpenSL ES PCM, w przypadku ciągłego opóźnienia wyjścia i opóźnienia wyjścia „na zimno” na co najmniej 1 obsługiwanym urządzeniu wyjściowym dźwięku, może zgłaszać obsługę dźwięku o niskim opóźnieniu, zgłaszając funkcję „android.hardware.audio.low-latency” za pomocą klasy android.content.pm.PackageManager. [Resources, 37] Jeśli implementacja urządzenia nie spełnia tych wymagań, NIE MOŻE zgłaszać obsługi dźwięku o niskiej latencji.

Zgodnie z sekcją 7.2.5 implementacje urządzeń mogą pominąć sprzęt mikrofonu.

Implementacje urządzeń, które zawierają sprzęt mikrofonowy i deklarują android.hardware.microphone, powinny spełniać te wymagania dotyczące opóźnienia 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 50 ms lub mniej,

5.6. Protokoły sieciowe

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

• RTSP (RTP, SDP)
• strumieniowe przesyłanie danych przez HTTP(S) w sposób progresywny;
• Projekt protokołu HTTP(S) do transmisji na żywo, wersja 3 [Resources, 59]

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. W szczególności urządzenia zgodne z Androidem MUSZĄ być zgodne z:

• Android Debug Bridge (ADB) [Resources, 33]
  Implementacje na urządzeniu MUSZĄ obsługiwać wszystkie funkcje adbopisane w pakiecie Android SDK. Demon adb na urządzeniu MUSI być domyślnie nieaktywny. Musi też istnieć mechanizm dostępny dla użytkownika, który umożliwia włączanie mostu debugowania Androida.
• Android 4.3 obsługuje bezpieczne połączenie ADB. Bezpieczny adb włącza adb na znanych uwierzytelnionych hostach. Implementacje urządzeń MUSZĄ obsługiwać bezpieczny interfejs adb.
• Usługa Dalvik Debug Monitor (znana jako ddms) [Zasoby, 33]
  Wdrożone na urządzeniu rozwiązania MUSZĄ obsługiwać wszystkie funkcje ddms zgodnie z dokumentacją 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, jak opisano powyżej.
• Monkey [Zasoby, 36]
  Implementacje na urządzeniach MUSZĄ zawierać platformę Monkey i musi być ona dostępna dla aplikacji.
• SysTrace [Resources, 33]
  Wdrożenia na urządzeniach MUSZĄ obsługiwać narzędzie systrace zgodnie z dokumentacją 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. Jednak systemy Microsoft Windows zwykle wymagają sterownika dla nowych urządzeń z Androidem. (na przykład nowe identyfikatory dostawców i czasami nowe identyfikatory urządzeń wymagają niestandardowych sterowników USB w systemach Windows). Jeśli implementacja urządzenia jest nieznana dla narzędzia adb udostępnianego w standardowym pakiecie SDK Androida, implementatorzy urządzeń MUSZĄ udostępnić sterowniki Windowsa, które umożliwiają deweloperom nawiązywanie połączenia z urządzeniem za pomocą protokołu adb. Te sterowniki MUSZĄ być dostarczone w wersjach 32- i 64-bitowej dla systemów Windows XP, Windows Vista, Windows 7 i Windows 8.

6.2 Opcje programisty

Android 4.3 zawiera obsługę konfigurowania ustawień związanych z tworzeniem aplikacji. Implementacje urządzeń MUSZĄ obsługiwać intencję android.settings.APPLICATION_DEVELOPMENT_SETTINGS, aby wyświetlać ustawienia związane z rozwojem aplikacji [Resources, 77]. W dolnej implementacji Androida menu Opcje dewelopera jest domyślnie ukryte, a użytkownicy mogą je otworzyć po naciśnięciu siedmiu (7) razy pozycji menu 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 zgodny z implementacją w górnym łańcuchu Androida.

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 wdrażać ten interfejs zgodnie z dokumentacją pakietu Android SDK. Jeśli interfejs API w pakiecie SDK współpracuje ze sprzętowym komponentem, który jest oznaczony jako opcjonalny, a urządzenie nie ma tego komponentu:

• muszą być nadal obecne definicje klas (opisane w pakiecie SDK) interfejsów API komponentu;
• zachowanie interfejsu API MUSI być zaimplementowane w taki sposób, aby nie robić nic w żaden sposób;
• 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Ą wywoływać 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 do obsługi połączeń telefonicznych: nawet na urządzeniach innych niż telefony interfejsy API muszą być implementowane jako rozsądne no-ops.

Implementacje urządzeń MUSZĄ prawidłowo raportować dokładne informacje o konfiguracji sprzętowej za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager. [Materiały, 37]

7.1. Wyświetlanie i grafika

Android 4.3 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 [Zasoby, 38]. Urządzenia MUSZĄ prawidłowo wdrażać 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:

• „Wymiary fizyczne przekątnej” to odległość w calach między dwoma przeciwległymi narożnikami podświetlonej części wyświetlacza.
• „dpi” (co oznacza „punkty na cal”) to liczba pikseli zawartych w liniowym zakresie poziomym lub pionowym o długości 1 cala. Jeśli podano wartości dpi, zarówno poziome, jak i pionowy dpi muszą mieścić się w tym zakresie.
• „Format obrazu” to stosunek dłuższego wymiaru ekranu do krótszego. Na przykład wyświetlacz o wymiarach 480 x 854 pikseli będzie miał współczynnik 854 / 480 = 1, 779, czyli mniej więcej „16:9”.
• „Piksel niezależny od gęstości” (czyli „dp”) to jednostka wirtualnych pikseli znormalizowana do ekranu o rozdzielczości 160 dpi, obliczana według wzoru:pixels = dps * (density / 160).

7.1.1. Konfiguracja ekranu

Rozmiar ekranu

Interfejs użytkownika Androida obsługuje różne rozmiary ekranu i pozwala aplikacjom zapytać o rozmiar ekranu urządzenia (czyli „układ ekranu”) za pomocą android.content.res.Configuration.screenLayout z użyciem SCREENLAYOUT_SIZE_MASK. Implementacje urządzeń MUSZĄ zgłaszać prawidłowy rozmiar ekranu zgodnie z definicją w dokumentacji pakietu Android SDK [Resources, 38] i określonym przez platformę Androida. 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ć ekrany o minimalnych wymiarach 426 x 320 dp (małe)
• Urządzenia, które podają rozmiar ekranu „normalny”, MUSZĄ mieć rozmiar ekranu co najmniej 480 x 320 dp
• Urządzenia, które podają rozmiar ekranu „duży”, MUSZĄ mieć rozmiar ekranu co najmniej 640 dp x 480 dp.
• Urządzenia, które podają rozmiar ekranu „xlarge”, MUSZĄ mieć rozmiar ekranu co najmniej 960 x 720 dp

Dodatkowo urządzenia MUSZĄ mieć ekran o fizycznym rozmiarze co najmniej 2, 5 cala w przypadku przekątnej.

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Ą poprawnie obsługiwać deklarowane przez aplikacje ekrany małe, normalne, duże i xlarge zgodnie z opisem w dokumentacji pakietu SDK Androida.

Format obrazu

Format musi się mieścić w zakresie od 1,3333 (4:3) do 1,85 (16:9).

Gęstość ekranu

Interfejs użytkownika Androida definiuje zestaw standardowych gęstości logicznych, aby ułatwić deweloperom aplikacji kierowanie zasobów aplikacji. Implementacje na urządzeniu MUSZĄ zgłaszać jedną z tych logicznych gęstości interfejsu Androida za pomocą interfejsów API android.util.DisplayMetrics i MUSZĄ uruchamiać aplikacje przy tej standardowej gęstości.

• 120 dpi, czyli „ldpi”.
• 160 dpi, czyli „mdpi”
• 213 dpi, znany jako „tvdpi”
• 240 dpi, czyli „hdpi”
• 320 dpi, czyli „xhdpi”
• 480 dpi, czyli „xxhdpi”
• 640 dpi, czyli „xxxhdpi”.

W implementacjach urządzeń NALEŻY 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 jest liczbowo najbliższa fizycznej gęstości, powoduje, że rozmiar ekranu jest mniejszy niż najmniejszy obsługiwany rozmiar ekranu (szerokość 320 dp), implementacje urządzeń powinny zgłaszać następną niżej standardową gęstość ramki Androida.

7.1.2. Dane dotyczące wyświetleń

Implementacje na urządzeniu MUSZĄ przekazywać prawidłowe wartości wszystkich danych wyświetlania zdefiniowanych w android.util.DisplayMetrics [Zasoby, 39].

7.1.3. Orientacja ekranu

Urządzenia MUSZĄ obsługiwać dynamiczną orientację ekranu w aplikacji, aby umożliwić wyświetlanie w orientacji poziomej lub pionowej. Oznacza to, że urządzenie musi uwzględnić prośbę aplikacji o określoną orientację ekranu. Implementacje na urządzeniach mogą domyślnie wybierać orientację pionową lub poziomą.

Urządzenia MUSZĄ raportować 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.

Urządzenia MUSZĄ zgłaszać obsługiwane orientacje ekranu (android.hardware.screen.portrait lub android.hardware.screen.landscape) i MUSZĄ zgłaszać co najmniej jedną obsługiwaną orientację. Na przykład urządzenie z niezmienną orientacją ekranu poziomego, takie jak telewizor czy laptop, MUSI zgłaszać tylko wartość android.hardware.screen.landscape.

7.1.4. akceleracja grafiki 2D i 3D;

Implementacje na urządzeniach MUSZĄ obsługiwać zarówno OpenGL ES 1.0, jak i 2.0, zgodnie z opisem w dokumentacji pakietu SDK Androida. Implementacje na urządzeniach powinny obsługiwać OpenGL ES 3.0 na urządzeniach, które mogą obsługiwać OpenGL ES 3.0. Implementacje na urządzeniu MUSZĄ obsługiwać Android Renderscript, zgodnie z dokumentacją Android SDK [Resources, 8].

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

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

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

Pamiętaj, że Android 4.3 obsługuje opcjonalne określanie przez aplikacje wymaganych formatów kompresji tekstur OpenGL. Te formaty są zwykle specyficzne dla dostawcy. Implementacje na urządzeniach z Androidem 4.3 nie muszą używać określonego formatu kompresji tekstur. NALEŻY jednak dokładnie podać wszystkie formaty kompresji tekstur, które są obsługiwane, za pomocą metody getString() w interfejsie OpenGL API.

Android 4.3 zawiera mechanizm, który umożliwia aplikacjom zadeklarowanie, że chcą włączyć przyspieszenie sprzętowe grafiki 2D na poziomie aplikacji, aktywności, okna lub widoku za pomocą tagu w pliku manifestuandroid:hardwareAccelerated lub bezpośrednich wywołań interfejsu API ([Zasoby, 9]).

W Androidzie 4.3 implementacje urządzeń MUSZĄ domyślnie włączać akcelerację sprzętową i MUSZĄ ją wyłączać, jeśli deweloper poprosi o to, ustawiając wartość android:hardwareAccelerated="false" lub wyłączając akcelerację sprzętową bezpośrednio za pomocą interfejsów API Androida View.

Ponadto implementacje na urządzeniach MUSZĄ działać zgodnie z dokumentacją Android SDK dotyczącą akceleracji sprzętowej ([Resources, 9]).

Android 4.3 zawiera obiekt TextureView, który umożliwia deweloperom bezpośrednie zintegrowanie tekstur OpenGL ES z przyspieszeniem sprzętowym jako celów renderowania w hierarchii interfejsu. Implementacje na urządzeniu MUSZĄ obsługiwać interfejs API TextureView i MUSZĄ zachowywać się w sposób spójny z implementacją na niższym poziomie w Androidzie.

Android 4.3 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 [Zasoby, 79].

7.1.5. Tryb zgodności ze starszymi wersjami aplikacji

Android 4.3 określa „tryb zgodności”, w którym platforma 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. Implementacje na urządzeniach MUSZĄ zawierać obsługę starszego trybu zgodności aplikacji, który jest implementowany przez upstreamowy kod źródłowy Androida typu open source. Oznacza to, że implementacje na urządzeniach NIE MOGĄ zmieniać wyzwalaczy ani progów, przy których aktywowany jest tryb zgodności, ani zmieniać zachowania samego trybu zgodności.

7.1.6. Typy ekranów

Ekrany implementacji urządzenia są podzielone na 2 rodzaje:

• Implementacje wyświetlacza o stałym pikselu: ekran to pojedynczy panel, który obsługuje tylko jedną szerokość i wysokość piksela. Ekran jest zwykle fizycznie zintegrowany z urządzeniem. Przykłady to telefony komórkowe, tablety itp.
• Implementacje wyświetlacza z pixelami o zmiennej wielkości: urządzenie albo nie ma wbudowanego ekranu i zawiera port wyjścia wideo, taki jak VGA, HDMI lub bezprzewodowy port do wyświetlania, albo ma wbudowany ekran, który może zmieniać wymiary pikseli. Przykłady: telewizory, dekodery itp.

Implementacje na urządzeniach z Pixelem

Implementacje urządzeń z urządzeniami o stałym rozmiarze piksela MOGĄ używać ekranów o dowolnych wymiarach pikseli, o ile spełniają wymagania określone w tej definicji zgodności.

Implementacje z użyciem pikseli stałych MOGĄ zawierać port wyjścia wideo do użycia z wyświetlaczem zewnętrznym. Jeśli jednak wyświetlacz jest używany do uruchamiania aplikacji, urządzenie MUSI spełniać te wymagania:

• Urządzenie MUSI zgłaszać te same dane o konfiguracji ekranu i wyświetlaczu, co wyświetlacz o stałych pikselach, zgodnie z informacjami podanymi w sekcjach 7.1.1 i 7.1.2.
• Urządzenie MUSI zgłaszać tę samą gęstość logiczną co wyświetlacz o stałych pikselach.
• Urządzenie MUSI zgłaszać wymiary ekranu, które są takie same lub bardzo zbliżone do wyświetlacza o stałych pikselach.

Na przykład tablet o przekątnej 7 cali i rozdzielczości 1024 x 600 pikseli jest uznawany za implementację wyświetlacza mdpi o dużej rozdzielczości i stałych pikselach. Jeśli zawiera port wyjścia wideo, który wyświetla obraz w rozdzielczości 720p lub 1080p, implementacja urządzenia MUSI skalować wyjście tak, aby aplikacje były wykonywane tylko w dużej rozdzielczości mdpi, niezależnie od tego, czy używany jest wyświetlacz z nieruchomymi pikselami czy port wyjścia wideo.

Implementacje urządzeń z urządzeniami o zmiennej liczbie pikseli

Implementacje urządzeń o zmiennej liczbie pikseli MUSZĄ obsługiwać rozdzielczość 1280 x 720 lub 1920 x 1080 (czyli 720p lub 1080p). Implementacje urządzeń z wyświetlaczami o zmiennej rozdzielczości NIE MOGĄ obsługiwać żadnej innej konfiguracji ani trybu ekranu. Implementacje urządzeń z ekranami o zmiennej rozdzielczości MOŻE zmieniać konfigurację lub tryb ekranu w czasie działania lub uruchamiania. Na przykład użytkownik dekodera może zastąpić wyświetlacz 720p wyświetlaczem 1080p, a implementacja urządzenia może się odpowiednio dostosować.

Dodatkowo implementacje urządzeń z pikselami o zmiennej wielkości MUSZĄ przekazywać informacje o tych zbiorach konfiguracji dotyczących wymiarów pikseli:

• 1280 x 720 (znane też jako 720p): rozmiar ekranu „duży”, gęstość „tvdpi” (213 dpi).
• 1920 x 1080 (zwane też 1080p): rozmiar ekranu „duży”, gęstość „xhdpi” (320 dpi).

Dla jasności: implementacje urządzeń o zmiennych wymiarach pikseli są ograniczone do rozdzielczości 720p lub 1080p w Androidzie 4.3 i MUSZĄ być skonfigurowane tak, aby raportowały zbiory rozmiarów i gęstości ekranu zgodnie z opisem powyżej.

7.1.7. 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. Więcej szczegółów:

• 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.
• Zastosowane rozwiązanie wyświetlacza MUSI mieć współczynnik proporcji pikseli (PAR) w zakresie od 0,9 do 1,1. Oznacza to, że współczynnik proporcji pikseli MUSI być zbliżony do kwadratu (1,0) z tolerancją 10%.

7.1.8. Wyświetlacze zewnętrzne

Android 4.3 obsługuje dodatkowy wyświetlacz, aby umożliwić udostępnianie multimediów, oraz interfejsy API dla deweloperów, które umożliwiają 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 Android SDK [Resources, 75]. Implementacje urządzeń, które obsługują bezpieczne wyjście wideo i mogą obsługiwać bezpieczne powierzchnie, MUSZĄ deklarować obsługę Display.FLAG_SECURE. W szczególności implementacje urządzeń, które deklarują obsługę Display.FLAG_SECURE, MUSZĄ obsługiwać HDCP 2.x lub nowszą w przypadku wyświetlaczy bezprzewodowych Miracast lub HDCP 1.2 lub nowszą w przypadku wyświetlaczy przewodowych. Górna implementacja open source Androida obejmuje obsługę wyświetlaczy bezprzewodowych (Miracast) i przewodowych (HDMI), która spełnia ten wymóg.

7.2. Urządzenia wejściowe

7.2.1. Klawiatura

Implementacje na urządzeniu:

• MUSI zawierać obsługę platformy zarządzania danymi wejściowymi (która umożliwia zewnętrznym deweloperom tworzenie mechanizmów zarządzania danymi wejściowymi, np.wirtualnych klawiatur), zgodnie z informacjami na stronie http://developer. android.com.
• Musisz udostępnić co najmniej jedną implementację wirtualnej klawiatury (niezależnie od tego, czy jest dostępna fizyczna klawiatura)
• MOŻE zawierać dodatkowe implementacje klawiatury ekranowej
• MOŻE zawierać klawiaturę sprzętową
• NIE MOŻE zawierać klawiatury sprzętowej, która nie odpowiada żadnemu z formatów określonych w android.content.res.Configuration.keyboard[Resources, 40] (czyli QWERTY lub 12 klawiszy).

7.2.2. Nawigacja bezdotykowa

Implementacje na urządzeniu:

• MOŻE pominąć opcję nawigacji bezdotykowej (czyli może pominąć trackball, pad kierunkowy lub koło)
• MUSI podać prawidłową wartość dla atrybutu android.content.res.Configuration.navigation[Resources, 40]
• 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. Implementacja open source w górę łańcucha Androida zawiera mechanizm wyboru odpowiedni do stosowania na urządzeniach, które nie mają elementów sterujących dotykowych.

7.2.3. Klawisze nawigacyjne

Funkcje Strona główna, Menu i Wstecz są niezbędne w ramach paradygmatu nawigacji w Androidzie. Implementacje na urządzeniach MUSZĄ udostępniać te funkcje użytkownikowi przez cały czas działania aplikacji. Te funkcje MOGĄ być realizowane za pomocą specjalnych przycisków fizycznych (takich jak mechaniczne lub pojemnościowe przyciski dotykowe) lub za pomocą specjalnych klawiszy programowych, gestów, panelu dotykowego itp. Android 4.3 obsługuje obie implementacje.

Android 4.3 obsługuje działanie asystenta [Materiały, 63]. Implementacje na urządzeniu MUSZĄ udostępniać użytkownikowi działanie wspomagające przez cały czas podczas uruchamiania aplikacji. Ta funkcja MOŻE być realizowana za pomocą klawiszy sprzętowych lub programowych.

Implementacje na urządzeniach 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ć osobnej części ekranu, niedostępnej dla aplikacji, i NIE MOGĄ 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 to określają.SYSTEM_UI_FLAG_LOW_PROFILE
• Implementacje na urządzeniu MUSZĄ ukryć klawisze nawigacyjne, gdy aplikacje określą SYSTEM_UI_FLAG_HIDE_NAVIGATION.
• Implementacja urządzenia MUSI udostępniać klucz menu aplikacjom, gdy wartość parametru targetSdkVersion jest <= 10, i NIE powinna udostępniać tego klucza, gdy wartość parametru targetSdkVersion jest > 10.

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:

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

Android 4.3 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 wyświetlaczem [Resources, 81], dzięki czemu użytkownik ma wrażenie bezpośredniego manipulowania elementami na ekranie. Ponieważ użytkownik dotyka ekranu bezpośrednio, system nie wymaga żadnych dodatkowych elementów, które wskazywałyby na manipulowane obiekty. 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, naśladuje dotyk, 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 4.0 zawiera stałą wartość funkcji android.hardware.faketouch, która odpowiada urządzeniu wejściowemu o wysokiej jakości, które nie jest dotykowe (czyli oparte na wskaźniku), takiemu jak mysz lub panel dotykowy, które może odpowiednio emulować wejście 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 obejmują ekran dotykowy (z jednym dotykiem lub lepszym) MUSZĄ przekazywać stałą wartość funkcji platformy android.hardware.touchscreen. Implementacje na urządzeniach, które podają stałą platformy android.hardware.touchscreen, MUSZĄ również podawać stałą platformy android.hardware.faketouch. Implementacje urządzeń, które nie mają ekranu dotykowego (i korzystają tylko z wskaźnika), NIE MOGĄ raportować żadnych funkcji ekranu dotykowego. Muszą raportować 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

• MUST report the absolute X and Y screen positions of the pointer location and display a visual pointer on the screen [Resources, 80]
• Musisz zgłaszać zdarzenie dotknięcia za pomocą kodu działania [Resources, 80], który określa stan zmiany, która występuje w przypadku down lub up na ekranie [Resources, 80]
• MUSI obsługiwać kursor down i up na obiekcie na ekranie, co pozwala użytkownikom emulować kliknięcie obiektu na ekranie.
• MUSI obsługiwać wskaźnik down, wskaźnik up, wskaźnik down, a następnie wskaźnik up w tym samym miejscu na ekranie w ramach określonego progu czasowego, co pozwala użytkownikom emulować dwukrotne kliknięcie obiektu na ekranie [Resources, 80]
• MUSI obsługiwać wskaźnik down w dowolnym miejscu na ekranie, wskaźnik przemieszcza się do dowolnego innego miejsca na ekranie, a następnie wskaźnik up, który pozwala użytkownikom emulować przeciąganie palcem.
• MUSI obsługiwać kursor down, aby umożliwić użytkownikom szybkie przenoszenie obiektu w inne miejsce na ekranie, a następnie kursor up na ekranie, który umożliwia użytkownikom przenoszenie obiektu na ekranie.

Urządzenia, które deklarują obsługę android.hardware.faketouch.multitouch.distinct, MUSZĄ spełniać wymagania dotyczące fałszywego dotykania wymienione powyżej, a także MUSZĄ obsługiwać oddzielne śledzenie co najmniej 2 niezależnych urządzeń wskazujących.

7.2.6. mikrofon

Implementacje na urządzeniu MOGĄ pomijać mikrofon. Jeśli jednak implementacja urządzenia nie zawiera mikrofonu, NIE MOŻE zgłaszać stałej funkcji android.hardware.microphone i musi zaimplementować interfejs API do nagrywania dźwięku jako no-op zgodnie z sekcją 7. Natomiast w przypadku implementacji urządzeń z mikrofonem:

• NALEŻY podać stałą funkcję android.hardware.microphone
• POWINNY spełniać wymagania dotyczące jakości dźwięku podane w sekcji 5.4
• POWINIEN spełniać wymagania dotyczące opóźnienia dźwięku podane w sekcji 5.5

7.3. Czujniki

Android 4.3 zawiera interfejsy API umożliwiające dostęp do różnych typów czujników. Implementacje urządzeń mogą w ogóle pomijać te czujniki, jak opisano w następnych podrozdziałach. Jeśli urządzenie zawiera określony typ czujnika 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. Na przykład w przypadku implementacji na urządzeniach:

• MUSI dokładnie raportować obecność lub brak czujników zgodnie z klasą android.content.pm.PackageManager. [Materiały, 37]
• MUSI zwracać dokładną listę obsługiwanych czujników za pomocą metody SensorManager.getSensorList() lub podobnych metod
• MUSI działać w rozsądny sposób w przypadku wszystkich innych interfejsów API czujników (np. zwracać wartość true lub false w odpowiednich przypadkach, gdy aplikacje próbują zarejestrować odbiorniki, nie wywoływać odbiorników czujników, gdy odpowiednie czujniki są nieobecne, itp.).
• MUST report all sensor measurements using the relevant International System of Units (i.e. metric) values for each sensor type as defined in the Android SDK documentation [Resources, 41]

Powyższa lista nie jest wyczerpująca. Należy stosować się do udokumentowanego zachowania pakietu Android SDK.

Niektóre typy czujników są syntetyczne, co oznacza, że można je uzyskać na podstawie danych pochodzących z co najmniej jednego innego czujnika. (Przykłady: czujnik orientacji i czujnik przyspieszenia liniowego). Implementacje urządzeń powinny uwzględniać te typy czujników, jeśli zawierają wymagane czujniki fizyczne.

Android 4.3 zawiera pojęcie „czujnika strumieniowego”, który zwraca dane ciągle, a nie tylko wtedy, gdy się zmieniają. Implementacje na urządzeniach MUSZĄ stale dostarczać okresowych próbek danych dla każdego interfejsu API wskazanego w dokumentacji pakietu SDK Androida 4.3 jako czujnik strumieniowy. Pamiętaj, że implementacje urządzeń MUSZĄ zapewnić, aby strumień danych z czujników nie uniemożliwiał procesorowi urządzenia przejścia w stan zawieszenia ani nie budził go z tego stanu.

7.3.1. Akcelerometr

Implementacje na urządzeniach powinny zawierać 3-osiowy akcelerometr. Jeśli implementacja urządzenia obejmuje 3-osiowy akcelerometr:

• Powinien być w stanie przesyłać zdarzenia z częstotliwością co najmniej 120 Hz. Pamiętaj, że chociaż częstotliwość pomiaru przyspieszenia powyżej jest określona jako „NALEŻY” w przypadku Androida 4.3, w przyszłej wersji definicji zgodności planujemy zmienić to na „NALEŻY”. Oznacza to, że te standardy są opcjonalne w Androidzie 4.3, ale będą wymagane w przyszłych wersjach. Istniejące i nowe urządzenia z Androidem 4.3 bardzo prosimy o spełnienie tych wymagań w Androidzie 4.3, aby można było uaktualnić je do przyszłych wersji platformy.
• MUSI być zgodny z systemem współrzędnych czujnika Androida opisanym w interfejsach Android API (patrz [Materiały, 41])
• MUSI umożliwiać pomiar w dowolnym wektorze trójwymiarowym od swobodnego spadania do podwójnego przyspieszenia ziemskiego (2 g) lub więcej.
• Musi mieć co najmniej 8-bitową dokładność
• Odchylenie standardowe musi być mniejsze niż 0,05 m/s2

7.3.2. Magnetometr

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

• MUSI być w stanie przesyłać zdarzenia z częstotliwością co najmniej 10 Hz
• MUSI być zgodny z systemem współrzędnych czujnika Androida, jak opisano w interfejsach Android API (patrz [Materiały, 41]).
• MUSI umożliwiać próbkowanie zakresu natężeń pola odpowiedniego do pokrycia pola geomagnetycznego
• Musi mieć co najmniej 8-bitową dokładność
• Odchylenie standardowe nie może być większe niż 0,5 µT

7.3.3. GPS

Implementacje urządzeń powinny zawierać odbiornik GPS. Jeśli implementacja urządzenia obejmuje odbiornik GPS, powinna zawierać jakąś formę techniki „wspomagania GPS”, aby zminimalizować czas ustalania pozycji przez GPS.

7.3.4. Żyroskop

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

• MUSI być wyposażony w kompensację temperatury.
• MUSI umożliwiać pomiar zmian orientacji do 5,5*Pi radianów/sekundę (czyli około 1000 stopni na sekundę).
• POWINIEN być w stanie przesyłać zdarzenia z częstotliwością co najmniej 200 Hz. Pamiętaj, że chociaż częstotliwość pomiaru żyroskopu w przypadku Androida 4.3 jest określona jako „SHOULD” (powinna), w definicji zgodności przyszłej wersji ta wartość zostanie zmieniona na „MUST” (musi). Oznacza to, że te standardy są opcjonalne w Androidzie 4.3, ale będą wymagane w przyszłych wersjach. Istniejące i nowe urządzenia z Androidem 4.3 bardzo prosimy o spełnienie tych wymagań w Androidzie 4.3, aby można było uaktualnić je do przyszłych wersji platformy.
• MUSI mieć co najmniej 12-bitową dokładność
• 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 od średniej żyroskopu przy częstotliwości próbkowania 1 Hz, nie powinno ono przekraczać 1 e-7 rad^2/s^2.
• Musi zawierać sygnatury czasowe jak najbardziej zbliżone do czasu wystąpienia zdarzenia związanego ze sprzętem. Stała wartość opóźnienia musi zostać usunięta.

7.3.5. barometr;

Implementacje urządzeń MOGĄ zawierać barometr (czyli czujnik ciśnienia powietrza). Jeśli implementacja urządzenia zawiera barometr, musi:

• 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ądzeń MOGĄ, ale NIE POWINNY zawierać termometru (czyli czujnika temperatury). Jeśli implementacja urządzenia zawiera termometr, MUSI on mierzyć temperaturę procesora urządzenia. Nie wolno mierzyć innej temperatury. (Pamiętaj, że ten typ czujnika został wycofany z interfejsów API Androida 4.3).

7.3.7. Fotometr

Implementacje urządzeń MOGĄ zawierać fotometr (czyli czujnik światła otoczenia).

7.3.8. Czujnik zbliżeniowy

Urządzenia mogą być wyposażone w czujnik zbliżeniowy. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy, MUSI on 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. Jeśli implementacja urządzenia zawiera czujnik zbliżeniowy, MUSI on mieć dokładność co najmniej 1 bita.

7.4. Łączność z danymi

7.4.1. Połączenia telefoniczne

Termin „telefonia” używany w interfejsach API Androida 4.3 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. Chociaż te połączenia głosowe mogą być przełączane pakietami, w przypadku Androida 4.3 są one uważane za niezależne od dowolnego połączenia danych, które może być stosowane w ramach tej samej sieci. Innymi słowy, funkcje i interfejsy API „telephony” w Androidzie odnoszą się konkretnie 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 4.3 MOŻE być używany na urządzeniach, które nie mają funkcji telefonicznej. Oznacza to, że Android 4.3 jest zgodny z urządzeniami, które nie są telefonami. Jeśli jednak implementacja urządzenia obejmuje telefonię GSM lub CDMA, MUSI wdrożyć pełną obsługę interfejsu API dla tej technologii. Implementacje na urządzeniach, które nie obejmują sprzętu telefonicznego, MUSZĄ implementować pełne interfejsy API jako no-ops.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementacje na urządzeniach z Androidem 4.3 powinny obsługiwać co najmniej jedną z form 802.11 (b/g/a/n itp.). Jeśli implementacja urządzenia obejmuje obsługę 802.11, MUSI implementować odpowiedni interfejs API Androida.

Implementacje na urządzeniu MUSZĄ implementować interfejs multicast API zgodnie z opisem w dokumentacji pakietu SDK [Resources, 62]. Implementacje urządzeń, które obsługują Wi-Fi, MUSZĄ obsługiwać multicast DNS (mDNS). Implementacje urządzeń NIE MOGĄ filtrować pakietów mDNS (224.0.0.251) w żadnym momencie działania, w tym wtedy, gdy ekran nie jest aktywny.

7.4.2.1. Wi-Fi Direct

Implementacje urządzeń powinny obejmować obsługę Wifi Direct (Wifi peer-to-peer). Jeśli implementacja urządzenia obejmuje obsługę Wifi Direct, musi ona implementować odpowiedni interfejs API Androida zgodnie z dokumentacją pakietu SDK [Resources, 68]. Jeśli implementacja urządzenia obejmuje obsługę Wi-Fi Direct, urządzenie:

• MUSI obsługiwać standardową sieć Wi-Fi
• SHOULD obsługuje równoczesne działanie Wi-Fi i Wi-Fi Direct

7.4.3. Bluetooth

Implementacje urządzeń powinny zawierać nadajnik Bluetooth. Implementacje urządzenia, które zawierają nadajnik Bluetooth, MUSZĄ włączyć interfejs Bluetooth oparty na RFCOMM zgodnie z opisem w dokumentacji pakietu SDK i zadeklarować funkcję sprzętową android.hardware.bluetooth [Resources, 42]. Implementacje urządzeń POWINNY implementować odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX itp., w sposób odpowiedni dla danego urządzenia.

Implementacje urządzeń, które obsługują Bluetooth GATT (Generic Attribute Profile), aby umożliwić komunikację z urządzeniami Bluetooth Smart lub Smart Ready, MUSZĄ włączyć interfejs Bluetooth API oparty na GATT zgodnie z opisem w dokumentacji SDK i zadeklarować funkcję sprzętową android.hardware.bluetooth_le [Resources, 42].

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, to:

• Musisz zgłaszać funkcję android.hardware.nfc za pomocą metody android.content.pm.PackageManager.hasSystemFeature(). [Materiały, 37]
• MUSI umożliwiać odczytywanie i zapisywanie wiadomości 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 6319-4)
    • IsoDep (ISO 14443-4)
    • Typy tagów NFC Forum 1, 2, 3 i 4 (zdefiniowane przez NFC Forum)
• Powinien być w stanie odczytywać i zapisywać komunikaty NDEF za pomocą tych standardów NFC: Pamiętaj, że chociaż poniższe standardy NFC są oznaczone jako „NALEŻY” w przypadku Androida 4.3, w przyszłej definicji zgodności planujemy zmienić to na „NALEŻY”. Oznacza to, że te standardy są opcjonalne w Androidzie 4.3, ale będą wymagane w przyszłych wersjach. Istniejące i nowe urządzenia z Androidem 4.3 bardzo zdecydowanie zachęcamy do spełnienia tych wymagań w Androidzie 4.3, aby można było uaktualnić je do przyszłych wersji platformy.
  • NfcV (ISO 15693)
• MUSI umożliwiać przesyłanie i odbieranie danych za pomocą tych standardów i protokołów peer-to-peer:
  • ISO 18092
  • LLCP 1.0 (zdefiniowana przez NFC Forum)
  • SDP 1.0 (zdefiniowana przez NFC Forum)
  • NDEF Push Protocol [Resources, 43]
  • SNEP 1.0 (zdefiniowany przez NFC Forum)
• MUSI zawierać obsługę Android Beam [Materiały, 65]:
  • MUSI implementować serwer domyślny SNEP. Prawidłowe komunikaty NDEF otrzymane przez domyślny serwer SNEP MUSZĄ zostać wysłane do aplikacji za pomocą intencjonalnej deklaracji android.nfc.ACTION_NDEF_DISCOVERED. Wyłączenie funkcji Android Beam w ustawieniach NIE MOŻE spowodować wyłączenia wysyłania wiadomości NDEF.
  • Implementacje urządzeń MUSZĄ obsługiwać intent android.settings.NFCSHARING_SETTINGS, aby wyświetlać ustawienia udostępniania NFC [Resources, 67].
  • MUSI implementować serwer NPP. Wiadomości odbierane przez serwer NPP MUSZĄ być przetwarzane w taki sam sposób jak przez domyślny serwer SNEP.
  • NALEŻY wdrożyć klienta SNEP i spróbować wysłać wychodzące NDEF P2P do domyślnego serwera SNEP, gdy włączona jest funkcja Android Beam. Jeśli nie zostanie znaleziony domyślny serwer SNEP, klient MUSI spróbować wysłać wiadomość na serwer NPP.
  • MUSI zezwalać aktywnościom na pierwszym planie na ustawianie wychodzących wiadomości NDEF P2P za pomocą android.nfc.NfcAdapter.setNdefPushMessage oraz android.nfc.NfcAdapter.setNdefPushMessageCallback oraz 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.
  • Domyślnie należy włączyć Android Beam.
  • 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, przez implementowanie specyfikacji „Connection Handover version 1.2” [Resources, 60] oraz „Bluetooth Secure Simple Pairing Using NFC version 1.0” [Resources, 61] z Forum NFC. W takim przypadku należy UŻYWAĆ żądań SNEP GET do wymiany żądania przekazania / wybranych rekordów za pomocą NFC, a DO RZECZNEGO PRZEKAZANIA DANYCH PRZEZ BLUETOOTH NALEŻY UŻYWAĆ profilu przesyłania obiektów Bluetooth.
• 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 i ekran blokady jest odblokowany.

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

Implementacje urządzeń mogą też obejmować obsługę czytników/nagrywarek w przypadku tych technologii MIFARE:

• MIFARE Classic (NXP MF1S503x [Resources, 44], MF1S703x [Resources, 45])
• MIFARE Ultralight (NXP MF0ICU1 [Resources, 46], MF0ICU2 [Resources, 47])
• NDEF na MIFARE Classic (NXP AN130511 [Resources, 48], AN130411 [Resources, 49])

Pamiętaj, że Android 4.3 zawiera interfejsy API dla tych typów MIFARE. Jeśli implementacja urządzenia obsługuje MIFARE w roli czytnika/pisarza, 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(). [Resources, 37] Pamiętaj, że nie jest to standardowa funkcja Androida i nie jest wyświetlana jako stała w klasie PackageManager.
• NIE MOŻE implementować odpowiednich interfejsów API Androida ani zgłaszać funkcji com.nxp.mifare, chyba że implementuje też ogólną obsługę NFC zgodnie z opisem w tej sekcji

Jeśli implementacja urządzenia nie obejmuje sprzętu NFC, NIE NALEŻY deklarować funkcji android.hardware.nfc w metodzie android.content.pm.PackageManager.hasSystemFeature() [Resources, 37] i NALEŻY zaimplementować interfejs NFC API w Androidzie 4.3 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 obejmują one obsługi NFC ani nie deklarują funkcji android.hardware.nfc.

7.4.5. Minimalna funkcjonalność sieci

Implementacje urządzeń MUSZĄ obsługiwać co najmniej jedną formę sieci danych. W szczególności implementacje urządzeń MUSZĄ obsługiwać co najmniej 1 standard danych o szybkości 200 kbps lub wyższej. Przykłady technologii spełniających ten wymóg to EDGE, HSPA, EV-DO, 802.11g, Ethernet itp.

Implementacje urządzeń, w których podstawowym połączeniem do przesyłania danych jest standard sieci fizycznej (np. Ethernet), POWINNY obejmować obsługę co najmniej jednego popularnego standardu bezprzewodowego przesyłania danych, takiego jak 802.11 (Wi-Fi).

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

7.5. Aparaty

Implementacje urządzeń powinny zawierać tylny aparat, a MOGĄ zawierać aparat przedni. Tylny aparat znajduje się po przeciwnej stronie urządzenia niż wyświetlacz. Oznacza to, że rejestruje obrazy z dalszej strony urządzenia, tak jak tradycyjny aparat. Przedni aparat to kamera znajdująca się po tej samej stronie urządzenia co wyświetlacz, czyli taka, która jest zwykle używana do robienia zdjęć użytkownikowi, na przykład podczas wideokonferencji i podobnych aplikacji.

7.5.1. Tylny aparat

Implementacje urządzeń powinny zawierać tylny aparat. Jeśli implementacja urządzenia obejmuje tylny aparat:

• Rozdzielczość musi wynosić co najmniej 2 megapiksele
• W sterowniku aparatu (niewidocznym dla oprogramowania aplikacji) powinien być zaimplementowany automatyczny autofokus sprzętowy lub automatyczny autofokus oprogramowania.
• 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ą, to lampa MUSI być WYŁĄCZONA, gdy instancja android.hardware.Camera.PreviewCallback została zarejestrowana na powierzchni podglądu aparatu, 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 obejmuje przedni aparat:

• Rozdzielczość musi wynosić co najmniej VGA (czyli 640 x 480 pikseli).
• Domyślnie w interfejsie Camera API NIE MOŻNA używać przedniego aparatu. Oznacza to, że interfejs API aparatu w Androidzie 4.3 obsługuje w szczególny sposób przednie kamery, a implementacje na urządzeniach NIE MOGĄ skonfigurować interfejsu API tak, aby traktował przednią kamerę jako domyślną tylną kamerę, nawet jeśli jest to jedyna kamera na urządzeniu.
• MOŻE zawierać funkcje (takie jak autofokus, lampa błyskowa itp.) dostępne dla tylnych aparatów zgodnie z opisem w sekcji 7.5.1.
• Musisz odwrócić poziomo (czyli lustro) strumień wyświetlany przez aplikację w CameraPreview, jak pokazano poniżej:
• 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ć odwrócony poziomo względem bieżącej orientacji urządzenia.
• Jeśli bieżąca aplikacja wyraźnie poprosiła o obrócenie wyświetlacza kamery za pomocą wywołania metody android.hardware.Camera.setDisplayOrientation() [Resources, 50], podgląd kamery MUSI być lustrzany w poziomie względem orientacji określonej przez aplikację.
• W przeciwnym razie podgląd MUSI być odzwierciedlony wzdłuż domyślnej osi poziomej urządzenia.
• OBRAZ MUSI BYĆ ODWRÓCONY w taki sam sposób jak obraz w podglądzie po wyświetleniu. (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. Zachowanie interfejsu Camera API

Implementacje urządzeń MUSZĄ implementować te zachowania w przypadku interfejsów API związanych z kamerą, zarówno w przypadku aparatów przednich, jak i tylnych:

1. Jeśli aplikacja nigdy nie wywołała funkcji android.hardware.Camera.Parameters.setPreviewFormat(int), urządzenie MUSI używać wartości android.hardware.PixelFormat.YCbCr_420_SP do danych podglądu przekazywanych do wywołań zwrotnych aplikacji.
2. Jeśli aplikacja rejestruje wystąpienie android.hardware.Camera.PreviewCallback , a system wywołuje metodę onPreviewFrame(), gdy format podglądu to YCbCr_420_SP, dane w byte[] przekazywane do onPreviewFrame() muszą być zakodowane w formacie NV21. Oznacza to, że NV21 MUSI być ustawiony jako domyślny.
3. 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.)

Implementacje na urządzeniu MUSZĄ implementować pełny interfejs Camera API zawarty w dokumentacji pakietu SDK Androida 4.3 [Zasoby, 51], niezależnie od tego, czy urządzenie ma sprzętowy autofokus lub inne funkcje. Na przykład aparaty bez autofokusa MUSZĄ wywoływać wszystkie zarejestrowane instancje android.hardware.Camera.AutoFocusCallback (chociaż nie ma to zastosowania do aparatów bez autofokusa). Pamiętaj, że dotyczy to również przednich aparatów. Chociaż większość przednich aparatów nie obsługuje autofokusa, wywołania interfejsu API muszą być „udawane” 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 bazowy obsługuje tę funkcję. Jeśli sprzęt urządzenia nie obsługuje danej funkcji, interfejs API musi działać zgodnie z opisem. Z drugiej strony implementacje na urządzeniu NIE MOGĄ obsługiwać ani rozpoznawać stałych ciągów znaków przekazywanych do metody android.hardware.Camera.setParameters(), które nie są opisane jako stałe w android.hardware.Camera.Parameters. Oznacza to, że implementacje urządzeń MUSZĄ obsługiwać wszystkie standardowe parametry kamery, jeśli sprzęt na to pozwala, i NIE MOGĄ obsługiwać niestandardowych typów parametrów kamery. Na przykład implementacje urządzeń, które obsługują techniki obrazowania z wysokim zakresem dynamiki (HDR), MUSZĄ obsługiwać parametr kamery Camera.SCENE_MODE_HDR ([Resources, 78]).

Implementacje na urządzeniu MUSZĄ wysyłać intencję Camera.ACTION_NEW_PICTUREza każdym razem, gdy aparat zrobi nowe zdjęcie i jego wpis zostanie dodany do magazynu multimediów.

Implementacje na urządzeniu MUSZĄ wysyłać intencję Camera.ACTION_NEW_VIDEOza każdym razem, gdy kamera nagra nowy film, a zdjęcie zostanie dodane do magazynu multimediów.

7.5.4. Orientacja aparatu

Przedni i tylny aparat (jeśli są dostępne) MUSZĄ być ustawione 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Ą rejestrować obraz 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

Implementacje urządzeń MUSZĄ mieć co najmniej 340 MB pamięci dostępnej dla jądra i przestrzeni użytkownika. 340 MB MUSI być dodatkiem do pamięci przeznaczonej na komponenty sprzętowe, takie jak radio, wideo itp., które nie są kontrolowane przez jądro.

Implementacje urządzeń MUSZĄ mieć co najmniej 512 MB pamięci nieulotnej dostępnej dla prywatnych danych aplikacji. Oznacza to, że partycja /data MUSI mieć co najmniej 512 MB. W przypadku implementacji urządzeń z Androidem 4.3 bardzo zalecamy, aby urządzenia miały co najmniej 1 GB pamięci nieulotnej na dane prywatne aplikacji, aby można było je uaktualnić do przyszłych wersji platformy.

Interfejsy API Androida zawierają Menedżera pobierania, którego aplikacje mogą używać do pobierania plików danych [Materiały, 56]. Implementacja Menedżera pobierania na urządzeniu MUSI umożliwiać pobieranie poszczególnych 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ć pamięć współdzieloną dla aplikacji. Udostępnione miejsce na dane musi mieć co najmniej 1 GB.

Implementacje urządzeń MUSZĄ być skonfigurowane z zainstalowanym domyślnie, „w standardzie” miejscem na dane współdzielone. Jeśli współdzielone miejsce na dane nie jest zamontowane w ścieżce Linuxa /sdcard, urządzenie MUSI zawierać link symboliczny Linuxa z /sdcard do rzeczywistego punktu montowania.

Implementacje urządzeń MUSZĄ egzekwować zgodnie z dokumentacją uprawnienia android.permission.WRITE_EXTERNAL_STORAGE do tego wspólnego magazynu. W przeciwnym razie udostępnione miejsce na dane MUSI być dostępne do zapisu dla każdej aplikacji, która uzyskała to uprawnienie.

Implementacje urządzeń mogą zawierać sprzęt do obsługi wymiennych nośników danych, do których użytkownik ma dostęp, np. karty Secure Digital. Implementacje urządzeń mogą przydzielać pamięć wewnętrzną (nieusuwalna) jako pamięć współdzielona dla aplikacji.

Niezależnie od formy używanej pamięci współdzielonej implementacje urządzeń MUSZĄ udostępniać mechanizm umożliwiający dostęp do zawartości tej pamięci z komputera hosta, np. za pomocą pamięci masowej USB (UMS) lub protokołu MTP. Implementacje urządzeń mogą używać pamięci masowej USB, ale powinny używać protokołu Media Transfer Protocol. Jeśli implementacja urządzenia obsługuje protokół Media Transfer Protocol:

• Implementacja urządzenia powinna być zgodna z hostem MTP w Androidzie, czyli z Android File Transfer [Resources, 57].
• Implementacja urządzenia powinna zgłaszać klasę urządzenia USB 0x00.
• Implementacja urządzenia powinna raportować nazwę interfejsu USB „MTP”.

Jeśli implementacja urządzenia nie zawiera portów USB, MUSI ona zapewniać komputerowi hosta dostęp do zawartości współdzielonej pamięci masowej za pomocą innych środków, takich jak system plików sieciowych.

Aby zilustrować tę kwestię, podajemy 2 typowe przykłady. Jeśli implementacja urządzenia obejmuje gniazdo karty SD, aby spełnić wymagania dotyczące współdzielonej pamięci, w ramach urządzenia sprzedawanego użytkownikom MUSI być dołączona karta SD w formacie FAT o rozmiary co najmniej 1 GB, która MUSI być domyślnie zamontowana. Jeśli implementacja urządzenia używa wewnętrznego stałego miejsca na dane, aby spełnić ten wymóg, miejsce na dane MUSI mieć rozmiar co najmniej 1 GB i być zamontowane w /sdcard (lub /sdcard MUSI być symboliczną lokalizacją w stosunku do fizycznej lokalizacji, jeśli jest zamontowane gdzie indziej).

W przypadku implementacji urządzeń, które obejmują wiele ścieżek do współdzielonej pamięci (np. zarówno gniazda kart SD, jak i współdzieloną pamięć wewnętrzną), NALEŻY zmodyfikować podstawowe aplikacje, takie jak skaner multimediów i ContentProvider, aby obsługiwały w przezroczysty sposób pliki umieszczone w obu lokalizacjach.

7.7. USB

Implementacje urządzeń powinny zawierać port USB klienta i port USB hosta.

Jeśli implementacja urządzenia zawiera port klienta USB:

• port MUSI umożliwiać połączenie z hostem USB za pomocą standardowego portu USB-A;
• Port powinien mieć format micro USB po stronie urządzenia. Istniejące i nowe urządzenia z Androidem 4.3 bardzo prosimy o spełnienie tych wymagań w Androidzie 4.3, aby można było uaktualnić je do przyszłych wersji platformy.
• Port powinien być wyśrodkowany na krawędzi. W przypadku implementacji urządzeń NALEŻY umieścić port na dole urządzenia (zgodnie z naturalną orientacją) lub umożliwić 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. Istniejące i nowe urządzenia z Androidem 4.3 bardzo zalecamy, aby spełniały te wymagania w Androidzie 4.3, aby można było uaktualnić je do przyszłych wersji platformy.
• jeśli urządzenie ma inne porty (np. port ładowania inny niż USB), powinny one znajdować się po tej samej stronie co port micro-USB;
• musi umożliwiać hostowi podłączonemu do urządzenia dostęp do zawartości udostępnionego woluminu pamięci masowej za pomocą pamięci masowej USB lub protokołu Media Transfer Protocol;
• MUSI implementować interfejs API i specyfikację Android Open Accessory zgodnie z dokumentacją do pakietu Android SDK oraz MUSI zadeklarować obsługę funkcji sprzętowej android.hardware.usb.accessory [Resources, 52]
• musi implementować klasę audio USB zgodnie z dokumentacją pakietu Android SDK [Resources, 66]
• Należy wdrożyć obsługę specyfikacji ładowania baterii przez USB [Resources, 64]. Zaleca się, aby istniejące i nowe urządzenia z Androidem 4.3 spełniały te wymagania w Androidzie 4.3, aby można było je uaktualnić do przyszłych wersji platformy.

Jeśli implementacja urządzenia zawiera port hosta USB:

• może używać niestandardowego formatu portu, ale w takim przypadku MUSI być dostarczany z kablem lub kablami umożliwiającymi dostosowanie portu do standardowego kabla USB-A;
• MUSI implementować interfejs hosta Android USB zgodnie z dokumentacją w pakiecie SDK Androida i MUSI deklarować obsługę funkcji sprzętowej. android.hardware.usb.host [Resources, 53]

Implementacje na urządzeniach MUSZĄ wykorzystywać Android Debug Bridge. Jeśli implementacja urządzenia pomija port klienta USB, MUSI implementować debugowanie Androida za pomocą mostu przez sieć lokalną (np. Ethernet lub 802.11).

8. Zgodność z kampaniami Performance Max

Implementacje urządzeń MUSZĄ spełniać kluczowe wskaźniki wydajności urządzenia zgodnego z Androidem 4.3 określone w tabeli poniżej:

Wskaźnik	Próg skuteczności	Komentarze
Czas uruchamiania aplikacji	W wyznaczonym czasie powinny się uruchomić te aplikacje: Przeglądarka: mniej niż 1300 ms Kontakty: mniej niż 700 ms Ustawienia: mniej niż 700 ms	Czas uruchamiania jest mierzony jako łączny czas wczytywania domyślnej czynności aplikacji, w tym czas potrzebny na uruchomienie procesu Linuxa, wczytanie pakietu Androida do maszyny wirtualnej Dalvik i wywołanie onCreate.
Równoczesne zgłoszenia	Gdy uruchomiono kilka aplikacji, ponowne uruchomienie już uruchomionej aplikacji musi zająć mniej czasu niż pierwotny czas uruchomienia.

9. Zgodność modelu zabezpieczeń

Implementacje na urządzeniu MUSZĄ stosować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji referencyjnej Bezpieczeństwo i uprawnienia w API [Zasoby, 54] w dokumentacji dla deweloperów Androida. Implementacje urządzeń MUSZĄ obsługiwać instalację samodzielnie podpisanych aplikacji bez konieczności uzyskiwania dodatkowych uprawnień lub certyfikatów od stron trzecich lub organów. W szczególności urządzenia zgodne MUSZĄ obsługiwać mechanizmy zabezpieczeń opisane w następujących podrozdziałach.

9.1. Uprawnienia

Implementacje urządzeń MUSZĄ obsługiwać model uprawnień Androida zgodnie z opisem w dokumentacji dla deweloperów [Zasoby, 54]. W szczególności implementacje MUSZĄ stosować wszystkie uprawnienia zdefiniowane zgodnie z dokumentacją pakietu SDK. Żadnych uprawnień nie można pominąć, zmienić ani zignorować. Implementacje MOGĄ dodawać dodatkowe uprawnienia, o ile nowe ciągi znaków identyfikatora uprawnień nie znajdują się w przestrzeni nazw android.*.

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 jako tego samego identyfikatora użytkownika Linuksa, pod warunkiem, że aplikacje są odpowiednio podpisane i skonstruowane zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień [Zasoby, 54].

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 poświęconej zabezpieczeniom i uprawnieniom [Zasoby, 54].

9.4. Alternatywne środowiska wykonawcze

Implementacje urządzeń mogą zawierać środowiska wykonawcze, które wykonują aplikacje za pomocą innego oprogramowania lub innej technologii niż maszyna wirtualna Dalvik czy kod natywny. Jednak takie alternatywne środowiska wykonawcze 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, o które nie prosimy 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. Więcej szczegółów:

• Alternatywny czas wykonywania POWINIEN instalować aplikacje za pomocą menedżera pakietów w oddzielnych piaskownicach Androida (czyli z użyciem identyfikatorów użytkowników Linuksa itp.).
• Alternatywny czas wykonywania MOŻE udostępniać jedną piaskownicę Androida wszystkim aplikacjom korzystającym z alternatywnego czasu wykonywania
• Alternatywne środowisko uruchomieniowe i zainstalowane aplikacje korzystające z alternatywnego środowiska uruchomieniowego NIE MOGĄ 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.
• Alternatywny czas wykonywania NIE MOŻE uruchamiać, przyznawać ani uzyskiwać dostępu do piaskownicy odpowiadającej innym aplikacjom na Androida.

Alternatywny czas wykonywania NIE MOŻE być uruchamiany z uprawnieniami superużytkownika (root) ani nie może przyznawać takich uprawnień innym aplikacjom ani nie może ich przyznawać innym aplikacjom.

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 dołączonych do implementacji urządzenia.

Podczas instalowania aplikacji alternatywne środowisko wykonawcze MUSI uzyskać zgodę użytkownika na uprawnienia Androida używane przez aplikację. Oznacza to, że jeśli aplikacja musi korzystać z zasobu urządzenia, do którego jest dostępne odpowiednie uprawnienie Androida (np. Aparat, GPS itp.), alternatywne środowisko wykonawcze MUSI poinformować 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 samo środowisko uruchomieniowe podczas instalowania dowolnej aplikacji korzystającej z tego środowiska.

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

Android 4.3 obsługuje wielu użytkowników i pozwala na pełną izolację użytkowników [Zasoby, 70].

Implementacje urządzeń MUSZĄ spełniać te wymagania związane z obsługą wielu użytkowników [Zasoby, 71]:

• Ponieważ działanie interfejsów API telefonii na urządzeniach z wieloma użytkownikami nie zostało jeszcze zdefiniowane, implementacje urządzeń, które deklarują android.hardware.telephony, NIE MOGĄ obsługiwać wielu użytkowników.
• Implementacje urządzeń MUSZĄ dla każdego użytkownika stosować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Androida, jak określono w dokumentacji referencyjnej interfejsów API dotyczącej zabezpieczeń i uprawnień [Resources, 54]
• Android 4.3 obsługuje profile ograniczone, które umożliwiają właścicielom urządzeń zarządzanie dodatkowymi użytkownikami i ich uprawnieniami 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. Implementacje urządzeń, które obsługują wielu użytkowników, MUSZĄ obsługiwać profile z ograniczonymi uprawnieniami. Dostępny w górę projekt Android Open Source zawiera implementację, która spełnia ten wymóg.

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 korzystają z interfejsów API pamięci zewnętrznej na nośnikach wymiennych, MUSZĄ szyfrować zawartość karty SD, jeśli włączona jest obsługa wielu użytkowników, za pomocą klucza przechowywanego tylko na nośniku niewymiennym, dostępnym tylko dla systemu. Ponieważ w takim przypadku dane 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 [Resources, 72] jako podstawowej pamięci zewnętrznej. Górny projekt Android Open Source zawiera implementację, która używa wewnętrznej pamięci urządzenia do interfejsów API zewnętrznej pamięci aplikacji. Implementacje na urządzeniu powinny używać tej konfiguracji i implementacji oprogramowania. Implementacje urządzeń, które zawierają wiele ścieżek do zewnętrznej pamięci, NIE MOGĄ zezwalać aplikacjom na Androida na zapisywanie danych na zewnętrznej pamięci.

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

Android 4.3 obsługuje wyświetlanie użytkownikom ostrzeżeń przed wysyłaniem SMS-ów specjalnych [Resources, 73] . 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 wysłaniem wiadomości SMS do numerów zidentyfikowanych za pomocą wyrażeń regularnych zdefiniowanych 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

Sandbox Androida w wersji 4.3 zawiera funkcje, które mogą korzystać z systemu SELinux (mandatory access control, czyli obowiązkowa kontrola dostępu) i innych funkcji bezpieczeństwa w rdzeniu systemu Linux. Implementacje urządzeń MUSZĄ obsługiwać mechanizm SELinux MAC. Pamiętaj, że upstreamowy projekt Android Open Source udostępnia implementację, która spełnia ten wymóg.

SELinux lub inne funkcje zabezpieczeń zaimplementowane poniżej platformy Android MUSZĄ zachowywać zgodność z dotychczasowymi aplikacjami. Te funkcje powinny być niewidoczne dla użytkowników i programistów. Funkcji tych nie powinien mieć możliwości konfigurowania użytkownik ani deweloper. 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ść. Aby zapewnić ciągłą zgodność, implementacja referencyjna umożliwia korzystanie z SELinux w trybie permisywnym i obsługuje dynamiczne aktualizacje zasad bez konieczności aktualizowania obrazu systemu. Implementacje urządzeń korzystające z SELinux MUSZĄ obsługiwać tryb zezwalający, obsługiwać dynamiczne aktualizacje zasad i rejestrować wszelkie naruszenia zasad bez zakłócania działania aplikacji lub wpływania na działanie systemu. Implementacje korzystające z SELinux powinny wczytywać zasady z pliku /sepolicy na urządzeniu. Dostępny w górę projektu Android Open Source Project zapewnia implementację, która spełnia ten wymóg. Implementacje na urządzeniu POWINNY korzystać z implementacji referencyjnej w Projekcie Android Open Source, a implementacje na urządzeniu MUSZĄ być zgodne z górnym projektem Android Open Source.

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 zalecamy, aby implementatorzy urządzeń wprowadzali jak najmniej zmian w wersji referencyjnej i preferowanej implementacji Androida 4.3 dostępnej w ramach Projektu Android Open Source. Pozwoli to zminimalizować ryzyko wprowadzenia błędów, które powodują niezgodności i wymagają ponownego wykonania pracy oraz potencjalnych aktualizacji urządzenia.

10.1. Compatibility Test Suite

Implementacje urządzeń MUSZĄ przejść testy Compatibility Test Suite (CTS) [Resources, 2] dostępne w ramach Projektu Android Open Source, korzystając z oprogramowania dołączonego do urządzenia. Dodatkowo implementatorzy urządzeń powinni w jak największym stopniu korzystać z implementacji referencyjnej w drzewie kodu źródłowego Androida na licencji Open Source. Muszą też zapewnić zgodność w przypadku niejednoznaczności w CTS oraz w przypadku każdej ponownej implementacji części referencyjnego kodu źródłowego.

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 4.3 może być udostępnionych wiele wersji CTS. Implementacje urządzeń MUSZĄ przejść najnowszą wersję CTS, która jest dostępna w momencie ukończenia oprogramowania urządzenia.

10.2. Weryfikator CTS

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

Narzędzie CTS Verifier zawiera testy dla wielu rodzajów sprzętu, w tym dla niektórych opcjonalnych. Implementacje urządzeń MUSZĄ przejść wszystkie testy dotyczące posiadanego sprzętu. 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 jako opcjonalne MOGĄ zostać pominięte.

Każde urządzenie i każda kompilacja MUSZĄ prawidłowo działać z narzędziem CTS Verifier, jak opisano powyżej. 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 zestawem obsługiwanych lokalizacji, marki itp., MOGĄ pominąć test CTS Verifier.

10.3. Aplikacje referencyjne

Implementatorzy urządzeń MUSZĄ przetestować zgodność implementacji za pomocą tych aplikacji open source:

• Aplikacje „Aplikacje na Androida” [Zasoby, 55]
• Replica Island (dostępna w Sklepie Google Play)

Aby implementacja została uznana za zgodną, każda z wymienionych wyżej aplikacji MUSI uruchamiać się prawidłowo i działać prawidłowo.

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”, co oznacza, że może być konieczne 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 dowolna z tych metod spełnia to wymaganie:

• Pobieranie bezprzewodowe (OTA) z aktualizacją offline po ponownym uruchomieniu
• „Przywiązane” aktualizacje przez USB z komputera głównego
• „Offline” aktualizacje przez ponowne uruchomienie i aktualizację z pliku na wymiennym dysku pamięci

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

Jeśli po wydaniu urządzenia zostanie w nim wykryty błąd, ale w rozsądnym okresie jego użytkowania, który został określony w konsultacji z zespołem ds. zgodności Androida, aby wpłynąć na zgodność aplikacji innych firm, implementator urządzenia MUSI naprawić błąd za pomocą dostępnej aktualizacji oprogramowania, którą można zastosować zgodnie z omówionym właśnie mechanizmem.

12. Skontaktuj się z nami

Aby uzyskać wyjaśnienia i przedstawić problemy, które Twoim zdaniem nie zostały omówione w dokumencie, skontaktuj się z jego autorami pod adresem compatibility@android.com.