Definicja zgodności z Androidem 2.1

Prawa autorskie © 2010, Google Inc. Wszelkie prawa zastrzeżone.
kompatybilność@android.com

1. Wstęp

W dokumencie tym wyszczególniono wymagania, jakie muszą zostać spełnione, aby telefony komórkowe były kompatybilne z systemem Android 2.1.

Użycie zwrotów „musi”, „nie może”, „wymagane”, „należy”, „nie powinno”, „powinno”, „nie powinno”, „zalecane”, „może” i „opcjonalne” jest zgodne ze standardem IETF zdefiniowane w RFC2119 [ Zasoby, 1 ].

W niniejszym dokumencie „wykonawca urządzenia” lub „wykonawca” to osoba lub organizacja opracowująca rozwiązanie sprzętowe/programowe z systemem Android 2.1. „Implementacja urządzenia” lub „implementacja” to opracowane w ten sposób rozwiązanie sprzętowe/programowe.

Aby uznać za zgodne z systemem Android 2.1, implementacje urządzeń:

  • MUSI spełniać wymagania przedstawione w niniejszej definicji zgodności, w tym wszelkie dokumenty włączone przez odniesienie.
  • MUSI przejść najnowszą wersję pakietu testów zgodności Androida (CTS) dostępną w momencie zakończenia wdrażania oprogramowania urządzenia. (CTS jest dostępny w ramach projektu Android Open Source [ Zasoby, 2 ].) CTS testuje wiele, ale nie wszystkie, komponenty opisane w tym dokumencie.

Jeżeli ta definicja lub CTS jest cicha, niejednoznaczna lub niekompletna, wykonawca urządzenia jest odpowiedzialny za zapewnienie zgodności z istniejącymi implementacjami. Z tego powodu projekt Android Open Source [ Zasoby, 3 ] jest zarówno referencyjną, jak i preferowaną implementacją Androida. Zdecydowanie zachęca się osoby wdrażające urządzenia, aby opierały swoje implementacje na „starszym” kodzie źródłowym dostępnym w ramach projektu Android Open Source. Chociaż niektóre komponenty można hipotetycznie zastąpić alternatywnymi implementacjami, praktyka ta jest zdecydowanie odradzana, ponieważ zdanie testów CTS stanie się znacznie trudniejsze. Obowiązkiem wdrażającego jest zapewnienie pełnej zgodności behawioralnej ze standardową implementacją Androida, w tym i poza pakietem testów zgodności. Na koniec należy pamiętać, że niniejszy dokument wyraźnie zabrania niektórych zamian i modyfikacji komponentów.

2. Zasoby

  • IETF RFC2119 Poziomy wymagań: http://www.ietf.org/rfc/rfc2119.txt
  • Omówienie programu zgodności z systemem Android: http://source.android.com/compatibility/index.html
  • Projekt Android Open Source: http: //source.android.com/
  • Definicje i dokumentacja API: http://developer.android.com/reference/packages.html
  • Informacje o uprawnieniach systemu Android: http://developer.android.com/reference/android/Manifest.permission. html
  • Odniesienie do android.os.Build: http://developer.android.com/reference/android/os/Build.html
  • Ciągi dozwolonych wersji Androida 2.1: http://source.Android.com/docs/compatibility/2.1/versions .html
  • klasa android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  • HTML5: http://www.whatwg.org/specs/web-apps/current-work/
  • specyfikacja maszyny wirtualnej
  • wielostronicowej/
  • Dalvik: dostępna w kodzie źródłowym Androida, pod adresem dalvik/docs
  • AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  • Powiadomienia: http://developer.android.com /guide/topics/ui/notifiers/notifications.html
  • Zasoby aplikacji: http://code.google.com/android/reference/available-resources.html
  • Przewodnik po stylu ikon na pasku stanu: http://developer.android.com/ Guide/practices/ui_guideline /icon_design.html#statusbarstructure
  • Menedżer wyszukiwania: http://developer.android.com/reference/android/app/SearchManager.html
  • Tosty: http://developer.android.com/reference/android/widget /Toast.html
  • Animowane tapety: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  • Aplikacje dla Androida: http://code.google.com/p/apps-for-android
  • Informacje dokumentacja narzędzia (dla adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  • Opis pliku apk dla Androida: http://developer.android.com/guide/topics/fundamentals .html
  • Pliki manifestu: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  • Narzędzie do testowania Monkey: https://developer.android.com/studio/test/other-testing-tools/ małpa
  • obsługująca wiele ekranów: http://developer.android.com/guide/practices/screens_support.html
  • android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration. html
  • android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  • android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera. html
  • Przestrzeń współrzędnych czujnika: http://developer.android.com/reference/android/hardware/SensorEvent.html
  • Informacje dotyczące zabezpieczeń i uprawnień systemu Android: http://developer.android.com/guide/topics/security/security.html
  • Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html
  • Wiele z tych zasobów pochodzi bezpośrednio lub pośrednio z zestawu SDK systemu Android 2.1 i będzie funkcjonalnie identyczne z informacjami zawartymi w dokumentacji tego zestawu SDK . W każdym przypadku, gdy niniejsza Definicja Zgodności lub Zestaw Testów Zgodności nie zgadza się z dokumentacją SDK, dokumentacja SDK jest uważana za wiarygodną. Wszelkie szczegóły techniczne podane w odnośnikach zawartych powyżej są uznawane za część niniejszej Definicji Zgodności.

    3. Oprogramowanie

    Platforma Android zawiera zestaw zarządzanych interfejsów API, zestaw natywnych interfejsów API oraz zbiór tak zwanych „miękkich” interfejsów API, takich jak interfejsy API systemu Intent i interfejsy API aplikacji internetowych. W tej sekcji szczegółowo opisano twarde i miękkie interfejsy API, które są integralną częścią kompatybilności, a także pewne inne istotne zachowania techniczne i interfejsy użytkownika. Implementacje urządzeń MUSZĄ spełniać wszystkie wymagania zawarte w tej sekcji.

    3.1. Zgodność z zarządzanym interfejsem API

    Zarządzane środowisko wykonawcze (oparte na Dalvik) jest głównym narzędziem dla aplikacji na Androida. Interfejs programowania aplikacji systemu Android (API) to zestaw interfejsów platformy Android udostępnianych aplikacjom działającym w zarządzanym środowisku maszyny wirtualnej. Implementacje urządzeń MUSZĄ zapewniać kompletne implementacje, w tym wszystkie udokumentowane zachowania, dowolnego udokumentowanego interfejsu API udostępnianego przez pakiet SDK systemu Android 2.1 [ Zasoby, 4 ].

    Implementacje urządzeń NIE MOGĄ pomijać żadnych zarządzanych interfejsów API, zmieniać interfejsów API ani podpisów, odbiegać od udokumentowanego zachowania ani zawierać zakazu wykonywania operacji, z wyjątkiem przypadków wyraźnie dozwolonych w niniejszej definicji zgodności.

    3.2. Zgodność z miękkim interfejsem API

    Oprócz zarządzanych interfejsów API z sekcji 3.1, system Android zawiera także znaczący „miękki” interfejs API przeznaczony wyłącznie do środowiska wykonawczego w postaci takich elementów, jak intencje, uprawnienia i podobne aspekty aplikacji systemu Android, których nie można wymusić w aplikacji czas kompilacji. W tej sekcji szczegółowo opisano „miękkie” interfejsy API i zachowania systemu wymagane do zapewnienia zgodności z systemem Android 2.1. Implementacje urządzeń MUSZĄ spełniać wszystkie wymagania przedstawione w tej sekcji.

    3.2.1. Uprawnienia

    Osoby wdrażające urządzenia MUSZĄ obsługiwać i egzekwować wszystkie stałe uprawnień zgodnie z dokumentacją na stronie odniesienia do uprawnień [ Zasoby, 5 ]. Należy pamiętać, że w sekcji 10 wymieniono dodatkowe wymagania związane z modelem zabezpieczeń systemu Android.

    3.2.2. Parametry kompilacji Interfejsy

    API systemu Android zawierają szereg stałych w klasie android.os.Build [ Zasoby, 6 ], które mają opisywać bieżące urządzenie. Aby zapewnić spójne, znaczące wartości we wszystkich implementacjach urządzeń, poniższa tabela zawiera dodatkowe ograniczenia dotyczące formatów tych wartości, z którymi MUSZĄ być zgodne implementacje urządzeń.

    Parametr Komentarze
    android.os.Build.VERSION.RELEASE Wersja aktualnie działającego systemu Android w formacie czytelnym dla człowieka. To pole MUSI zawierać jedną z wartości ciągu znaków zdefiniowanych w [ Resources, 7 ].
    android.os.Build.VERSION.SDK Wersja aktualnie działającego systemu Android, w formacie dostępnym dla kodu aplikacji innych firm. Dla Androida 2.1 to pole MUSI mieć wartość całkowitą. 7.
    android.os.Build.VERSION.INCREMENTAL Wartość wybrana przez realizatora urządzenia, określająca konkretną wersję aktualnie działającego systemu Android, w formacie czytelnym dla człowieka. Tej wartości NIE WOLNO ponownie używać w przypadku różnych kompilacji wysyłanych do użytkowników końcowych. Typowym zastosowaniem tego pola jest wskazanie, który numer kompilacji lub identyfikator zmiany kontroli źródła został użyty do wygenerowania kompilacji. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
    android.os.Build.BOARD Wartość wybrana przez realizatora urządzenia, identyfikująca konkretny sprzęt wewnętrzny używany przez urządzenie, w formacie czytelnym dla człowieka. Możliwym zastosowaniem tego pola jest wskazanie konkretnej wersji płytki zasilającej urządzenie. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
    android.os.Build.BRAND Wartość wybrana przez realizatora urządzenia, identyfikująca nazwę firmy, organizacji, osoby itp., która wyprodukowała urządzenie, w formacie czytelnym dla człowieka. Możliwym zastosowaniem tego pola jest wskazanie producenta OEM i/lub przewoźnika, który sprzedał urządzenie. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
    android.os.Build.DEVICE Wartość wybrana przez realizatora urządzenia, identyfikująca konkretną konfigurację lub wersję korpusu (czasami nazywaną „projektem przemysłowym”) urządzenia. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
    android.os.Build.FINGERPRINT Ciąg znaków, który jednoznacznie identyfikuje tę kompilację. POWINIEN być w miarę czytelny dla człowieka. MUSI być zgodny 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żeli inne pola zawarte w powyższym szablonie zawierają spacje, NALEŻY je zastąpić znakiem podkreślenia ASCII („_”) w odcisku palca.
    android.os.Build.HOST Ciąg znaków, który jednoznacznie identyfikuje hosta, na którym zbudowano kompilację, w formacie czytelnym dla człowieka. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
    android.os.Build.ID Identyfikator wybrany przez osobę wdrażającą urządzenie w celu odniesienia się do konkretnej wersji, w formacie czytelnym dla człowieka. To pole może być takie samo jak pole android.os.Build.VERSION.INCREMENTAL, ale POWINNO być wartością na tyle znaczącą, aby użytkownicy końcowi mogli rozróżnić kompilacje oprogramowania. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
    android.os.Build.MODEL Wartość wybrana przez realizatora urządzenia zawierająca nazwę urządzenia znaną użytkownikowi końcowemu. POWINNA to być ta sama nazwa, pod którą urządzenie jest sprzedawane i sprzedawane użytkownikom końcowym. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
    android.os.Build.PRODUCT Wartość wybrana przez realizatora urządzenia, zawierająca nazwę rozwojową lub nazwę kodową urządzenia. MUSI być czytelny dla człowieka, ale niekoniecznie jest przeznaczony do przeglądania przez użytkowników końcowych. Nie ma żadnych wymagań dotyczących konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).
    android.os.Build.TAGS Rozdzielana przecinkami lista tagów wybranych przez osobę wdrażającą urządzenie, które dodatkowo wyróżniają kompilację. Na przykład „bez znaku, debugowanie”. To pole NIE MOŻE mieć wartości null ani być pustym ciągiem znaków („”), ale pojedynczy tag (taki jak „release”) jest w porządku.
    android.os.Build.TIME Wartość reprezentująca znacznik czasu wystąpienia kompilacji.
    android.os.Build.TYPE Wartość wybrana przez realizatora urządzenia, określająca konfigurację środowiska wykonawczego kompilacji. To pole POWINNO mieć jedną z wartości odpowiadających trzem 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 konkretnego formatu tego pola, z wyjątkiem tego, że NIE MOŻE ono mieć wartości null ani pustego ciągu znaków („”).

    3.2.3. Zgodność intencji

    Android korzysta z intencji, aby osiągnąć luźno powiązaną integrację między aplikacjami. W tej sekcji opisano wymagania związane ze wzorcami intencji, które MUSZĄ być honorowane przez implementacje urządzeń. Przez „honorowany” rozumie się, że osoba wdrażająca urządzenie MUSI udostępnić działanie lub usługę Androida, która określa pasujący filtr intencji oraz wiąże się i implementuje prawidłowe zachowanie dla każdego określonego wzorca intencji.

    3.2.3.1. Założenia podstawowej aplikacji

    Projekt Android upstream definiuje szereg podstawowych aplikacji, takich jak dialer telefoniczny, kalendarz, książka kontaktów, odtwarzacz muzyki i tak dalej. Osoby wdrażające urządzenia MOGĄ zastąpić te aplikacje wersjami alternatywnymi.

    Jednakże wszelkie takie alternatywne wersje MUSZĄ uwzględniać te same wzorce zamierzeń, które zapewnił wcześniejszy projekt. Na przykład, jeśli urządzenie zawiera alternatywny odtwarzacz muzyki, musi nadal przestrzegać wzorca intencji wydanego przez aplikacje innych firm w celu wybrania utworu.

    Następujące aplikacje są uważane za podstawowe aplikacje systemu Android:

    • Zegar na biurku
    • Przeglądarka
    • Kalendarz Kalkulator
    • Aparat
    • Kontakty
    • E
    • -mail
    • Galeria
    • GlobalSearch
    • Launcher
    • LivePicker (czyli aplikacja selektora tapet na żywo; 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
    • Ustawienia
    • telefonu
    • Rejestrator dźwięku

    Podstawowe aplikacje systemu Android obejmują różne składniki Aktywności lub Usługi, które są uważane za „publiczne”. Oznacza to, że atrybut „android:exported” może być nieobecny lub może mieć wartość „true”.

    Dla każdej Aktywności lub Usługi zdefiniowanej w jednej z podstawowych aplikacji systemu Android, która nie jest oznaczona jako niepubliczna za pomocą atrybutu android:exported o wartości „false”, implementacje urządzenia MUSZĄ zawierać komponent tego samego typu implementujący ten sam filtr intencji wzorce jako podstawowa aplikacja systemu Android.

    Innymi słowy, implementacja urządzenia MOŻE zastąpić podstawowe aplikacje systemu Android; jeśli jednak tak się stanie, implementacja urządzenia MUSI obsługiwać wszystkie wzorce intencji zdefiniowane przez każdą zastępowaną podstawową aplikację systemu Android.

    3.2.3.2. Zastępowanie intencji

    Ponieważ Android jest platformą rozszerzalną, osoby wdrażające urządzenia MUSZĄ pozwolić na zastąpienie każdego wzorca intencji zdefiniowanego w podstawowych aplikacjach systemowych przez aplikacje innych firm. Domyślnie pozwala na to projekt open source Androida; osobom wdrażającym urządzenia NIE WOLNO przypisywać specjalnych uprawnień aplikacjom systemowym do korzystania z tych wzorców zamierzeń ani uniemożliwiać aplikacjom stron trzecich wiązania się z tymi wzorcami i przejmowania nad nimi kontroli. Zakaz ten obejmuje w szczególności, ale nie ogranicza się do wyłączenia interfejsu użytkownika „Chooser”, który pozwala użytkownikowi wybierać pomiędzy wieloma aplikacjami, z których wszystkie obsługują ten sam wzorzec zamiarów.

    Uwaga: ta sekcja została zmodyfikowana przez Erratum EX6580.

    3.2.3.3.

    Przestrzenie

    nazw intencji

    Osoby wdrażające urządzenia NIE MOGĄ zawierać żadnego komponentu systemu Android, który honoruje jakiekolwiek nowe wzorce intencji lub intencji rozgłaszania przy użyciu AKCJI, KATEGORII lub innego ciągu kluczy w przestrzeni nazw android.*. Osoby wdrażające urządzenia NIE MOGĄ dołączać żadnych komponentów Androida, które honorują jakiekolwiek nowe wzorce intencji lub intencji rozgłaszania przy użyciu AKCJI, KATEGORII lub innego ciągu klucza w obszarze pakietu należącym do innej organizacji. Osoby wdrażające urządzenia NIE MOGĄ zmieniać ani rozszerzać żadnych wzorców intencji używanych przez podstawowe aplikacje wymienione w sekcji 3.2.3.1.

    Zakaz ten jest analogiczny do zakazu określonego dla klas języka Java w sekcji 3.6.

    3.2.3.4. Intencje rozgłaszania

    Aplikacje innych firm wykorzystują platformę do rozgłaszania określonych intencji w celu powiadamiania ich o zmianach w środowisku sprzętu lub oprogramowania. Urządzenia kompatybilne z Androidem MUSZĄ nadawać publiczne intencje transmisji w odpowiedzi na odpowiednie zdarzenia systemowe. Intencje rozgłaszania są opisane w dokumentacji zestawu SDK.

    3.3. Zgodność natywnego interfejsu API

    Kod zarządzany działający w Dalvik może wywoływać kod natywny dostarczony w pliku .apk aplikacji jako plik ELF .so skompilowany dla odpowiedniej architektury sprzętowej urządzenia. Implementacje urządzeń MUSZĄ obejmować obsługę kodu działającego w środowisku zarządzanym w celu wywołania kodu natywnego przy użyciu standardowej semantyki Java Native Interface (JNI). Następujące interfejsy API MUSZĄ być dostępne dla kodu natywnego:

    • libc (biblioteka C)
    • libm (biblioteka matematyczna)
    • Interfejs JNI
    • libz (kompresja Zlib)
    • liblog (logowanie w systemie Android)
    • Minimalna obsługa C++
    • Obsługa OpenGL, jak opisano poniżej
    • Implementacje urządzeń MUSZĄ

    obsługiwać OpenGL ES 1.0 . Urządzenia pozbawione akceleracji sprzętowej MUSZĄ implementować OpenGL ES 1.0 przy użyciu programowego modułu renderującego. Implementacje urządzeń POWINNY implementować tyle OpenGL ES 1.1, ile obsługuje sprzęt urządzenia. Implementacje urządzeń POWINNY zapewniać implementację OpenGL ES 2.0, jeśli sprzęt jest w stanie zapewnić rozsądną wydajność w przypadku tych interfejsów API.

    Biblioteki te MUSZĄ być kompatybilne ze źródłami (tj. kompatybilne z nagłówkami) i kompatybilne binarnie (dla danej architektury procesora) z wersjami dostarczonymi w Bionic przez projekt Android Open Source. Ponieważ implementacje Bionic nie są w pełni kompatybilne z innymi implementacjami, takimi jak biblioteka GNU C, osoby wdrażające urządzenia POWINNY używać implementacji Androida. Jeśli osoby wdrażające urządzenia korzystają z innej implementacji tych bibliotek, MUSZĄ zapewnić zgodność nagłówków, plików binarnych i zachowania.

    Implementacje urządzeń MUSZĄ dokładnie raportować natywny interfejs binarny aplikacji (ABI) obsługiwany przez urządzenie za pośrednictwem interfejsu API android.os.Build.CPU_ABI . ABI MUSI być jednym z wpisów udokumentowanych w najnowszej wersji Androida NDK, w pliku docs/CPU-ARCH-ABIS.txt . Należy pamiętać, że dodatkowe wersje zestawu Android NDK mogą wprowadzać obsługę dodatkowych interfejsów ABI.

    Zgodność kodu natywnego jest wyzwaniem. Z tego powodu należy powtórzyć, że BARDZO zachęca się twórców urządzeń do korzystania z wcześniejszych implementacji bibliotek wymienionych powyżej, aby zapewnić kompatybilność.

    3.4. Zgodność interfejsu API sieci Web

    Wielu programistów i aplikacji opiera się na zachowaniu klasy android.webkit.WebView [ Zasoby, 8 ] w swoich interfejsach użytkownika, dlatego implementacja WebView musi być kompatybilna we wszystkich implementacjach Androida. Implementacja Android Open Source wykorzystuje silnik renderujący WebKit do implementacji WebView.

    Ponieważ nie jest możliwe opracowanie kompleksowego zestawu testów dla przeglądarki internetowej, osoby wdrażające urządzenia MUSZĄ używać określonej wcześniejszej kompilacji WebKit w implementacji WebView. W szczególności:

    • WebView MUSI korzystać z wersji 530.17 WebKit z nadrzędnego drzewa Android Open Source dla systemu Android 2.1. Ta kompilacja zawiera określony zestaw poprawek funkcjonalności i zabezpieczeń dla WebView.
    • Ciąg agenta użytkownika zgłaszany przez WebView MUSI mieć następujący 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ąg $(VERSION) MUSI być taki sam jak wartość dla android.os.Build.VERSION.RELEASE
      • Wartość ciągu $(LOCALE) MUSI być zgodna z konwencjami ISO dotyczącymi kodu kraju i języka oraz POWINNA odnosić się do aktualnie skonfigurowanych ustawień regionalnych urządzenia
      • Wartość ciągu $(MODEL) MUSI być taka sama jak wartość dla android.os.Build.MODEL
      • Wartość ciągu $(BUILD) MUSI być taka sama jak wartość dla android.os.Build.ID
    Implementacje
      • android.os.Build.ID

    MOGĄ dostarczać niestandardowy ciąg agenta użytkownika w samodzielnej aplikacji przeglądarki. Co więcej, samodzielna przeglądarka MOŻE być oparta na alternatywnej technologii przeglądarki (takiej jak Firefox, Opera itp.). Jednak nawet jeśli dostarczona zostanie alternatywna aplikacja przeglądarki, komponent WebView udostępniany aplikacjom innych firm MUSI być oparty na WebKit, jak powyżej.

    Konfiguracja WebView MUSI obejmować obsługę bazy danych HTML5, pamięci podręcznej aplikacji i interfejsów API geolokalizacji [ Zasoby, 9 ]. Widok WebView MUSI zawierać obsługę tagu HTML5 <video> w jakiejś formie. Samodzielna aplikacja przeglądarki (niezależnie od tego, czy jest oparta na wcześniejszej aplikacji przeglądarki WebKit, czy na zamienniku innej firmy) MUSI obsługiwać te same funkcje HTML5, które wymieniono dla WebView.

    3.5. Zgodność behawioralna API

    Zachowania każdego typu API (zarządzanego, miękkiego, natywnego i sieciowego) muszą być spójne z preferowaną implementacją projektu open source dla Androida [ Zasoby, 3 ]. Niektóre konkretne obszary kompatybilności to:

    • Urządzenia NIE MOGĄ zmieniać zachowania ani znaczenia standardowego celu.
    • Urządzenia NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia określonego typu komponentu systemu (takiego jak usługa, działanie, dostawca treści itp.).
    • Urządzenia NIE MOGĄ
    • zmieniać cyklu życia lub semantyki cyklu życia.
    • zmienić semantykę konkretnego uprawnienia

    Powyższa lista nie jest wyczerpująca, a obowiązek zapewnienia zgodności behawioralnej spoczywa na osobach wdrażających urządzenia. Z tego powodu osoby wdrażające urządzenia POWINNY używać kodu źródłowego dostępnego w ramach projektu Android Open Source, tam gdzie to możliwe, zamiast ponownie wdrażać znaczące części systemu.

    Zestaw testów zgodności (CTS) testuje znaczną część platformy pod kątem zgodności behawioralnej, ale nie wszystkie. Obowiązkiem realizatora jest zapewnienie zgodności behawioralnej z projektem Android Open Source.

    3.6. Przestrzenie nazw API

    Android postępuje zgodnie z konwencjami przestrzeni nazw pakietów i klas zdefiniowanymi w języku programowania Java. Aby zapewnić zgodność z aplikacjami innych firm, twórcom urządzeń NIE WOLNO wprowadzać żadnych zabronionych modyfikacji (patrz poniżej) w następujących przestrzeniach nazw pakietów:

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

    Zabronione modyfikacje obejmują:

    • Implementacje urządzeń MUSZĄ NIE modyfikuj publicznie dostępnych interfejsów API na platformie Android, zmieniając jakiekolwiek podpisy metod lub klas lub usuwając klasy lub pola klas.
    • Osoby wdrażające urządzenia MOGĄ modyfikować podstawową implementację interfejsów API, ale takie modyfikacje NIE MOGĄ wpływać na określone zachowanie i podpis w języku Java jakichkolwiek publicznie udostępnianych interfejsów API.
    • Implementatorom urządzeń NIE WOLNO dodawać żadnych publicznie dostępnych elementów (takich jak klasy lub interfejsy albo pola lub metody do istniejących klas lub interfejsów) do powyższych interfejsów API.

    „Element publicznie eksponowany” to dowolny konstrukt, który nie jest ozdobiony znacznikiem „@hide” w kodzie źródłowym Androida. Innymi słowy, twórcom urządzeń NIE WOLNO ujawniać nowych interfejsów API ani zmieniać istniejących interfejsów API w przestrzeniach nazw wymienionych powyżej. Osoby wdrażające urządzenia MOGĄ wprowadzać modyfikacje wyłącznie do użytku wewnętrznego, ale modyfikacje te NIE MOGĄ być reklamowane ani w żaden inny sposób udostępniane programistom.

    Osoby wdrażające urządzenia MOGĄ dodawać niestandardowe interfejsy API, ale żadne takie interfejsy API NIE MOGĄ znajdować się w przestrzeni nazw będącej własnością innej organizacji lub odnoszącej się do innej organizacji. Na przykład twórcom urządzeń NIE WOLNO dodawać interfejsów API do com.google.* lub podobnej przestrzeni nazw; może to zrobić tylko Google. Podobnie Google NIE WOLNO dodawać interfejsów API do przestrzeni nazw innych firm.

    Jeśli osoba wdrażająca urządzenie zaproponuje ulepszenie jednej z powyższych przestrzeni nazw pakietów (na przykład poprzez dodanie przydatnej nowej funkcjonalności do istniejącego interfejsu API lub dodanie nowego interfejsu API), osoba wdrażająca POWINNA odwiedzić stronę source.android.com i rozpocząć proces wprowadzania zmian i zgodnie z informacjami zawartymi na tej stronie.

    Należy pamiętać, że powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku programowania Java; ta sekcja ma po prostu na celu wzmocnienie tych konwencji i uczynienie ich wiążącymi poprzez włączenie ich do niniejszej definicji zgodności.

    3.7. Zgodność z maszyną wirtualną

    Implementacje urządzeń MUSZĄ obsługiwać pełną specyfikację kodu bajtowego Dalvik Executable (DEX) i semantykę maszyny wirtualnej Dalvik [ Zasoby, 10 ].

    Implementacje urządzeń MUSZĄ skonfigurować Dalvik tak, aby przydzielał co najmniej 16 MB pamięci dla każdej aplikacji na urządzeniach z ekranami sklasyfikowanymi jako średniej lub niskiej gęstości. Implementacje urządzeń MUSZĄ skonfigurować Dalvik tak, aby przydzielał co najmniej 24 MB pamięci dla każdej aplikacji na urządzeniach z ekranami sklasyfikowanymi jako o dużej gęstości. Należy pamiętać, że implementacje urządzeń MOGĄ przydzielać więcej pamięci niż podano w podanych liczbach, ale nie jest to wymagane.

    3.8. Zgodność interfejsu użytkownika

    Platforma Android zawiera kilka interfejsów API dla programistów, które umożliwiają programistom podłączenie się do interfejsu użytkownika systemu. Implementacje urządzeń MUSZĄ uwzględniać te standardowe interfejsy API interfejsu użytkownika w niestandardowych interfejsach użytkownika, które opracowują, jak wyjaśniono poniżej.

    3.8.1. Widżety

    Android definiuje typ komponentu oraz odpowiedni interfejs API i cykl życia, który umożliwia aplikacjom udostępnianie „AppWidget” użytkownikowi końcowemu [ Zasoby, 11 ]. Wersja referencyjna Android Open Source zawiera aplikację Launcher zawierającą elementy interfejsu użytkownika umożliwiające użytkownikowi dodawanie, przeglądanie i usuwanie AppWidgets z ekranu głównego.

    Osoby wdrażające urządzenia MOGĄ zastąpić alternatywę dla referencyjnego programu uruchamiającego (tj. ekranu głównego). Alternatywne programy uruchamiające POWINNY zawierać wbudowaną obsługę AppWidgets i udostępniać elementy interfejsu użytkownika umożliwiające dodawanie, konfigurowanie, przeglądanie i usuwanie AppWidgets bezpośrednio w programie uruchamiającym. Alternatywne programy uruchamiające MOGĄ pomijać te elementy interfejsu użytkownika; jeśli jednak zostaną one pominięte, osoba wdrażająca urządzenie MUSI udostępnić oddzielną aplikację dostępną z poziomu programu uruchamiającego, która umożliwi użytkownikom dodawanie, konfigurowanie, przeglądanie i usuwanie AppWidgets.

    3.8.2. Powiadomienia

    Android zawiera interfejsy API, które pozwalają programistom powiadamiać użytkowników o ważnych wydarzeniach [ Zasoby, 12 ]. Osoby wdrażające urządzenia MUSZĄ zapewnić obsługę każdej tak zdefiniowanej klasy powiadomień; w szczególności: dźwięki, wibracje, światło i pasek stanu.

    Dodatkowo implementacja MUSI poprawnie renderować wszystkie zasoby (ikony, pliki dźwiękowe itp.) przewidziane w interfejsach API [ Zasoby, 13 ] lub w przewodniku po stylach ikon paska stanu [ Zasoby, 14 ]. Osoby wdrażające urządzenia MOGĄ zapewniać użytkownikowi alternatywne środowisko powiadomień niż zapewniane przez referencyjną implementację Android Open Source; jednakże takie alternatywne systemy powiadamiania MUSZĄ obsługiwać istniejące zasoby powiadamiania, jak powyżej.

    w systemie Android zawiera interfejsy API [ Zasoby, 15 ], które umożliwiają programistom włączanie wyszukiwania do swoich aplikacji i udostępnianie danych aplikacji w globalnym wyszukiwaniu systemowym. Ogólnie rzecz biorąc, ta funkcjonalność składa się z jednego, ogólnosystemowego interfejsu użytkownika, który umożliwia użytkownikom wprowadzanie zapytań, wyświetla sugestie podczas wpisywania przez użytkownika i wyświetla wyniki. Interfejsy API systemu Android umożliwiają programistom ponowne wykorzystanie tego interfejsu do wyszukiwania w ich własnych aplikacjach oraz dostarczanie wyników do wspólnego interfejsu użytkownika wyszukiwania globalnego.

    Implementacje urządzeń MUSZĄ obejmować pojedynczy, współdzielony, ogólnosystemowy interfejs użytkownika wyszukiwania, umożliwiający wyświetlanie sugestii w czasie rzeczywistym w odpowiedzi na dane wprowadzone przez użytkownika. Implementacje urządzeń MUSZĄ implementować interfejsy API, które umożliwiają programistom ponowne wykorzystanie tego interfejsu użytkownika w celu zapewnienia wyszukiwania we własnych aplikacjach. Implementacje urządzeń MUSZĄ implementować interfejsy API, które umożliwiają aplikacjom innych firm dodawanie sugestii do pola wyszukiwania, gdy jest ono uruchamiane w trybie wyszukiwania globalnego. Jeśli nie są zainstalowane żadne aplikacje innych firm korzystające z tej funkcjonalności, domyślnym zachowaniem POWINNO być wyświetlanie wyników i sugestii wyszukiwarki internetowej.

    Implementacje urządzeń MOGĄ zawierać alternatywne interfejsy użytkownika wyszukiwania, ale POWINNY zawierać twardy lub miękki dedykowany przycisk wyszukiwania, którego można użyć w dowolnej chwili w dowolnej aplikacji w celu wywołania struktury wyszukiwania, z zachowaniem opisanym w dokumentacji API.

    3.8.4. Tosty

    Aplikacje mogą używać interfejsu API „Toast” (zdefiniowanego w [ Resources, 16 ]), aby wyświetlać użytkownikowi końcowemu krótkie, niemodalne ciągi znaków, które znikają po krótkim czasie. Implementacje urządzeń MUSZĄ wyświetlać toasty z aplikacji dla użytkowników końcowych w jakiś dobrze widoczny sposób.

    3.8.5. Live Wallpapers

    Android definiuje typ komponentu oraz odpowiedni interfejs API i cykl życia, który pozwala aplikacjom udostępniać użytkownikowi końcowemu jedną lub więcej „Live Wallpapers” [ Zasoby, 17 ]. Animowane tapety to animacje, wzory i podobne obrazy z ograniczonymi możliwościami wprowadzania danych, które są wyświetlane jako tapeta za innymi aplikacjami.

    Uważa się, że sprzęt umożliwia niezawodne uruchamianie animowanych tapet, jeśli umożliwia uruchamianie wszystkich animowanych tapet, bez ograniczeń funkcjonalności, z rozsądną liczbą klatek na sekundę i bez negatywnego wpływu na inne aplikacje. Jeśli ograniczenia sprzętowe powodują awarie, nieprawidłowe działanie tapet i/lub aplikacji, nadmierne zużycie energii procesora lub baterii albo działanie z niedopuszczalnie niską liczbą klatek na sekundę, uznaje się, że sprzęt nie jest w stanie uruchomić tapety na żywo. Na przykład niektóre animowane tapety mogą wykorzystywać kontekst Open GL 1.0 lub 2.0 do renderowania swojej zawartości. Animowana tapeta nie będzie działać niezawodnie na sprzęcie, który nie obsługuje wielu kontekstów OpenGL, ponieważ użycie animowanej tapety w kontekście OpenGL może powodować konflikt z innymi aplikacjami, które również korzystają z kontekstu OpenGL.

    Implementacje urządzeń umożliwiających niezawodne uruchamianie animowanych tapet, jak opisano powyżej, POWINNY implementować animowane tapety. Implementacje urządzeń, w przypadku których stwierdzono, że nie działają niezawodnie animowane tapety, jak opisano powyżej, NIE MOGĄ implementować animowanych tapet.

    4. Zgodność oprogramowania referencyjnego

    Osoby wdrażające urządzenia MUSZĄ przetestować zgodność implementacji przy użyciu następujących aplikacji typu open source:

    • Kalkulator (zawarty w pakiecie SDK)
    • Lunar Lander (zawarty w pakiecie SDK)
    • Aplikacje „Aplikacje dla Androida” [ Zasoby, 18 ].

    Każda powyższa aplikacja MUSI zostać uruchomiona i działać poprawnie w trakcie implementacji, aby implementacja została uznana za zgodną.

    Dodatkowo implementacje urządzeń MUSZĄ testować każdą pozycję menu (w tym wszystkie podmenu) każdej z tych aplikacji do testów dymu:

    • ApiDemos (zawarte w SDK)
    • ManualSmokeTests (zawarte w CTS)

    Każdy przypadek testowy w powyższych aplikacjach MUSI działać poprawnie na urządzeniu realizacja.

    5. Zgodność pakietów aplikacji

    Implementacje urządzeń MUSZĄ instalować i uruchamiać pliki „.apk” systemu Android wygenerowane przez narzędzie „aapt” zawarte w oficjalnym zestawie SDK systemu Android [ Zasoby, 19 ].

    Implementacje urządzeń NIE MOGĄ rozszerzać formatów .apk [ Resources, 20 ], Android Manifest [ Resources, 21 ] lub Dalvik bytecode [ Resources, 10 ] w sposób uniemożliwiający prawidłową instalację i działanie tych plików na innych kompatybilnych urządzeniach . Osoby wdrażające urządzenia POWINNY używać referencyjnej implementacji Dalvik i systemu zarządzania pakietami implementacji referencyjnej.

    6. Kompatybilność multimediów

    Implementacje urządzeń MUSZĄ obsługiwać następujące kodeki multimedialne. Wszystkie te kodeki są dostarczane jako implementacje oprogramowania w preferowanej implementacji Androida z projektu Android Open Source.

    Należy pamiętać, że ani firma Google, ani organizacja Open Handset Alliance nie zapewniają, że te kodeki nie są obciążone patentami stron trzecich. Osobom zamierzającym używać tego kodu źródłowego w sprzęcie lub oprogramowaniu informuje się, że implementacje tego kodu, w tym w oprogramowaniu typu open source lub shareware, mogą wymagać licencji patentowych od odpowiednich posiadaczy patentów.

    Nazwa
    audio
    Koder Szczegóły dekodera Format pliku/kontenera
    AAC LC/LTP   X Treści mono/stereo w dowolnej kombinacji standardowych przepływności do 160 kbps i częstotliwości próbkowania od 8 do 48 kHz 3GPP (.3gp) i MPEG-4 (.mp4, .m4a). Brak obsługi surowego AAC (.aac)
    HE-AACv1 (AAC+)   X
    HE-AACv2 (ulepszony AAC+)   X
    AMR-NB X X 4,75 do 12,2 kb/s próbkowanie przy 8 kHz 3GPP (.3gp)
    AMR-WB   X 9 szybkości od 6,60 kbit/s do 23,85 kbit/s przy próbkowaniu przy 16 kHz 3GPP (.3gp)
    MP3   X Mono/Stereo 8–320 Kb/s, stała (CBR) lub zmienna przepływność (VBR) MP3 (.mp3)
    MIDI   X MIDI typ 0 i 1. DLS wersja 1 i 2. XMF i Mobile XMF. Obsługa formatów dzwonka RTTTL/RTX, OTA i IMELODY Typ 0 i 1 (.mid, .xmf, .mxmf). Również rtttl/rtx (.rtttl, .rtx), OTA (.OTA) i IMELODY (.IMY)
    OGG VORBIS   X   OGG (.ogg)
    PCM   X 8- i 16-bitowe liniowe PCM (prędkości do limitu fali sprzętowej (.wav)
    obraz
    JPEG x x baza+progresywna  
    GIF-y   X   
    Png x x   
    BMP   X   
    Wideo
    H.263 x x   Pliki 3GPP (.3GP)
    H.264   X   Pliki 3GPP (.3GP) i MPEG-4 (.mp4)
    MPEG4 Prosty profil   X   Plik 3GPP (.3GP)

    Należy zauważyć, że powyższa tabela nie wymienia określonych wymagań dotyczących przepustowości dla większości kodeków wideo. Powodem tego jest to, że w praktyce obecny sprzęt urządzeń niekoniecznie obsługuje transmisję transmisji, które dokładnie mapują do wymaganych transmisji pod określonymi przez odpowiednie standardy. Zamiast tego implementacje urządzeń powinny obsługiwać najwyższą praktyczną przepustkę na sprzęcie, aż do limitów określonych przez specyfikacje.

    7. Implementacje urządzeń kompatybilności narzędzi programisty

    muszą obsługiwać narzędzia programistów Androida dostarczone w systemie Android SDK. W szczególności urządzenia kompatybilne z Androidem muszą być kompatybilne z:

    • Android Debug Bridge (znany jako ADB) [ Resources, 19 ]
      Implementacje urządzeń muszą obsługiwać wszystkie funkcje adb , jak udokumentowano w systemie Android SDK. Demon adb po stronie urządzenia powinien być domyślnie nieaktywny, ale musi istnieć mechanizm dostępny dla użytkownika do włączenia mostu debugowego Androida.
    • Dalvik Debug Monitor Service (znany jako DDMS) [ Resources, 19 ]
      Implementacje urządzeń muszą obsługiwać wszystkie funkcje ddms , jak udokumentowano w systemie Android SDK. Ponieważ ddms korzysta z adb , obsługa ddms powinna być domyślnie nieaktywna, ale musi być obsługiwana za każdym razem, gdy użytkownik aktywuje most debugowania Androida, jak wyżej.
    • Monkey [ Resources, 22 ]
      Implementacje urządzeń muszą zawierać Framework Monkey i udostępnić je do korzystania z aplikacji.

    8. Kompatybilność sprzętowa

    Android ma na celu obsługę implementerów urządzeń tworzących innowacyjne czynniki i konfiguracje formularzy. Jednocześnie programiści Android oczekują pewnego sprzętu, czujników i interfejsów API na całym urządzeniu z Androidem. W tej sekcji wymieniono funkcje sprzętowe, które muszą obsługiwać wszystkie urządzenia kompatybilne z Androidem 2.1.

    Jeśli urządzenie zawiera konkretny komponent sprzętowy, który ma odpowiedni interfejs API dla twórców stron trzecich, implementacja urządzenia musi zaimplementować ten interfejs API zgodnie z definicją w dokumentacji Android SDK. Jeśli interakcja interakcji API w SDK oddziałuje z komponentem sprzętowym, który jest opcjonalny, a implementacja urządzenia nie posiada tego komponentu:

    • Definicje klas interfejsów API komponentu muszą być prezentowane
    • Zachowania interfejsu API muszą być wdrażane jako No-OPS w jakiś rozsądny sposób
    • Metody API muszą zwrócić wartości zerowe, w których dozwolone przez metody dokumentacji SDK
    • Metody API muszą zwrócić implementacje klas NO-OP, w których wartości zerowe nie są dozwolone przez dokumentację

    SDK -Urządzenia telefoniczne, te interfejsy API muszą być zaimplementowane jako rozsądne NO-OPS.

    Implementacje urządzeń muszą dokładne zgłoszenie dokładnych informacji o konfiguracji sprzętowej za pomocą metod getSystemAvailableFeatures() i hasSystemFeature(String) na klasie android.content.pm.PackageManager .

    8.1. Wyświetl

    Android 2.1 zawiera w niektórych okolicznościach urządzenia, które wykonują pewne automatyczne operacje skalowania i transformacji, aby zapewnić, że aplikacje stron trzecich działają dość dobrze w różnych konfiguracjach sprzętowych [ zasoby, 23 ]. Urządzenia muszą prawidłowo wdrożyć te zachowania, jak szczegółowo opisano w tej sekcji.

    Dla Androida 2.1 są to najczęstsze konfiguracje wyświetlania:

    szerokość Grupa WVGA 480 5,0 Duże podłożem
    typu ekranu (piksele) Wysokość (piksele) Zakres długości przekątnej (cale)gęstości grupy ekranowej
    QVGA 240 320 2,6 - 3,0 Małe niskie
    WQVGA 240 400 3,2 - 3,5 Normalne niskie niskie
    FWQVGA 240 432 3,5 - 3,8 Normalne niskie
    HVGA 320 480 3,0 - 3,5 Normalna Średnica
    WVGA 480 800 3,3 - 4,0 Normalne Wysokie
    FWVGA 480 854 3,5 - 4,0 Normalne Wysokie
    800 4,8 - 5,5 Duża medium
    FWVGA 480 854- 5,8dla dużych

    podłoży Odpowiednio jednej ze standardowych konfiguracji powyżej należy skonfigurować do zgłaszania wskazanego rozmiaru ekranu aplikacji za pośrednictwem klasy android.content.res.Configuration [ Zasoby, 24 ].

    Niektóre pakiety .APK mają manifesty, które nie identyfikują ich jako wspierające określony zakres gęstości. Podczas uruchamiania takich aplikacji obowiązują następujące ograniczenia:

    • Implementacje urządzeń muszą interpretować zasoby w. AAPK, które nie mają kwalifikatora gęstości jako domyślnego „Medium” (znanego jako „MDPI” w dokumentacji SDK.)
    • Podczas pracy na „niskiej” gęstości gęstości „niskiej” Ekran, implementacje urządzeń muszą zmniejszać środkowe/MDPI aktywów o współczynnik 0,75.
    • Podczas działania na ekranie „wysokiej” gęstości implementacje urządzeń muszą skalować środkowe/MDPI aktywów o współczynnik 1,5.
    • Implementacje urządzeń nie mogą skalować zasobów w zakresie gęstości i muszą skalować zasoby dokładnie tymi czynnikami między zakresami gęstości.

    8.1.2. Nieprzestkowo konfiguracje wyświetlania

    wyświetlania konfiguracji, które nie pasują do jednej ze standardowych konfiguracji wymienionych w rozdziale 8.1.1, wymagają dodatkowego rozpatrzenia i kompatybilności. Wdrażacze urządzeń muszą skontaktować się z zespołem zgodności z Androidem zgodnie z rozdziałem 12 w celu uzyskania klasyfikacji kadłuba wielkości, gęstości i współczynnika skalowania. Po dostarczeniu tych informacji implementacje urządzeń muszą je zaimplementować zgodnie z określonymi.

    Należy pamiętać, że niektóre konfiguracje wyświetlania (takie jak bardzo duże lub bardzo małe ekrany i niektóre współczynniki kształtu) są zasadniczo niezgodne z Androidem 2.1; Dlatego wdrażacze urządzeń są zachęcani do skontaktowania się z zespołem zgodności z Androidem jak najwcześniej w procesie rozwoju.

    8.1.3. Display Metrycs

    Wdrożenie urządzeń muszą zgłaszać prawidłowe wartości dla wszystkich wskaźników wyświetlania zdefiniowanych na android.util.DisplayMetrics [ Resources, 25 ].

    8.2.

    Implementacje urządzeń

    klawiatury

    :

    • MUSI zawierać obsługę frameworka zarządzania wejściowym (która pozwala programistom stron trzecich tworzyć silniki zarządzania wejściową - IE Miękką klawiaturę), jak szczegółowo opisano w
    • programie Klawiatura twarda jest obecna)
    • może zawierać dodatkowe implementacje klawiatury miękkiej
    • mogą zawierać klawiaturę sprzętową
    • nie może zawierać klawiatury sprzętowej, która nie pasuje do jednego z formatów określonych w android.content.res.Configuration.keyboard [ Zasoby, 24 ] (to znaczy, QWERTY lub 12-klawisz)

    8.3.

    Implementacje urządzeń

    do nawigacji nieuchronnej

    :

    • może pominąć opcje nawigacji bez dotyku (to znaczy może pominąć trackball, d-pad lub koło)
    • musi zgłosić prawidłową wartość dla android.content.res.Configuration.navigation [ Zasoby, 24 ]

    8.4.

    Urządzenia kompatybilne z

    orientacją ekranu

    muszą obsługiwać dynamiczną orientację według aplikacji do orientacji ekranu portretowego lub krajobrazu.

    Oznacza to, że urządzenie musi szanować żądanie aplikacji dotyczące określonej orientacji ekranu. Implementacje urządzeń mogą wybrać orientację portretową lub krajobrazową jako domyślną.

    Urządzenia muszą zgłosić prawidłową wartość bieżącej orientacji urządzenia, za każdym razem, gdy jest zapytany za pośrednictwem Android.Content.Res.Configuration.orientacja, Android.View.display.getorientation () lub inne interfejsy API.

    8,5.

    Implementacje urządzeń

    wejściowych z ekranem dotykowym

      :
    • Musi mieć ekran dotykowy
    • może mieć pojemnikowy lub rezystancyjny ekran dotykowy
    • musi zgłosić wartość android.content.res.Configuration [ Zasoby, 24 ] odzwierciedlające odpowiadające typowi konkretnego ekranu dotykowego na urządzeniu

    8.6.

    Implementacje urządzeń

    USB

      :
    • Musi zaimplementować klienta USB, podłączony do hosta USB ze standardowym portem USB-A
    • musi zaimplementować most debugowania Androida przez USB (jak opisano w sekcji 7),
    • musi zaimplementować specyfikację pamięci masowej USB, aby umożliwić podłączanie hosta podłączania hosta Do urządzenia, aby uzyskać dostęp do zawartości głośności /SDCard,
    • powinien użyć współczynnika formularza mikro USB po stronie urządzenia
    • , może zawierać niestandardowy port po stronie urządzenia Standardowy port USB-A

    8.7. Klucze nawigacyjne

    Funkcje domu, menu i tyłu są niezbędne dla paradygmatu nawigacji Androida. Implementacje urządzeń muszą udostępniać te funkcje przez cały czas, niezależnie od stanu aplikacji. Funkcje te powinny być zaimplementowane za pomocą dedykowanych przycisków. Można je zaimplementować przy użyciu oprogramowania, gestów, panelu dotykowego itp., Ale jeśli tak, muszą być zawsze dostępne i nie są niejasne ani nie zakłócają dostępnego obszaru wyświetlania aplikacji.

    Wdrażacze urządzeń powinni również dostarczyć dedykowany klucz wyszukiwania. Wdrażacze urządzeń mogą również dostarczać klucze wysyłania i końcowych dla połączeń telefonicznych.

    8.8.

    Implementacje urządzeń

    bezprzewodowych sieci danych

    muszą obejmować obsługę bezprzewodowych szybkich sieci danych. W szczególności implementacje urządzeń muszą zawierać obsługę co najmniej jednego standardu danych bezprzewodowych zdolnych do 200 kbit/s lub większych. Przykłady technologii, które spełniają ten wymóg, obejmują Edge, HSPA, EV-DO, 802.11g itp.

    Jeśli implementacja urządzenia obejmuje szczególną modalność, dla której Android SDK zawiera API (to znaczy Wi-Fi, GSM lub CDMA), Wdrożenie musi obsługiwać API.

    Urządzenia mogą zaimplementować więcej niż jedną formę łączności danych bezprzewodowych. Urządzenia mogą wdrażać przewodową łączność danych (takich jak Ethernet), ale mimo to muszą zawierać co najmniej jedną formę łączności bezprzewodowej, jak wyżej.

    8.9.

    Implementacje urządzeń

    aparatu

    muszą obejmować aparat. Dołączony aparat:

    • Musi mieć rozdzielczość co najmniej 2 megapikseli
    • , powinna mieć sprzętowy automatyczny skupienie, albo oprogramowanie automatyczne skupione na sterowniku aparatu (przezroczyste dla oprogramowania aplikacyjnego)
    • może mieć ustalone skupienie lub EDOF (rozszerzona głębokość pola) Sprzęt
    • może zawierać błysk. Jeśli aparat zawiera lampę błyskową, lampa lampowa nie może być oświetlona, ​​podczas 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 FLASH_MODE_AUTO lub FLASH_MODE_ON atrybutów z Obiekt Camera.Parameters . Należy pamiętać, że to ograniczenie nie dotyczy wbudowanej aplikacji aparatu systemowego, ale tylko do aplikacji stron trzecich za pomocą Camera.PreviewCallback .

    Implementacje urządzeń muszą zaimplementować następujące zachowania dla interfejsów API związanych z kamerą:

    1. jeśli aplikacja nigdy nie nazywała Android.hardware.camera.parameters.setpreviewformat (INT), to urządzenie musi używać Android.Hardware.Pixelformat.ycbcr_420_sp dla dostarczonych danych podgląd Oddzwonienia aplikacji.
    2. Jeśli aplikacja rejestruje instancję android.hardware.camera.previewCallback, a system wywołuje metodę onPreviewFrame (), gdy format podglądu jest YCBCR_420_SP, dane w BYTE [] przekazane do OnPreViewFrame () muszą być w formacie NV21. (Jest to format używany natywnie przez rodzinę sprzętową 7K.) To znaczy, NV21 musi być domyślnie.

    Implementacje urządzeń muszą zaimplementować pełny interfejs API aparatu zawarty w dokumentacji SDK z Androidem 2.1 [ Zasoby, 26 ]), niezależnie od tego, czy urządzenie obejmuje sprzętowe autofokus lub inne możliwości. Na przykład kamery, które nie mają autofokusa, muszą nadal wywoływać zarejestrowany system android.hardware.Camera.AutoFocusCallback (mimo że nie ma to znaczenia dla kamery spoza AutoFocus.) Implementacje urządzeń muszą

    rozpoznać i honorować każdą nazwę parametrów zdefiniowaną jako stała na stałym na stałym android.hardware.Camera.Parameters klasa, jeśli podstawowy sprzęt obsługuje funkcję. Jeśli sprzęt urządzenia nie obsługuje funkcji, interfejs API musi zachowywać się zgodnie z udokumentowaniem. I odwrotnie, implementacje urządzeń nie mogą honorować ani rozpoznawać stałych sznurków przekazywanych na metodę android.hardware.Camera.setParameters() inną niż te udokumentowane jako stałe na android.hardware.Camera.Parameters , chyba że stałe są prefiksowane z ciągiem wskazującym na ciąg, co wskazuje na to, że stał Nazwa implementarza urządzenia. Oznacza to, że implementacje urządzeń muszą obsługiwać wszystkie standardowe parametry aparatu, jeśli sprzęt pozwala na to, i nie mogą obsługiwać niestandardowych rodzajów parametrów aparatu, chyba że nazwy parametrów są wyraźnie wskazane przez prefiks ciągów jako niestandardowy.

    8.10.

    Implementacje urządzeń

    akcelerometru

    muszą zawierać 3-osiowy akcelerometr i muszą być w stanie dostarczać zdarzenia przy 50 Hz lub więcej. Układ współrzędnych stosowany przez akcelerometr musi być zgodny z układem współrzędnych czujników Androida, jak szczegółowo opisano w interfejsach API z Androidem (patrz [ Zasoby, 27 ]).

    8.11.

    Implementacje urządzeń

    kompasu

    muszą zawierać 3-osiowy kompas i muszą być w stanie dostarczyć zdarzenia 10 Hz lub więcej. Układ współrzędnych stosowany przez kompas musi być zgodny z układem współrzędnych czujników Androida, zgodnie z definicją API Androida (patrz [ Zasoby, 27 ]).

    8.12.

    Implementacje urządzeń

    GPS

    muszą zawierać GPS i powinny zawierać jakąś formę techniki „wspomaganego GPS”, aby zminimalizować czas blokady GPS.

    8.13. Telefonia

    Android 2.1 może być używana na urządzeniach, które nie zawierają sprzętu telefonii. Oznacza to, że Android 2.1 jest kompatybilny z urządzeniami, które nie są telefonami. Jeśli jednak implementacja urządzenia obejmuje telefonię GSM lub CDMA, musi wdrożyć pełne wsparcie interfejsu API dla tej technologii. Implementacje urządzeń, które nie zawierają sprzętu telefonii, muszą zaimplementować pełne interfejsy API jako NO-OPS.

    Patrz także sekcja 8.8, bezprzewodowe sieci danych.

    8.14.

    Implementacje urządzeń

    pamięci i pamięci

    muszą mieć co najmniej 92 MB pamięci dostępnych dla jądra i przestrzeni użytkowników. 92 MB musi być oprócz dowolnej pamięci poświęconej komponentom sprzętowym, takim jak radio, pamięć itd. Nie jest pod kontrolą jądra.

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

    Uwaga: Ta sekcja została zmodyfikowana przez Erratum EX6580.

    8.15.

    Wdrażania urządzeń

    pamięci współdzielonej aplikacji

    muszą oferować udostępnioną pamięć dla aplikacji. Udostępniona pamięć musi mieć co najmniej 2 GB.

    Implementacje urządzeń należy domyślnie skonfigurować z udostępnioną pamięcią zamontowaną „poza pudełkiem”. Jeśli udostępniona pamięć nie jest zamontowana na ścieżce Linux /sdcard , wówczas urządzenie musi zawierać symboliczny link Linux z /sdcard do rzeczywistego punktu montażowego.

    Implementacje urządzeń muszą egzekwować zgodnie z dokumentatem zgody na android.permission.WRITE_EXTERNAL_STORAGE w tej wspólnej pamięci. Udostępniona pamięć musi być zapisana przez każdą aplikację, która uzyskuje to pozwolenie.

    Implementacje urządzeń mogą mieć sprzęt do dostępnego przez użytkownika pamięci wymiennej, takiej jak bezpieczna karta cyfrowa. Alternatywnie, implementacje urządzeń mogą przydzielić pamięć wewnętrzną (nie do remontu) jako udostępnioną pamięć dla aplikacji.

    Niezależnie od formy używanej pamięci współdzielonej, pamięć udostępniona musi zaimplementować masę masy USB, jak opisano w sekcji 8.6. Jak wysyłano z pudełka, udostępniane przechowywanie musi być zamontowane za pomocą grubego systemu plików.

    Ilustrujące jest rozważenie dwóch typowych przykładów. Jeśli implementacja urządzenia zawiera gniazdo karty SD w celu spełnienia wymogu pamięci współdzielonej, należy dołączyć do użytku lub większego w formacie tłuszczowej SD lub większej, należy dołączyć użytkownikom, i musi zostać zamontowana. Alternatywnie, jeśli implementacja urządzenia używa wewnętrznej stałej pamięci, aby zaspokoić ten wymóg, pamięć musi mieć 2 GB lub większy i zamontowany na /sdcard (lub /sdcard musi być symbolicznym linkiem do fizycznej lokalizacji, jeśli jest zamontowana gdzie indziej.

    ) : Ta sekcja została dodana przez Erratum EX6580.

    8.16.

    Implementacje urządzeń

    Bluetooth

    muszą obejmować transceiver Bluetooth. Implementacje urządzeń muszą włączyć interfejs Bluetooth oparty na RFCOMM, jak opisano w dokumentacji SDK [ Zasoby, 29 ]. Implementacje urządzeń powinny zaimplementować odpowiednie profile Bluetooth, takie jak A2DP, AVRCP, OBEX itp., W odpowiednich dla urządzenia.

    Uwaga: Ta sekcja została dodana przez Erratum EX6580.

    9. Kompatybilność z wydajnością

    Jednym z celów programu kompatybilności Androida jest umożliwienie konsumentom spójnego wrażenia aplikacji. Kompatybilne implementacje muszą zapewnić nie tylko, że aplikacje po prostu działają poprawnie na urządzeniu, ale także to, że robią to z rozsądną wydajnością i ogólną dobrą obsługą. Implementacje urządzeń muszą spełniać kluczowe wskaźniki wydajności urządzenia kompatybilnego z Android 2.1 zdefiniowanego w poniższej tabeli:

    Metryczne progowe komentarze
    do uruchomienia aplikacji Poniższe aplikacje powinny uruchomić w określonym czasie.
    • Przeglądarka: mniej niż 1300 ms
    • MMS/SMS: mniej niż 700 ms
    • Clock: mniej niż 650 ms
    Czas uruchamiania jest mierzony jako całkowity czas na zakończenie ładowania domyślnej aktywności aplikacji, w tym czas potrzebny na rozpoczęcie procesu Linux, załadowanie Androida Pakuj do maszyny wirtualnej Dalvik i zadzwoń do OnCreate.
    Jednoczesne aplikacje po uruchomieniu wielu aplikacji, ponowne uruchomienie już działającej aplikacji po jej uruchomieniu musi zająć mniej niż oryginalny czas uruchomienia.  

    10. Implementacje urządzeń kompatybilności kompatybilności bezpieczeństwa

    muszą wdrożyć model bezpieczeństwa zgodny z modelem bezpieczeństwa platformy Androida zgodnie z definicją w dokumencie referencyjnym bezpieczeństwa i uprawnień w interfejsach API [ zasoby, 28 ] w dokumentacji programistów Androida. Implementacje urządzeń muszą obsługiwać instalację aplikacji z podpisem samodzielnie, nie wymagając dodatkowych uprawnień/certyfikatów od osób trzecich/organów. W szczególności kompatybilne urządzenia muszą obsługiwać mechanizmy bezpieczeństwa opisane w podsekcjach obserwujących.

    10.1.

    Implementacje urządzeń

    uprawnień

    muszą obsługiwać model uprawnień na Androida, zgodnie z definicją w dokumentacji programistów Androida [ Zasoby, 28 ]. W szczególności implementacje muszą egzekwować każde pozwolenie zdefiniowane zgodnie z opisem w dokumentacji SDK; Nie można pominąć, zmienić ani zignorować uprawnień. Implementacje mogą dodać dodatkowe uprawnienia, pod warunkiem, że nowe ciągi identyfikacyjne uprawnień nie znajdują się w Androidzie.* Przestrzeń nazw.

    10.2.

    Implementacje urządzeń

    izolacyjnych UID i procesu

    muszą obsługiwać model piaskownicy aplikacji Android, w którym każda aplikacja działa jako unikalny UID w stylu UNIX i w osobnym procesie. Implementacje urządzeń muszą obsługiwać uruchamianie wielu aplikacji jako ten sam identyfikator użytkownika Linux, pod warunkiem, że aplikacje są odpowiednio podpisywane i konstruowane, zgodnie z definicją w odniesieniu do bezpieczeństwa i uprawnień [ Zasoby, 28 ].

    10.3.

    Implementacje urządzeń

    uprawnienia systemu plików

    muszą obsługiwać model uprawnień do dostępu do plików z Androidem zgodnie z definicją w odniesieniu do bezpieczeństwa i uprawnień [ Zasoby, 28 ].

    11. Implementacje urządzenia pakietu testów kompatybilności muszą przekazać pakiet testu kompatybilności Android (CTS) [ Zasoby, 2 ] dostępne w projekcie open source z Androidem, korzystając z ostatecznego oprogramowania wysyłkowego na urządzeniu

    .

    Ponadto wdrażacze urządzeń powinni w jak największym stopniu korzystać z referencyjnej implementacji w drzewie open source z Androidem i muszą zapewnić zgodność w przypadkach dwuznaczności w CTS i wszelkich ponownych implementacjach części kodu źródłowego.

    CTS jest zaprojektowany do uruchamiania na rzeczywistym urządzeniu. Jak każde oprogramowanie, same CT mogą zawierać błędy. CTS będzie wersja niezależnie od tej definicji zgodności, a wiele wersji CTS może zostać wydanych dla Androida 2.1. Implementacje urządzeń muszą przekazać najnowszą wersję CTS dostępną w momencie zakończenia oprogramowania urządzenia.

    12. Implementacje urządzeń oprogramowania, które można aktualizować,

    muszą zawierać mechanizm zastąpienia całego oprogramowania systemowego. Mechanizm nie musi wykonywać aktualizacji „na żywo” - to znaczy może być wymagane ponowne uruchomienie urządzenia.

    Można zastosować dowolną metodę, pod warunkiem, że może wymienić całe oprogramowanie wstępnie zainstalowane na urządzeniu. Na przykład każde z poniższych podejść spełni ten wymóg:

    • Pobieranie Over-the-Air (OTA) z aktualizacją offline za pośrednictwem ponownego uruchamiania
    • „uwięzionych” aktualizacji USB z aktualizacji „offline” na komputerze hosta
    • za pośrednictwem ponownego uruchomienia i aktualizacji z pliku włączonego pliku Zdejmowane przechowywanie

    , którego zastosowany mechanizm aktualizacji musi obsługiwać aktualizacje bez wycierania danych użytkownika. Należy pamiętać, że oprogramowanie z Androidem Upstream zawiera mechanizm aktualizacji, który spełnia ten wymóg.

    Jeśli błąd zostanie znaleziony w implementacji urządzenia po jego wydaniu, ale w rozsądnym okresie życia produktu, który jest określony w porozumieniu z zespołem kompatybilności Androida, aby wpłynąć na kompatybilność aplikacji THID-partii Dostępna aktualizacja, którą można zastosować zgodnie z opisanym mechanizmem.

    13. Skontaktuj się z nami,

    możesz skontaktować się z autorów dokumentów pod adresem Compaticibity@android.com w celu uzyskania wyjaśnień i podjąć wszelkie problemy, które Twoim zdaniem nie obejmuje dokumentu.