Definicja zgodności z Androidem 2.1

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

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

1. Wprowadzenie

Ten dokument zawiera listę wymagań, które muszą być spełnione, aby telefony komórkowe były zgodne z Androidem 2.1.

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 2.1. „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 2.1, musi ona:

• MUSI spełniać wymagania podane w tym dokumencie definicji zgodności, w tym wszelkie dokumenty włączone przez odwołanie.
• Musi przejść najnowszą wersję pakietu testów zgodności Androida (CTS) dostępnego w momencie zakończenia implementacji oprogramowania urządzenia. (CTS jest dostępny w ramach Projektu Android Open Source [Resources, 2]). Test CTS sprawdza wiele, ale nie wszystkie komponenty opisane w tym dokumencie.

Jeśli definicja lub pakiet CTS jest niejednoznaczny, niepełny lub niejasny, 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. Wdrożeniom urządzeń zdecydowanie zalecamy opieranie ich na „górnym” kodzie źródłowym dostępnym w ramach projektu Android Open Source. Chociaż niektóre komponenty można teoretycznie zastąpić alternatywnymi implementacjami, zdecydowanie odradzamy taką praktykę, ponieważ znacznie utrudni to zaliczenie testów CTS. Implementator jest odpowiedzialny za zapewnienie pełnej zgodności behawioralnej ze standardową implementacją Androida, w tym w ramach pakietu Compatibility Test Suite i poza nim. Pamiętaj, że niektóre wymiany i modyfikacje komponentów są wyraźnie zabronione w tym dokumencie.

2. Materiały

1. Poziomy wymagań RFC 2119 IETF: http://www.ietf.org/rfc/rfc2119.txt
2. Przegląd programu zgodności z Androidem: http://source.android.com/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 bibliotece android.os.Build: http://developer.android.com/reference/android/os/Build.html
7. Dozwolone ciągi znaków wersji Androida 2.1: http://source.android.com/docs/compatibility/2.1/versions.html
8. Klasa android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. Specyfikacja maszyny wirtualnej Dalvik: dostępna w kodzie źródłowym Androida w folderze dalvik/docs.
11. Widgety aplikacji: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
12. Powiadomienia: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
13. Zasoby aplikacji: http://code.google.com/android/reference/available-resources.html
14. Przewodnik po stylu ikon na pasku stanu: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
15. Menedżer wyszukiwania: http://developer.android.com/reference/android/app/SearchManager.html
16. Toasty: http://developer.android.com/reference/android/widget/Toast.html
17. Tapety na żywo: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
18. Aplikacje na Androida: http://code.google.com/p/apps-for-android
19. Dokumentacja narzędzi (dla adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
20. Opis pliku APK na Androida: http://developer.android.com/guide/topics/fundamentals.html
21. Pliki manifestu: http://developer.android.com/guide/topics/manifest/manifest-intro.html
22. Narzędzie do testowania Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
23. Obsługa wielu ekranów: http://developer.android.com/guide/practices/screens_support.html
24. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
25. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
26. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
27. Przestrzeń współrzędnych czujnika: http://developer.android.com/reference/android/hardware/SensorEvent.html
28. Informacje o bezpieczeństwie i uprawnieniach w Androidzie: http://developer.android.com/guide/topics/security/security.html
29. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

Wiele z tych zasobów pochodzi bezpośrednio lub pośrednio z Androida 2.1 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

Platforma Androida obejmuje zestaw zarządzanych interfejsów API, zestaw natywnych interfejsów API oraz zestaw tak zwanych „miękkich” interfejsów API, takich jak system Intent i interfejsy API aplikacji internetowych. W tej sekcji znajdziesz szczegółowe informacje o twardych i miękkich interfejsach API, które są niezbędne do zapewnienia zgodności, a także o niektórych innych istotnych zachowaniach technicznych i interfejsu użytkownika. Implementacje urządzeń MUSZĄ spełniać wszystkie wymagania opisane w tej sekcji.

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Ą zapewniać pełne implementacje, w tym wszystkie udokumentowane zachowania, wszystkich udokumentowanych interfejsów API udostępnionych przez pakiet SDK Androida 2.1 [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.

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. W tej sekcji znajdziesz szczegółowe informacje o interfejsach API „soft” i zachowaniach systemu, które są wymagane do zapewnienia zgodności z Androidem 2.1. Implementacje urządzeń MUSZĄ spełniać wszystkie wymagania podane w tej sekcji.

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 10 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 2.1 to pole MUSI zawierać wartość całkowitą 7.
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 wysyłanych do użytkowników końcowych. 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. 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.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. 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.DEVICE	Wartość wybrana przez implementatora urządzenia, która identyfikuje konkretną konfigurację lub wersję obudowy (czasami nazywaną „wzornictwem przemysłowym”) urządzenia. 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.FINGERPRINT	Ciąg znaków jednoznacznie identyfikujący tę kompilację. Powinien być w rozsądnym stopniu czytelny dla człowieka. Musi ono być zgodne z tym szablonem: $(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Na przykład: acme/mydevice/generic/generic:2.1-update1/ERC77/3359:userdebug/test-keys Odcisk palca NIE MOŻE zawierać spacji. Jeśli inne pola w powyższym szablonie zawierają spacje, należy je zastąpić w odpisie cyfrowym znakiem podkreślenia ASCII („_”).
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. Nie ma żadnych wymagań dotyczących formatu tego pola, z tym wyjątkiem, że NIE MOŻE ono być 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ą urządzenia. MUSI być zrozumiała dla człowieka, ale nie musi być przeznaczona do wyświetlania 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.TAGS	Lista tagów wybranych przez implementatora urządzenia, rozdzielona przecinkami, która dodatkowo rozróżnia kompilację. Na przykład „unsigned,debug”. To pole NIE może być puste ani zawierać pustego ciągu znaków (""), ale można użyć pojedynczego tagu (np. „release”).
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”.
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

Android używa intencji do luźnej integracji aplikacji. W tej sekcji opisano wymagania dotyczące wzorów intencji, które MUSZĄ być obsługiwane przez implementacje na urządzeniach. „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 właściwym działaniem dla każdego określonego wzorca intencji.

3.2.3.1. Główne intencje aplikacji

Projekt upstream Androida definiuje kilka podstawowych aplikacji, takich jak wybieranie numeru, kalendarz, książka adresowa czy odtwarzacz muzyki. Deweloperzy urządzeń MOGĄ zastąpić te aplikacje 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
• Kalkulator
• Aparat
• kontakty,
• Wysyłając e-mailem
• Galeria
• GlobalSearch
• Wyrzutnia
• LivePicker (czyli aplikacja do wybierania animowanych tapet; MOŻE zostać pominięta, jeśli urządzenie nie obsługuje animowanych tapet zgodnie z sekcją 3.8.5).
• Wiadomości (inaczej „MMS”)
• Muzyka
• Telefon
• Ustawienia
• Rejestrator dźwięku

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ą, implementatorzy urządzeń MUSZĄ zezwalać na zastępowanie każdego wzorca intencji zdefiniowanego w podstawowych aplikacjach systemowych przez aplikacje innych firm. Górny projekt o źródle otwartym Androida zezwala na to domyślnie. 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 m.in. wyłączenie interfejsu „Wybór”, który umożliwia użytkownikowi wybór spośród wielu aplikacji, z których każda obsługuje ten sam wzór intencji.

3.2.3.3. Przestrzenie nazw intencji

Implementatorzy urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub intencji rozgłoszeniowych za pomocą działania, kategorii ani innego kluczowego ciągu znaków w przestrzeni nazw android.*. Implementatorzy urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub intencji rozgłoszenia za pomocą działania, kategorii lub innego kluczowego ciągu znaków 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.

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

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. Implementacje na urządzeniach MUSZĄ zawierać obsługę kodu działającego w środowisku zarządzanym, aby wywoływać kod natywny za pomocą standardowej semantyki interfejsu JNI (Java Native Interface). Kod natywny musi mieć dostęp do tych interfejsów API:

• libc (biblioteka C)
• libm (biblioteka matematyczna)
• Interfejs JNI
• libz (kompresja Zlib)
• liblog (rejestrowanie na Androidzie)
• Minimalne wsparcie dla C++
• Obsługa OpenGL, jak opisano poniżej

Implementacje na urządzeniu MUSZĄ obsługiwać OpenGL ES 1.0. Urządzenia, które nie mają akceleracji sprzętowej, MUSZĄ implementować OpenGL ES 1.0 przy użyciu renderowania programowego. Implementacje na urządzeniach powinny wykorzystywać OpenGL ES 1.1 w takim zakresie, w jakim pozwala na to sprzęt. Implementacje na urządzeniu powinny zapewniać obsługę OpenGL ES 2.0, jeśli sprzęt zapewnia odpowiednią wydajność w przypadku tych interfejsów API.

Te biblioteki MUSZĄ być zgodne z źródłem (czyli z nagłówkami) i z binarnymi wersjami (w przypadku danej architektury procesora) z wersjami udostępnionymi w Bionic przez projekt Android Open Source. Implementacje Bionic nie są w pełni zgodne z innymi implementacjami, takimi jak biblioteka GNU C, dlatego implementatorzy urządzeń powinni używać implementacji Androida. Jeśli implementatorzy urządzeń używają innej implementacji tych bibliotek, MUSZĄ zadbać o zgodność z nagłówkiem, binarną i zachowaniem.

Implementacje na urządzeniu MUSZĄ prawidłowo raportować natywny interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie za pomocą interfejsu API android.os.Build.CPU_ABI. ABI MUSI być jednym z elementów opisanych w najnowszej wersji NDK Androida w pliku docs/CPU-ARCH-ABIS.txt. Pamiętaj, że kolejne wersje Android NDK mogą obsługiwać dodatkowe ABI.

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 interfejsem Web API

Wielu deweloperów i aplikacji korzysta z działania klasy android.webkit.WebView [Resources, 8] w swoich interfejsach użytkownika, dlatego implementacja WebView musi być zgodna ze wszystkimi implementacjami Androida. Implementacja Androida open source korzysta z silnika renderowania WebKit do implementowania WebView.

Ponieważ niemożliwe jest opracowanie kompleksowego zestawu testów dla przeglądarki, implementatorzy urządzeń MUSZĄ używać konkretnej kompilacji WebKit w implementacji WebView. Więcej szczegółów:

• WebView MUSI używać kompilacji WebKit 530.17 z gałęzi źródłowej kodu źródłowego Androida w wersji 2.1. Ta kompilacja zawiera określony zestaw funkcji i poprawek zabezpieczeń dla WebView.
• 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/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
  • 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 mogą zawierać niestandardowy ciąg znaków klienta użytkownika w samodzielnej aplikacji przeglądarki. Co więcej, samodzielna przeglądarka MOŻE być oparte na alternatywnej technologii przeglądarki (np. Firefox, Opera itp.). Jednak nawet wtedy, gdy udostępnisz alternatywną aplikację przeglądarki, komponent WebView udostępniany aplikacjom innych firm MUSI być oparty na WebKit, jak opisano powyżej.

Konfiguracja WebView MUSI obejmować obsługę bazy danych HTML5, pamięci podręcznej aplikacji i interfejsów API geolokalizacji [Zasoby, 9]. WebView MUSI obsługiwać tag HTML5 <video> w jakiejś formie. Samodzielna aplikacja przeglądarki (oparta na aplikacji WebKit Browser lub na zamienniku innej firmy) MUSI obsługiwać te same funkcje HTML5, które zostały wymienione w przypadku WebView.

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ą w górnym projekcie open source na Androida [Materiały, 3]. Oto niektóre obszary zgodności:

• Urządzenia NIE MOGĄ zmieniać działania ani znaczenia 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 konkretnego uprawnienia.

Powyższa lista nie jest wyczerpująca, a odpowiedzialnie za zapewnienie zgodności zachowań spoczywa na implementatorach urządzeń. 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.

Pakiet Compatibility Test Suite (CTS) testuje znaczne części platformy pod kątem zgodności behawioralnej, ale nie wszystkie. Implementator jest odpowiedzialny za zapewnienie zgodności z zachowaniem projektu Android Open Source.

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” w poprzednim kodzie źródłowym Androida. Innymi słowy, implementatorzy urządzeń NIE MOGĄ udostępniać nowych interfejsów API ani zmieniać istniejących interfejsów API w wymienionych powyżej przestrzeniach nazw. Implementatorzy urządzeń MOGĄ wprowadzać modyfikacje tylko na potrzeby wewnętrzne, ale te modyfikacje NIE MOGĄ być reklamowane ani w inny sposób udostępniane deweloperom.

Implementatorzy urządzeń MOGĄ dodawać niestandardowe interfejsy API, ale nie mogą umieszczać ich w przestrzeni nazw należącej do innej organizacji 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 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, 10].

Implementacje urządzeń MUSZĄ skonfigurować Dalvik tak, aby przydzielić co najmniej 16 MB pamięci każdej aplikacji na urządzeniach ze średnią lub niską gęstością pikseli. Implementacje urządzeń MUSZĄ skonfigurować Dalvik tak, aby przydzielić co najmniej 24 MB pamięci każdej aplikacji na urządzeniach z ekranami o wysokiej gęstości. Pamiętaj, że implementacje na urządzeniach mogą przydzielić więcej pamięci niż te wartości, ale nie jest to wymagane.

3.8. Zgodność interfejsu

Platforma Androida zawiera interfejsy API dla deweloperów, które umożliwiają im łączenie się z interfejsem użytkownika systemu. Implementacje na urządzeniach MUSZĄ uwzględniać te standardowe interfejsy API w ramach niestandardowych interfejsów użytkownika, które są przez nie tworzone, zgodnie z opisem poniżej.

3.8.1. Widżety

Android definiuje typ komponentu oraz odpowiadający mu interfejs API i cykl życia, które umożliwiają aplikacjom udostępnianie „widżetu aplikacji” użytkownikowi końcowemu [Resources, 11]. Wersja referencyjna Androida Open Source zawiera aplikację Launcher, która zawiera elementy interfejsu użytkownika umożliwiające dodawanie, wyświetlanie i usuwanie widżetów aplikacji na ekranie głównym.

Implementatorzy urządzeń mogą zastąpić domyślny Launcher alternatywą (np. ekranem głównym). Alternatywny program uruchamiający MUSI zawierać wbudowane wsparcie dla widżetów aplikacji i elementy interfejsu użytkownika umożliwiające dodawanie, konfigurowanie, wyświetlanie i usuwanie widżetów bezpośrednio w programie uruchamiającym. Alternatywny Launcher MOŻE pominąć te elementy interfejsu użytkownika. Jeśli jednak pominie je, implementator urządzenia MUSI udostępnić osobną aplikację dostępną w Launcherze, która umożliwia użytkownikom dodawanie, konfigurowanie, wyświetlanie i usuwanie widżetów aplikacji.

3.8.2. Powiadomienia

Android zawiera interfejsy API, które umożliwiają deweloperom powiadamianie użytkowników o istotnych wydarzeniach [Materiały, 12]. Implementatorzy urządzeń MUSZĄ zapewnić obsługę każdej z tak zdefiniowanych klas powiadomień, w tym dźwięków, wibracji, światła i paska stanu.

Ponadto implementacja MUSI prawidłowo renderować wszystkie zasoby (ikony, pliki dźwiękowe itp.) udostępnione w interfejsach API [Zasoby, 13] lub w przewodniku po stylu ikonek na pasku stanu [Zasoby, 14]. Implementatorzy urządzeń MOGĄ zapewnić użytkownikom odmienne wrażenia związane z powiadomieniami niż w przypadku referencyjnej implementacji Androida Open Source. Jednak takie alternatywne systemy powiadomień MUSZĄ obsługiwać istniejące zasoby powiadomień, jak opisano powyżej.

3.8.3. Szukaj

Android zawiera interfejsy API [Resources, 15], które umożliwiają deweloperom wdrażanie wyszukiwarki w aplikacjach 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 tekstu 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.

Implementacje na urządzeniach mogą zawierać alternatywne interfejsy wyszukiwania, ale powinny zawierać twardy lub miękki przycisk wyszukiwania, którego można używać w dowolnym momencie w dowolnej aplikacji, aby wywołać interfejs wyszukiwania. Zachowanie tego przycisku zostało opisane w dokumentacji interfejsu API.

3.8.4. Toasty

Aplikacje mogą używać interfejsu Toast API (zdefiniowanego w sekcji [Zasoby, 16]) do wyświetlania krótkich, niemodalnych ciągów tekstowych, 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.5. 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” [Zasoby, 17]. 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.

4. Zgodność z oprogramowaniem referencyjnym

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

• Kalkulator (dostępny w pakiecie SDK)
• Lunar Lander (dostępny w pakiecie SDK)
• Aplikacje „Aplikacje na Androida” [Zasoby, 18].

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

Implementacje urządzeń MUSZĄ przetestować każdy element menu (w tym wszystkie podmenu) w ramach tych aplikacji testów diagnostycznych:

• ApiDemos (dostępny w pakiecie SDK)
• ManualSmokeTests (uwzględnione w CTS)

Każdy przypadek testowy w wymienionych powyżej aplikacjach MUSI działać prawidłowo w implementacji na urządzeniu.

5. Zgodność z pakietem aplikacji

Implementacje na urządzeniach MUSZĄ instalować i uruchamiać pliki „.apk” na Androida wygenerowane przez narzędzie „aapt” zawarte w oficjalnym pakiecie SDK Androida [Resources, 19].

Implementacje urządzeń NIE MOGĄ rozszerzać formatów plików .apk [Zasoby, 20], manifestu Androida [Zasoby, 21] ani kodu bajtowego Dalvik [Zasoby, 10] w taki sposób, aby uniemożliwić ich prawidłowe instalowanie i uruchamianie na innych zgodnych urządzeniach. Implementatorzy urządzeń powinni używać referencyjnej implementacji Dalvik w górę łańcucha i systemu zarządzania pakietami referencyjnej implementacji.

6. Zgodność multimedialna

Implementacje na urządzeniach MUSZĄ obsługiwać te kodeki multimedialne. Wszystkie te kodeki są udostępniane jako implementacje oprogramowania w preferowanej implementacji Androida z Projektu Android Open Source.

Należy pamiętać, że ani Google, ani Open Handset Alliance nie gwarantują, że te kodeki 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.

Dźwięk
	Nazwa	Koder	Dekodery	Szczegóły	Format pliku/kontenera
	AAC LC/LTP		X	mono lub stereo w dowolnej kombinacji standardowych szybkości transmisji bitów do 160 kb/s i częstotliwości próbkowania od 8 do 48 kHz;	3GPP (.3gp) i MPEG-4 (.mp4, .m4a). Nieobsługiwane są pliki AAC (.aac) w formacie surowym.
	HE-AACv1 (AAC+)		X
	HE-AACv2 (ulepszone AAC+)		X
	AMR-NB	X	X	4,75–12,2 kb/s próbkowane z częstotliwością 8 kHz	3GPP (.3gp)
	AMR-WB		X	9 szybkości od 6,60 kb/s do 23,85 kb/s z próbkowaniem 16 kHz	3GPP (.3gp)
	MP3		X	Mono/Stereo 8–320 kb/s CBR lub VBR	MP3 (.mp3)
	MIDI		X	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). Dozwolone są też formaty RTTTL/RTX (.rtttl, .rtx), OTA (.ota) i iMelody (.imy).
	Ogg Vorbis		X		Ogg (.ogg)
	Menedżer połączeń z partnerami		X	8- i 16-bitowy linearny PCM (szybkości do limitu sprzętowego)	WAVE (.wav)
Obraz
	JPEG	X	X	podstawowa + progresywna
	GIF		X
	PNG	X	X
	BMP		X
Film
	H.263	X	X		pliki 3GPP (.3gp);
	H.264		X		pliki 3GPP (.3gp) i MPEG-4 (.mp4);
	MPEG4 Simple Profile		X		Plik 3GPP (.3gp)

Pamiętaj, że tabela powyżej nie zawiera konkretnych wymagań dotyczących szybkości transmisji danych w przypadku większości kodeków wideo. Dzieje się tak, ponieważ w praktyce obecny sprzęt niekoniecznie obsługuje bitrate, który odpowiada dokładnie wymaganemu bitrate określonemu przez odpowiednie standardy. Zamiast tego implementacje urządzeń powinny obsługiwać najwyższą możliwą szybkość transmisji bitów na sprzęcie, do limitów określonych w specyfikacji.

7. Zgodność z narzędziami dla programistów

Implementacje urządzeń MUSZĄ obsługiwać narzędzia dla programistó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) [Zasoby, 19]
  Implementacje na urządzeniu MUSZĄ obsługiwać wszystkie funkcje adbopisane w pakiecie Android SDK. Domyślnie demon adb na urządzeniu powinien być nieaktywny, ale musi istnieć dostępny dla użytkownika mechanizm włączania mostu debugowania Androida.
• Usługa Dalvik Debug Monitor (znana jako ddms) [Zasoby, 19]
  Implementacje na urządzeniu 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, 22]
  Wdrożenia na urządzeniach MUSZĄ zawierać platformę Monkey i musi być ona dostępna dla aplikacji.

8. Zgodność sprzętowa

Android ma wspierać implementatorów urządzeń w tworzeniu innowacyjnych formatów i konfiguracji. Jednocześnie deweloperzy Androida oczekują, że na wszystkich urządzeniach z Androidem będzie dostępny określony sprzęt, czujniki i interfejsy API. W tej sekcji wymieniono funkcje sprzętowe, które muszą obsługiwać wszystkie urządzenia zgodne z Androidem 2.1.

Jeśli urządzenie zawiera określony komponent sprzętowy, który ma odpowiedni interfejs API dla deweloperów zewnętrznych, implementacja urządzenia MUSI wdrażać ten interfejs zgodnie z określeniami w dokumentacji pakietu Android SDK. Jeśli interfejs API w pakiecie SDK wchodzi w interakcję ze sprzętowym komponentem, który jest oznaczony jako opcjonalny, a urządzenie nie ma tego komponentu:

• definicje klas interfejsów API komponentu,
• zachowania interfejsu API MUSZĄ być zaimplementowane w sposób, który nie wymaga interwencji użytkownika;
• 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.

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ć informacje o konfiguracji sprzętowej za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager.

8.1. Wyświetlacz

Android 2.1 zawiera funkcje, które w pewnych okolicznościach wykonują automatyczne operacje skalowania i przekształcania, aby zapewnić prawidłowe działanie aplikacji innych firm w różnych konfiguracjach sprzętowych [Zasoby, 23]. Urządzenia MUSZĄ prawidłowo implementować te zachowania zgodnie z opisem w tej sekcji.

W przypadku Androida 2.1 te ustawienia są najpopularniejsze:

Typ ekranu	Szerokość (piksele)	Wysokość (w pikselach)	Zakres długości przekątnej (cale)	Grupa rozmiarów ekranu	Grupa gęstości ekranu
QVGA	240	320	2,6–3,0	Mały	Niska
WQVGA	240	400	3,2–3,5	Normalny	Niska
FWQVGA	240	432	3,5–3,8	Normalny	Niska
HVGA	320	480	3,0–3,5	Normalny	Średni
WVGA	480	800	3.3 – 4.0	Normalny	Wysoki
FWVGA	480	854	3,5–4,0	Normalny	Wysoki
WVGA	480	800	4,8–5,5	Duży	Średni
FWVGA	480	854	5,0–5,8	Duży	Średni

Implementacje urządzeń odpowiadające jednej ze standardowych konfiguracji opisanych powyżej MUSZĄ być skonfigurowane tak, aby zgłaszały wskazany rozmiar ekranu aplikacjom za pomocą klasy android.content.res.Configuration [Resources, 24].

Niektóre pakiety .apk mają pliki manifestu, które nie wskazują, że obsługują określony zakres gęstości. Podczas uruchamiania takich aplikacji obowiązują te ograniczenia:

• Implementacje na urządzeniu MUSZĄ interpretować zasoby w pliku .apk, które nie mają atrybutu density, jako domyślnie „medium” (znanego jako „mdpi” w dokumentacji pakietu SDK).
• W przypadku ekranu o „niskiej” gęstości implementacje na urządzeniu MUSZĄ zmniejszyć zasoby o rozdzielczości medium/mdpi o współczynnik 0, 75.
• W przypadku ekranów o „wysokiej” gęstości implementacje na urządzeniach MUSZĄ zwiększać rozmiar zasobów o rozdzielczości medium/mdpi o 1, 5.
• Implementacje urządzeń NIE MOGĄ skalować komponentów w zakresie gęstości, a MOGĄ skalować komponenty dokładnie o te współczynniki w zakresie gęstości.

8.1.2. Niestandardowe konfiguracje wyświetlacza

Konfiguracje wyświetlania, które nie pasują do żadnej z konfiguracji standardowych wymienionych w sekcji 8.1.1, wymagają dodatkowej analizy i działań, aby były zgodne. Implementatorzy urządzeń MUSZĄ skontaktować się z zespołem ds. zgodności z Androidem, jak to opisano w sekcji 12, aby uzyskać klasyfikację w ramach puli rozmiarów ekranu, gęstości i współczynnika skalowania. W przypadku tych informacji implementacje na urządzeniach MUSZĄ je stosować zgodnie z określeniami.

Pamiętaj, że niektóre konfiguracje wyświetlacza (np. bardzo duże lub bardzo małe ekrany oraz niektóre proporcje) są całkowicie niezgodne z Androidem 2.1. Dlatego implementatorzy urządzeń powinni jak najszybciej skontaktować się z zespołem ds. zgodności z Androidem.

8.1.3. Dane dotyczące wyświetleń

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

8.2. Klawiatura

Implementacje na urządzeniu:

• MUSI zawierać obsługę mechanizmu zarządzania danymi wejściowymi (który pozwala deweloperom zewnętrznym tworzyć mechanizmy zarządzania danymi wejściowymi, np.klawiaturę ekranową) zgodnie z informacjami na stronie developer. android.com.
• Musisz udostępnić co najmniej 1 implementację klawiatury ekranowej (niezależnie od tego, czy jest dostępna klawiatura fizyczna)
• 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, 24] (czyli QWERTY lub 12 klawiszy).

8.3. Nawigacja bezdotykowa

Implementacje na urządzeniu:

• MOŻNA pominąć opcje nawigacji bezdotykowej (czyli można pominąć kulkę, pad lub koło)
• MUSI podać prawidłową wartość dla atrybutu android.content.res.Configuration.navigation [Resources, 24]

8.4. Orientacja ekranu

Zgodne urządzenia MUSZĄ obsługiwać dynamiczną orientację ekranu w aplikacji, aby można było wyświetlać obraz 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.

8.5. Dotykowe wprowadzanie danych

Implementacje na urządzeniu:

• Musi mieć ekran dotykowy
• MOŻE mieć pojemnościowy lub oporowy ekran dotykowy
• MUSI raportować wartość android.content.res.Configuration [Resources, 24] odpowiadającą typowi ekranu dotykowego na urządzeniu

8.6. USB

Implementacje na urządzeniu:

• MUSI implementować klienta USB, który można podłączyć do hosta USB za pomocą standardowego portu USB-A.
• NALEŻY zaimplementować Android Debug Bridge przez USB (jak opisano w sekcji 7).
• MUSI implementować specyfikację pamięci masowej USB, aby umożliwić hostowi połączonemu z urządzeniem dostęp do zawartości woluminu /sdcard.
• NALEŻY użyć formatu micro USB po stronie urządzenia
• MOŻE zawierać niestandardowy port po stronie urządzenia, ale w takim przypadku MUSI być dostarczany z kablowym złączem umożliwiającym podłączenie niestandardowego złącza do standardowego portu USB-A.

8.7. Klawisze nawigacyjne

Funkcje Strona główna, Menu i Wstecz są niezbędne w ramach paradygmatu nawigacji w Androidzie. Implementacje na urządzeniu MUSZĄ udostępniać te funkcje użytkownikowi przez cały czas, niezależnie od stanu aplikacji. Te funkcje NALEŻY wdrożyć za pomocą specjalnych przycisków. Mogą być wdrażane za pomocą oprogramowania, gestów, panelu dotykowego itp., ale w takim przypadku muszą być zawsze dostępne i nie mogą zasłaniać ani przeszkadzać w dostępnej powierzchni wyświetlacza aplikacji.

Implementatorzy urządzeń powinni też podać klucz wyszukiwania. Implementatorzy urządzeń mogą również udostępniać klawisze wysyłania i kończenia połączeń telefonicznych.

8,8. Sieci bezprzewodowe

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

Jeśli implementacja urządzenia zawiera daną metodę, dla której pakiet SDK Androida zawiera interfejs API (np. WiFi, GSM lub CDMA), implementacja MUSI obsługiwać ten interfejs API.

Urządzenia mogą wykorzystywać więcej niż jedną formę bezprzewodowej transmisji danych. Urządzenia MOGĄ stosować przewodowe połączenia danych (np. Ethernet), ale MUSZĄ zawierać co najmniej jedną formę połączenia bezprzewodowego, jak opisano powyżej.

8,9. Aparat

Implementacje urządzeń MUSZĄ zawierać kamerę. Dołączona kamera:

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

Implementacje urządzeń MUSZĄ implementować te zachowania w przypadku interfejsów API związanych z kamerą:

1. Jeśli aplikacja nigdy nie wywołała metody android.hardware.Camera.Parameters.setPreviewFormat(int), urządzenie MUSI używać android.hardware.PixelFormat.YCbCr_420_SP do danych podglądu przekazywanych do wywołań zwrotnych aplikacji.
2. Jeśli aplikacja rejestruje instancję android.hardware.Camera.PreviewCallback i system wywołuje metodę onPreviewFrame(), gdy format podglądu to YCbCr_420_SP, dane w byte[] przekazane do onPreviewFrame() muszą być w dalszym ciągu w formacie kodowania NV21. (To format używany domyślnie przez rodzinę urządzeń 7k). Oznacza to, że NV21 MUSI być ustawiony jako domyślny.

Implementacje urządzeń MUSZĄ implementować pełny interfejs Camera API zawarty w dokumentacji pakietu SDK Androida 2.1 [Zasoby, 26]), 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).

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() innych niż te, które są udokumentowane jako stałe w android.hardware.Camera.Parameters, chyba że stałe mają prefiks w postaci ciągu znaków wskazującego nazwę implementacji na urządzeniu. Oznacza to, że implementacje na urządzeniu MUSZĄ obsługiwać wszystkie standardowe parametry aparatu, jeśli tylko sprzęt na to pozwala, i NIE MOGĄ obsługiwać niestandardowych typów parametrów aparatu, chyba że nazwy parametrów wyraźnie wskazują na ich niestandardowy charakter za pomocą prefiksu ciągu znaków.

8.10. Akcelerometr

Implementacje na urządzeniu MUSZĄ zawierać 3-osiowy akcelerometr i MUSZĄ być w stanie przesyłać zdarzenia z częstotliwością co najmniej 50 Hz. System współrzędnych używany przez akcelerometr MUSI być zgodny z systemem współrzędnych czujnika Androida opisanym w interfejsach API Androida (patrz [Materiały, 27]).

8.11. Kompas

Implementacje na urządzeniach MUSZĄ zawierać kompas 3-osiowy i MUSZĄ być w stanie przesyłać zdarzenia z częstotliwością co najmniej 10 Hz. System współrzędnych używany przez kompas MUSI być zgodny z systemem współrzędnych czujnika Androida zdefiniowanym w interfejsie API Androida (patrz [Materiały, 27]).

8.12. GPS

Implementacje urządzeń MUSZĄ zawierać GPS-a i POWINNY zawierać jakąś formę techniki „assisted GPS”, aby zminimalizować czas ustalania pozycji przez GPS.

8.13. Połączenia telefoniczne

Android 2.1 MOŻE być używany na urządzeniach, które nie zawierają sprzętu telefonicznego. Oznacza to, że Android 2.1 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.

Patrz też sekcja 8.8, Sieci bezprzewodowe.

8.14. Pamięć i miejsce na dane

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

Implementacje urządzeń MUSZĄ mieć co najmniej 150 MB pamięci nieulotnej dostępnej dla danych użytkownika. Oznacza to, że partycja /data musi mieć co najmniej 150 MB.

8.15. Pamięć współdzielona aplikacji

Implementacje urządzeń MUSZĄ oferować pamięć współdzieloną dla aplikacji. Udostępnione miejsce na dane musi mieć co najmniej 2 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żywanego wspólnego miejsca na dane, musi ono implementować pamięć masową USB zgodnie z opisem w sekcji 8.6. Pamięć współdzielona musi być zamontowana w systemie plików FAT.

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ólnego miejsca na dane, karta SD w formacie FAT o rozmiary co najmniej 2 GB MUSI być dołączona do urządzenia sprzedawanego użytkownikom i MUSI być zamontowana domyślnie. Jeśli implementacja urządzenia używa wewnętrznego stałego miejsca na dane, aby spełnić ten wymóg, to miejsce na dane MUSI mieć rozmiar co najmniej 2 GB i być zamontowane w /sdcard (lub /sdcard MUSI być symboliczną lokalizacją w dowolnym innym miejscu).

8.16. Bluetooth

Implementacje urządzeń MUSZĄ zawierać nadajnik Bluetooth. Implementacje na urządzeniu MUSZĄ włączyć interfejs Bluetooth API oparty na RFCOMM zgodnie z opisem w dokumentacji pakietu SDK [Resources, 29]. Implementacje urządzeń powinny wdrażać odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX itp.

9. Zgodność z kampaniami Performance Max

Jednym z celów programu zgodności z Androidem jest zapewnienie konsumentom spójnego działania aplikacji. Zgodne implementacje muszą nie tylko zapewniać prawidłowe działanie aplikacji na urządzeniu, ale też odpowiednią wydajność i ogólne dobre wrażenia użytkownika. Implementacje urządzeń MUSZĄ spełniać kluczowe wskaźniki wydajności urządzenia zgodnego z Androidem 2.1 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 MMS/SMS: mniej niż 700 ms AlarmClock: mniej niż 650 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.

10. Zgodność modelu zabezpieczeń

Implementacje urządzeń MUSZĄ stosować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android określonym w dokumentacji referencyjnej API [Zasoby, 28] 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.

10.1. Uprawnienia

Implementacje urządzeń MUSZĄ obsługiwać model uprawnień Androida zgodnie z opisem w dokumentacji dla deweloperów Androida [Zasoby, 28]. 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.*.

10.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, 28].

10.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, 28].

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

12. 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. Pamiętaj, że oprogramowanie Androida na poziomie dostawcy zawiera mechanizm aktualizacji, który spełnia ten wymóg.

Jeśli po wydaniu urządzenia zostanie w nim znaleziony błąd, który wpływa na zgodność aplikacji innych firm, ale w rozsądnym okresie użytkowania urządzenia (określonym w konsultacji z zespołem ds. zgodności Androida), implementator urządzenia MUSI naprawić ten błąd, wprowadzając aktualizację oprogramowania, którą można zastosować zgodnie z opisanym mechanizmem.

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