Definicja zgodności z Androidem 2.2

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

Copyright © 2010, Google Inc. Wszelkie prawa zastrzeżone.
[email protected]

Spis treści

1. Wprowadzenie

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

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 „implementer urządzenia” lub „implementer” to osoba lub organizacja opracowująca rozwiązanie sprzętowe/programowe z Androidem 2.2. „Wdrożenie urządzenia” lub „wdrożenie” to opracowane rozwiązanie sprzętowo-programowe.

Aby być uznawanym za zgodny z Androidem 2.2, implementacja urządzenia musi:

• 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ń 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. Ciągi znaków wersji Androida 2.2: http://source.android.com/docs/compatibility/2.2/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. Animowane tapety: 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. Lista funkcji sprzętowych Androida: http://developer.android.com/reference/android/content/pm/PackageManager.html
24. Obsługa wielu ekranów: http://developer.android.com/guide/practices/screens_support.html
25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
28. Przestrzeń współrzędnych czujnika: http://developer.android.com/reference/android/hardware/SensorEvent.html
29. Informacje o bezpieczeństwie i uprawnieniach w Androidzie: http://developer.android.com/guide/topics/security/security.html
30. Interfejs 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.2 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Ą zawierać kompletne implementacje wszystkich udokumentowanych interfejsów API udostępnionych przez pakiet SDK Androida 2.2 [Zasoby, 4], w tym wszystkie udokumentowane zachowania.

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 opisano „miękkie” interfejsy API oraz zachowania systemu wymagane do zapewnienia zgodności z Androidem 2.2. 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.2 to pole MUSI zawierać wartość całkowitą 8.
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. 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 on być zgodny z tym szablonem: $(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Na przykład: acme/mydevice/generic/generic:2.2/ERC77/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 („_”).
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Ą zezwolić na zastąpienie każdego wzorca intencji, o którym mowa w sekcji 3.2.3.1, 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 przeglądarką

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. Podobnie pełne wrażenia z korzystania z internetu są kluczowe dla użytkowników Androida. Implementacje na urządzeniu MUSZĄ zawierać wersję android.webkit.WebView zgodną z oprogramowaniem Androida w górę łańcucha i MUSZĄ zawierać nowoczesną przeglądarkę obsługującą HTML5, jak opisano poniżej.

3.4.1. Zgodność WebView

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

• Implementacje na urządzeniachandroid.webkit.WebViewmuszą być oparte na kompilacji WebKit 533.1 z gałęzi źródłowej szkieletu Android Open Source dla Androida 2.2. 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/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
  • 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.

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>. Interfejsy HTML5 API, podobnie jak wszystkie interfejsy JavaScript API, MUSZĄ być domyślnie wyłączone w komponencie WebView, chyba że deweloper wyraźnie je włączy za pomocą zwykłych interfejsów Android API.

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 zostanie dostarczona inna aplikacja przeglądarki, 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 przeglądarki WebKit lub na zamienniku innej firmy) POWINNA obsługiwać jak najwięcej funkcji HTML5 [Zasoby, 9]. Implementacje na urządzeniach MUSZĄ obsługiwać geolokalizację HTML5, pamięć podręczną aplikacji i interfejsy API bazy danych oraz tag <video> w samodzielnej aplikacji przeglądarki.

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

W przypadku implementacji urządzeń z ekranami o średniej lub niskiej gęstości pamięci należy skonfigurować Dalvik tak, aby każdej aplikacji przydzielić co najmniej 16 MB pamięci. W przypadku implementacji urządzeń z ekranami o wysokiej gęstości należy skonfigurować Dalvik tak, aby każdej aplikacji przydzielić co najmniej 24 MB pamięci. Pamiętaj, że implementacje na urządzeniu mogą przydzielić więcej pamięci niż te wartości.

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].
• Replica Island (dostępna w Android Market; wymagana tylko w przypadku implementacji urządzeń obsługujących OpenGL ES 2.0)

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Ą w pełni implementować wszystkie interfejsy multimedialne API. Implementacje na urządzeniach MUSZĄ obsługiwać wszystkie kodeki multimedialne opisane poniżej i POWINNY być zgodne z wytycznymi dotyczącymi przetwarzania dźwięku opisanymi poniżej.

6.1. Kodeki multimedialne

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.

6.2. Nagrywanie dźwięku

Gdy aplikacja użyje interfejsu android.media.AudioRecord API, aby rozpocząć nagrywanie strumienia audio, implementacje na urządzeniu POWINNY pobierać próbki i nagrywać dźwięk z użyciem tych zachowań:

• Przetwarzanie redukcji szumów (jeśli jest dostępne) POWINNA być wyłączona.
• Automatyczna kontrola wzmocnienia (jeśli jest dostępna) powinna być wyłączona.
• 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 dźwięku (SPL) wynoszącym 90 dB przy częstotliwości 1000 Hz dawało wartość RMS wynoszącą 5000 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% w zakresie 100–4000 Hz przy poziomie wejściowym 90 dB SPL.

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

6.3. Opóźnienie dźwięku

Opóźnienie dźwięku to ogólnie odstęp między momentem, w którym aplikacja poprosi o odtworzenie lub nagranie dźwięku, a chwilą, w której implementacja urządzenia faktycznie rozpocznie działanie. Wiele klas aplikacji wymaga krótkich opóźnień, aby uzyskać efekty w czasie rzeczywistym, takie jak efekty dźwiękowe czy komunikacja VOIP. Implementacje urządzeń powinny spełniać wszystkie wymagania dotyczące opóźnienia dźwięku opisane w tej sekcji.

Na potrzeby tej sekcji:

• „Opóźnienie wyjścia po zimnym uruchomieniu” to czas od momentu, gdy aplikacja poprosi o odtworzenie dźwięku, do momentu, gdy dźwięk zacznie się odtwarzać, gdy system audio był nieaktywny i wyłączony przed żądaniem.
• „Opóźnienie wyjściowe w stanie gotowości” to przedział czasu od momentu, gdy aplikacja poprosi o odtworzenie dźwięku, do momentu, gdy dźwięk zacznie się odtwarzać, gdy system audio był niedawno używany, ale obecnie jest nieaktywny (czyli nie emituje dźwięku).
• „Ciągła latencja wyjściowa” to przedział czasu między momentem, w którym aplikacja wysyła próbkę do odtworzenia, a momentem, w którym głośnik fizycznie odtwarza odpowiedni dźwięk, gdy urządzenie odtwarza dźwięk
• „Opóźnienie w przyjmowaniu danych z nieaktywnych mikrofonów” to czas od momentu, gdy aplikacja poprosi o nagranie dźwięku, do momentu, gdy pierwszy próbka zostanie przesłana do aplikacji za pomocą funkcji wywołania zwrotnego, gdy system audio i mikrofon były nieaktywne i wyłączone przed wysłaniem żądania.
• „Ciągła opóźnienie wejścia” występuje, gdy występuje dźwięk otoczenia i próbka odpowiadająca temu dźwiękowi jest dostarczana do aplikacji do nagrywania za pomocą wywołania zwrotnego, gdy urządzenie jest w trybie nagrywania.

Zgodnie z powyższymi definicjami implementacje urządzeń powinny mieć te właściwości:

• opóźnienie wyjścia „na zimno” nie większe niż 100 ms;
• opóźnienie wyjścia „na ciepło” nie większe niż 10 ms;
• ciągłe opóźnienie wyjścia na poziomie 45 ms lub mniej
• opóźnienie na wejściu „na zimno” nieprzekraczające 100 ms,
• ciągłe opóźnienie wejścia na poziomie 50 ms lub mniej,

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

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

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ć dokładne informacje o konfiguracji sprzętowej za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) w klasie android.content.pm.PackageManager. [Materiały, 23]

8.1. Wyświetlacz

Android 2.2 zawiera funkcje, które w pewnych okolicznościach wykonują automatyczne operacje skalowania i przekształcania, aby aplikacje innych firm działały w stosunkowo dobry sposób w różnych konfiguracjach sprzętowych [Zasoby, 24]. Urządzenia MUSZĄ prawidłowo implementować te zachowania zgodnie z opisem w tej sekcji.

W przypadku Androida 2.2 te ustawienia wyświetlania są najczęstsze:

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 w sposób opisany w sekcji 13, aby uzyskać klasyfikację dla 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.2. 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, 26].

8.1.4. Zadeklarowana obsługa ekranu

Aplikacje mogą wskazywać obsługiwane rozmiary ekranu za pomocą atrybutu <supports-screens> w pliku AndroidManifest.xml. Implementacje urządzeń MUSZĄ prawidłowo obsługiwać deklarowane przez aplikacje wsparcie małych, średnich i dużych ekranów zgodnie z opisem w dokumentacji pakietu SDK Androida.

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, 25] (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, 25].

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, 25] odpowiadającą typowi ekranu dotykowego na urządzeniu
• NALEŻY obsługiwać wskaźniki śledzone niezależnie, jeśli ekran dotykowy obsługuje wiele wskaźników

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.
• NALEŻY wdrożyć obsługę specyfikacji pamięci masowej USB (aby można było uzyskać dostęp do pamięci wymiennej lub stałej na urządzeniu z komputera hosta).

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ć tylny aparat. Dołączony 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.

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.2 [Zasoby, 27], 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(), 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.

Implementacje urządzeń MOGĄ zawierać przedni aparat. Jeśli jednak implementacja urządzenia zawiera przedni aparat, interfejs API aparatu zaimplementowany na urządzeniu NIE MOŻE domyślnie używać przedniego aparatu. Oznacza to, że interfejs API aparatu w Androidzie 2.2 jest przeznaczony tylko do obsługi tylnych kamer, a implementacje na urządzeniach NIE MOGĄ ponownie używać ani przeciążać interfejsu API, aby działał na przednim aparacie (jeśli taki istnieje). Pamiętaj, że wszystkie niestandardowe interfejsy API dodane przez implementatorów urządzeń w celu obsługi przednich kamer muszą być zgodne z sekcjami 3.5 i 3.6. Jeśli na przykład niestandardowa podklasa android.hardware.Camera lub Camera.Parameters jest udostępniana w celu obsługi przednich kamer, nie może ona znajdować się w dotychczasowej przestrzeni nazw, zgodnie z sekcjami 3.5 i 3.6. Pamiętaj, że umieszczenie przedniego aparatu nie spełnia wymogu, aby urządzenia miały tylny aparat.

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, jak to opisano w interfejsach API Androida (patrz [Materiały, 28]).

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

8.12. GPS

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

8.13. Połączenia telefoniczne

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

Oprócz spełnienia powyższych wymagań implementacje urządzeń POWINNY mieć co najmniej 128 MB pamięci dostępnej dla jądra i przestrzeni użytkownika, oprócz pamięci przeznaczonej dla komponentów sprzętowych, które nie są kontrolowane przez jądro. Urządzenia powinny mieć co najmniej 1 GB pamięci nieulotnej dostępnej dla danych użytkownika. Pamiętaj, że w przyszłej wersji Androida te wyższe wymagania staną się minimalnymi wymaganiami. Zalecamy, aby implementacje urządzeń spełniały te wymagania już teraz, ponieważ w przeciwnym razie mogą nie być zgodne z przyszłą wersją Androida.

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, być sformatowane jako FAT i zamontowane w /sdcard (lub /sdcardMUSI to być symboliczny link do fizycznej lokalizacji, jeśli jest zamontowany 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.

8.16. Bluetooth

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

Pakiet Compatibility Test Suite zawiera przypadki obejmujące podstawową obsługę interfejsu Bluetooth RFCOMM API na Androidzie. Bluetooth jest jednak protokołem komunikacji między urządzeniami, więc nie można go w pełni przetestować za pomocą testów jednostkowych wykonywanych na jednym urządzeniu. W związku z tym implementacje urządzeń MUSZĄ przejść procedurę testowania Bluetooth z udziałem człowieka opisaną w Załączniku A.

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 zgodnego z Androidem 2.2 urządzenia 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 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, 29] 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 [Zasoby, 29]. 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, 29].

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, 29].

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

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.

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.2 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 [email protected].

Załącznik A. Procedura testowania Bluetooth

Pakiet Compatibility Test Suite zawiera przypadki obejmujące podstawową obsługę interfejsu Bluetooth RFCOMM API na Androidzie. Bluetooth jest jednak protokołem komunikacji między urządzeniami, więc nie można go w pełni przetestować za pomocą testów jednostkowych wykonywanych na jednym urządzeniu. W związku z tym implementacje urządzeń MUSZĄ przejść procedurę testowania Bluetooth z udziałem człowieka opisaną poniżej.

Procedura testowania opiera się na przykładowej aplikacji BluetoothChat zawartej w drzewie projektu Androida typu open source. Procedura wymaga użycia 2 urządzeń:

• wdrożenie urządzenia docelowego z kompilacją oprogramowania do przetestowania.
• osobna implementacja urządzenia, która jest już znana jako zgodna, oraz model z testowanej implementacji urządzenia, czyli „znana dobra” implementacja urządzenia.

W procedurze testowania te urządzenia są nazywane odpowiednio „kandydatem” i „sprawdzonym”.

Konfiguracja i instalacja

1. Utwórz plik BluetoothChat.apk za pomocą polecenia „make samples” w drzewie kodu źródłowego Androida.
2. Zainstaluj plik BluetoothChat.apk na urządzeniu, które działa prawidłowo.
3. Zainstaluj plik BluetoothChat.apk na urządzeniu docelowym.

Testowanie sterowania Bluetooth przez aplikacje

1. Uruchom BluetoothChat na urządzeniu docelowym, gdy Bluetooth jest wyłączony.
2. Sprawdź, czy urządzenie docelowe włącza Bluetooth lub wyświetla użytkownikowi okno z prośbą o włączenie tej funkcji.

Testowanie parowania i komunikacji

1. Uruchom aplikację Bluetooth Chat na obu urządzeniach.
2. Upewnij się, że znane i sprawne urządzenie jest wykrywalne w BluetoothChat (za pomocą menu).
3. Na urządzeniu docelowym wyszukaj urządzenia Bluetooth w BluetoothChat (za pomocą menu) i sparuj je z urządzeniem, które działa prawidłowo.
4. Wyślij co najmniej 10 wiadomości z każdego urządzenia i sprawdź, czy drugie urządzenie je poprawnie odbiera.
5. Zamknij aplikację BluetoothChat na obu urządzeniach, naciskając przycisk Strona główna.
6. Odłącz każde urządzenie od drugiego, używając aplikacji Ustawienia.

Testowanie parowania i komunikacji w odwrotnym kierunku

1. Uruchom aplikację Bluetooth Chat na obu urządzeniach.
2. Urządzenie docelowe musi być wykrywalne w BluetoothChat (za pomocą menu).
3. Na urządzeniu, które działa prawidłowo, wyszukaj urządzenia Bluetooth w BluetoothChat (za pomocą menu) i sparuj z wybranym urządzeniem.
4. Wyślij 10 wiadomości z każdego urządzenia i sprawdź, czy drugie urządzenie je odbiera prawidłowo.
5. Zamknij aplikację Bluetooth Chat na obu urządzeniach, naciskając kilka razy przycisk Wstecz, aby otworzyć program uruchamiający.

Testowanie ponownych uruchomień

1. Uruchom ponownie aplikację Bluetooth Chat na obu urządzeniach.
2. Wyślij 10 wiadomości z każdego urządzenia i sprawdź, czy drugie urządzenie je odbiera prawidłowo.

Uwaga: w przypadku niektórych testów powyżej sekcja testu kończy się po kliknięciu przycisku Strona główna, a w innych – przycisku Wstecz. Te testy nie są zbędne ani opcjonalne: ich celem jest sprawdzenie, czy interfejs API Bluetooth i jego stos działają prawidłowo zarówno wtedy, gdy aktywności są wyraźnie zamykane (przez naciśnięcie przez użytkownika przycisku Wstecz, który wywołuje metodę finish()), jak i wówczas, gdy są niejawnie wysyłane do tła (przez naciśnięcie przez użytkownika przycisku Strona główna). Każda sekwencja testów MUSI być wykonywana zgodnie z opisem.