Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.

Ta strona została przetłumaczona przez Cloud Translation API.

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

Definicja zgodności z Androidem: Android 1.6
Android 1.6 r2
Google Inc.
compatibility@android.com

1. Wprowadzenie
Ten dokument zawiera listę wymagań, które muszą być spełnione, aby telefony komórkowe były
kompatybilne z Androidem 1.6. Ta definicja zakłada znajomość programu zgodności z Androidem
[Materiały, 1].
Użycie słów „must” (musi), „must not” (nie musi), „required” (wymagane), „shall” (należy), „shall not” (nie należy), „should” (należy), „should not” (nie należy), „recommended” (zalecane),
„may” (można) i „optional” (opcjonalnie) jest zgodne ze standardem IETF zdefiniowanym w RFC2119 [Resources, 2].
W tym dokumencie „implementer urządzenia” lub „implementer” to osoba lub organizacja opracowująca
sprzętowe lub programowe rozwiązanie z Androidem 1.6. „Wdrażanie urządzenia” lub „wdrażanie” to opracowane w ten sposób rozwiązanie sprzętowo-programowe.

Aby uznać implementację urządzenia za zgodną z Androidem 1.6:
1. MUSI spełniać wymagania określone w tej definicji zgodności, w tym wszelkie dokumenty
włączone przez odniesienie.
2. MUSI przejść testy Compatibility Test Suite (CTS) dostępne w ramach projektu Android Open
Source [Resources, 3]. CTS sprawdza większość ale nie wszystkie komponenty opisane w tym
dokumencie.
Jeśli definicja lub pakiet CTS są niejednoznaczne lub niepełne, implementator urządzenia
musi zadbać o zgodność z dotychczasowymi implementacjami. Z tego powodu projekt Android Open
Source [Zasoby, 4] jest zarówno referencyjną, jak i preferowaną implementacją Androida. Programistom
zalecamy, aby opracowali swoje implementacje na podstawie kodu źródłowego „upstream”
dostępnego w ramach projektu Android Open Source. Chociaż niektóre komponenty można hipotetycznie zastąpić
innymi implementacjami, zdecydowanie odradzamy tę praktykę, ponieważ zdanie testów CTS stanie się
znacznie trudniejsze. Obowiązkiem implementatora jest zapewnienie pełnej zgodności z zachowaniem standardowej implementacji Androida, w tym w ramach pakietu testów zgodności i poza nim.

2. Materiały
Ta definicja zgodności odwołuje się do wielu materiałów, które można znaleźć tutaj.
1.Omówienie programu zgodności z Androidem: https://sites.google.com/a/android.com/compatibility/
how-it-works
2. Poziomy wymagań IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
3. Zestaw testów zgodności: http://sites.google.com/a/android.com/compatibility/compatibility-test-
suite--cts
4. Projekt Android Open Source: http://source.android.com/
5. Definicje i dokumentacja interfejsu API: http://developer.android.com/reference/packages.html
6. Dostawcy treści: http://code.google.com/android/reference/android/provider/package-
summary.html
7. Dostępne zasoby: http://code.google.com/android/reference/available-resources.html
8. Pliki manifestu Androida: http://code.google.com/android/devel/bblocks-manifest.html
9. Informacje o uprawnieniach Androida: http://developer.android.com/reference/android/
Manifest.permission.html
10. Konstanty kompilacji: http://developer.android.com/reference/android/os/Build.html
11. WebView: http://developer.android.com/reference/android/webkit/WebView.html
12. Rozszerzenia do przeglądarki Gears: http://code.google.com/apis/gears/

13. Specyfikacja maszyny wirtualnej Dalvik, dostępna w katalogu dalvik/docs w checkoutzie kodu źródłowego
. Dostępna też pod adresem http://android.git.kernel.org/?p=platform/
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
14. Widgety aplikacji: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. Powiadomienia: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. Poradnik dotyczący stylu ikon na pasku stanu: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. Menedżer wyszukiwania: http://developer.android.com/reference/android/app/SearchManager.html
18. Toast: http://developer.android.com/reference/android/widget/Toast.html
19. Aplikacje na Androida: http://code.google.com/p/apps-for-android
20.Opis pliku APK na Androida: http://developer.android.com/guide/topics/fundamentals.html
21. Android Debug Bridge (adb): http://code.google.com/android/reference/adb.html
22. Dalvik Debug Monitor Service (ddms): http://code.google.com/android/reference/ddms.html
23. Monkey: http://developer.android.com/guide/developing/tools/monkey.html
24. Dokumentacja dotycząca niezależności od wyświetlacza:
25. Konfiguracja stałych: http://developer.android.com/reference/android/content/res/
Configuration.html
26. Wskaźniki wyświetlacza: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. Aparat: 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
Wiele z tych zasobów pochodzi bezpośrednio lub pośrednio z pakietu SDK Androida 1.6 i będzie funkcjonalnie identyczne z informacjami w dokumentacji tego pakietu SDK.
W każdym przypadku, gdy ta
definicja zgodności jest niezgodna z dokumentacją pakietu SDK, to dokumentacja pakietu SDK jest uznawana za
autorytatywną. Wszelkie szczegóły techniczne podane w wymienionych powyżej dokumentach są uwzględniane
w ramach tej definicji zgodności.
3. Oprogramowanie
Platforma Androida obejmuje zarówno zestaw zarządzanych („twardych”) interfejsów API, jak i tak zwane „miękkie” interfejsy API
, takie jak system Intent, interfejsy API kodu natywnego i interfejsy API aplikacji internetowych. W tej sekcji znajdziesz szczegółowe informacje o interfejsach API (twardych i miękkich), 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 podane w tej sekcji.
3.1. Zgodność zarządzanego interfejsu API
Zarządzane środowisko wykonywania (oparte na Dalviku) jest głównym sposobem uruchamiania aplikacji na Androida.
Interfejs programowania aplikacji (API) Androida to zestaw 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 zachowań interfejsu API udostępnionego przez pakiet SDK Androida
1.6, w tym:
1. Podstawowe interfejsy API w języku Java na Androida [Resources, 5].
2. Dostawcy treści [Resources, 6].
3. Resources [Resources, 7].
4. Atrybuty i elementy pliku AndroidManifest.xml [Zasoby, 8].

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

3.2. Zgodność z miękkimi interfejsami API
Oprócz zarządzanych interfejsów API wymienionych w sekcji 3.1 Android zawiera też ważne „miękkie” interfejsy API
, które są używane tylko w czasie wykonywania. Dotyczy to m.in. intencji, uprawnień i podobnych aspektów aplikacji na Androida
, których nie można wymusić w czasie kompilowania aplikacji. W tej sekcji znajdziesz szczegółowe informacje o „miękkich” interfejsach API i zachowaniach systemu
wymaganych do zapewnienia zgodności z Androidem 1.6. Wdrożenia urządzeń MUSZĄ spełniać wszystkie
wymagania podane w tej sekcji.
3.2.1. Uprawnienia
Wdrożyciele urządzeń MUSZĄ obsługiwać i stosować wszystkie stałe uprawnienia zgodnie z dokumentacją na
stronie z informacjami o uprawnieniach [Zasoby, 9]. Pamiętaj, że w sekcji 10 wymieniono dodatkowe wymagania dotyczące
modelu zabezpieczeń Androida.
3.2.2. Parametry kompilacji
Interfejsy API Androida zawierają wiele stałych wartości w klasie android.os.Build [Resources, 10] , które
służą do opisu bieżącego urządzenia. Aby zapewnić spójne, sensowne 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
Wersja aktualnie uruchomionego systemu Android w czytelnym dla człowieka formacie
android.os.Build.VERSION.RELEASE
. W przypadku Androida 1.6 to pole MUSI zawierać ciąg znaków
„1.6”.
Wersja aktualnie działającego systemu Android w formacie
android.os.Build.VERSION.SDK
dostępna dla kodu aplikacji innych firm. W przypadku Androida 1.6 to pole
MUSI zawierać wartość całkowitą 4.
Wartość wybrana przez implementatora urządzenia, która określa specyficzną kompilację
obecnie działającego systemu Android w czytelnym dla człowieka formacie.
Tej wartości NIE WOLNO używać ponownie w przypadku różnych kompilacji wysyłanych do użytkowników
android.os.Build.VERSION.INCREMENTAL. Typowym zastosowaniem tego pola jest wskazanie numeru wersji lub identyfikatora zmiany w kontroli źródłowej, który posłużył do wygenerowania wersji.
Nie
ma wymagań dotyczących formatu tego pola, z wyjątkiem tego, że
NIE MOŻE być ono puste ani zawierać pustego ciągu znaków ("").
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
android.os.Build.BOARD
polega na wskazaniu konkretnej wersji płyty głównej zasilającej urządzenie
. Nie ma żadnych wymagań dotyczących formatu tego pola,
z wyjątkiem tego, że NIE MOŻE ono być puste ani zawierać pustego ciągu znaków („"").
Wartość wybrana przez implementatora urządzenia, identyfikująca nazwę
android.os.Build.BRAND
firmy, organizacji, osoby itp., która wyprodukowała urządzenie, w
czytelnym dla człowieka formacie. 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 tym zastrzeżeniem, że nie może być ono puste ani nie może zawierać pustego ciągu znaków (czyli „"").
Wartość wybrana przez implementatora urządzenia, która identyfikuje określoną konfigurację lub wersję treści (czasami nazywaną „projektem przemysłowym
android.os.Build.DEVICE
”) urządzenia.

Nie ma 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 („"”).
Ciąg znaków jednoznacznie identyfikujący tę kompilację. Powinien być w miarę
zrozumiały dla człowieka. Musi ona być zgodna z tym szablonem:
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/
android.os.Build.FINGERPRINT
$(BUILD_VERSION_TAGS)
Na przykład: acme/mydevicel/generic/generic:Donut/ERC77/
3359:userdebug/test-keys
Odcisk palca NIE MOŻE zawierać spacji. Jeśli inne pola w powyższym szablonie
zawierają spacje, należy je zastąpić w odpisie cyfrowym znakiem podkreślenia (
) z zestawu ASCII.
Ciąg znaków jednoznacznie identyfikujący hosta, na którym została utworzona kompilacja, w czytelnym dla człowieka formacie
android.os.Build.HOST
. 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 („"").
Identyfikator wybrany przez implementatora urządzenia, aby odwoływać się do konkretnej wersji
w formacie zrozumiałym dla człowieka. To pole może być takie samo jak
android.os.Build.VERSION.INCREMENTAL, ale MUSI mieć wartość
android.os.Build.ID
zawierającą informacje istotne dla użytkowników. 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 („"").
Wartość wybrana przez implementatora urządzenia zawierająca nazwę
urządzenia znaną użytkownikowi końcowemu. Powinna to być ta sama nazwa
android.os.Build.MODEL
pod którą urządzenie jest sprzedawane użytkownikom. Nie ma
wymagań dotyczących formatu tego pola, z wyjątkiem tego, że NIE MOŻE
być puste ani zawierać pustego ciągu znaków („"").
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ć
android.os.Build.PRODUCT
koniecznie przeznaczona do wyświetlania przez użytkowników końcowych. Nie ma wymagań
dotyczących formatu tego pola, z wyjątkiem tego, że nie może być puste ani zawierać
pustego ciągu znaków („"").
Lista tagów oddzielonych przecinkami wybranych przez implementatora urządzenia, która
dodatkowo rozróżnia kompilację. Na przykład „unsigned,debug”. To pole
android.os.Build.TAGS
NIE MOŻE być puste ani zawierać pustego ciągu znaków (""), ale pojedynczy tag (np.
"release") jest dozwolony.
android.os.Build.TIME
Wartość reprezentująca sygnaturę czasową utworzenia kompilacji.
Wartość wybrana przez implementatora urządzenia, która określa konfigurację czasu wykonywania wersji.
To pole MUSI zawierać jedną z wartości
android.os.Build.TYPE
odpowiadającą 3 typowym konfiguracjom środowiska uruchomieniowego Androida: „user”,
„userdebug” lub „eng”.
Nazwa lub identyfikator użytkownika (lub użytkownika automatycznego), który wygenerował wersję
android.os.Build.USER
. Nie ma 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 („”).

3.2.3. Zgodność intencji
Android używa intencji do luźnej integracji aplikacji. W tej sekcji opisano
wymagania dotyczące wzorca intencji, które MUSZĄ być uwzględnione w implementacjach urządzeń. Przez
„przestrzeganie” rozumie się, że implementator urządzenia MUSI udostępnić aktywność, usługę lub inny
komponent Androida, który określa pasujący filtr intencji oraz wiąże się z właściwym zachowaniem i implementuje je w przypadku każdego
określonego w tym celu wzorca.
3.2.3.1. Podstawowe intencje aplikacji
Projekt Android upstream definiuje kilka podstawowych aplikacji, takich jak wybieranie numeru, kalendarz,
książka adresowa czy odtwarzacz muzyki. Implementatorzy urządzeń MOGĄ zastąpić te aplikacje
alternatywnymi wersjami.
Jednak takie alternatywne wersje MUSZĄ przestrzegać tych samych wzorców intencji, które są dostarczane przez projekt źródłowy
. (na przykład jeśli urządzenie zawiera alternatywny odtwarzacz muzyki, nadal musi on honorować wzór intencji
wydawany przez aplikacje innych firm w celu wybrania utworu). Implementacje na urządzeniu MUSZĄ obsługiwać wszystkie wzorce intencji
wymienione w Załączniku A.
3.2.3.2. Zastępowanie intencji
Android jest platformą rozszerzalną, dlatego implementatorzy urządzeń MUSZĄ zezwolić na zastępowanie każdego wzorca intencji opisanego w
Załączniku A przez aplikacje innych firm. Górny projekt o otwartym kodzie źródłowym Androida
domyślnie zezwala na to; implementatorzy urządzeń NIE MOGĄ dołączać specjalnych uprawnień do aplikacji systemowych
wykorzystujących te wzorce intencji ani uniemożliwiać aplikacjom innych firm wiązania się z tymi wzorami i przejmowania nad nimi kontroli.
Zakaz ten obejmuje w szczególności wyłączenie interfejsu „Wybór”, który pozwala użytkownikowi na wybór spośród wielu aplikacji, które obsługują ten sam wzór intencji.

3.2.3.3. Nazwy przestrzeni Intent
Deweloperzy urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub
intencji rozgłoszeniowych za pomocą ciągu znaków ACTION, CATEGORY lub innego ciągu klucza w przestrzeni android.*.
Deweloperzy urządzeń NIE MOGĄ uwzględniać żadnych komponentów Androida, które obsługują nowe wzorce intencji lub
intencji rozgłoszeniowych za pomocą ciągu znaków ACTION, CATEGORY lub innego ciągu klucza w przestrzeni pakietu
należącej do innej organizacji. Implementatorzy urządzeń NIE MOGĄ zmieniać ani rozszerzać żadnych wzorów intencji
wymienionych w Appendiksie A lub B.
Ten zakaz jest analogiczny do zakazu dotyczącego zajęć z języka Java w sekcji 3.6.

3.2.3.4. Rozgłaszanie intencji
Aplikacje innych firm polegają na platformie, która rozgłasza określone intencje, aby informować je o zmianach w
środowisku sprzętowym lub programowym. Urządzenia zgodne z Androidem MUSZĄ wysyłać publiczne intencje
w odpowiedzi na odpowiednie zdarzenia systemowe. Lista wymaganych intencji transmisji znajduje się w
Załączniku B. Pamiętaj jednak, że pakiet SDK może definiować dodatkowe intencje transmisji, które również muszą być uwzględniane.

3.3. Zgodność z natywnym interfejsem API
Kod zarządzany działający w Dalviku może wywoływać kod natywny dostarczony w pliku APK aplikacji jako plik ELF
.so skompilowany pod kątem odpowiedniej architektury sprzętowej urządzenia. Implementacje na urządzeniu MUSZĄ zawierać
obsługę kodu działającego w semantycznym środowisku zarządzanym, aby wywoływać kod natywny za pomocą standardowego interfejsu natywnego Java (JNI).
Te biblioteki MUSZĄ być zgodne pod względem kodu źródłowego (czyli nagłówka) i binarnego (dla 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 ich zgodność z nagłówkami i plikami binarnymi.
Zgodność z kodem natywnym jest trudna do osiągnięcia. Dlatego jeszcze raz prosimy implementatorów urządzeń o
bardzo dokładne korzystanie z implementacji bibliotek wymienionych powyżej, aby zapewnić kompatybilność.

3.4. Kompatybilność z interfejsem Web API
Wiele deweloperów i aplikacji korzysta z klasy android.webkit.WebView [Resources,
11] w swoich interfejsach użytkownika, dlatego implementacja WebView musi być kompatybilna z implementacjami Androida
. Implementacja na Androidzie typu open source korzysta z wersji silnika renderowania WebKit do
implementacji WebView.
Ponieważ niemożliwe jest opracowanie kompleksowego zestawu testów dla przeglądarki, implementatorzy urządzeń
MUSZĄ używać konkretnej kompilacji WebKit w implementacji WebView. W szczególności:
• W komponencie WebView MUSISZ używać kompilacji WebKit 528.5 lub nowszej z drzewa źródłowego Android Open Source na potrzeby
Androida 1.6. Ta kompilacja zawiera określony zestaw funkcji i poprawek zabezpieczeń dla WebView.
• Ciąg klienta użytkownika zwracany przez WebView MUSI mieć format:
Mozilla/5.0 (Linux; U; Android 1.6; <language>-<country>; <device
name>; Build/<build ID>) AppleWebKit/528.5+ (KHTML, like Gecko)
Version/3.1.2 Mobile Safari/525.20.1

◦ Ciąg "<device name>" MUSI być taki sam jak wartość parametru
android.os.Build.MODEL
◦ Ciąg "<build ID>" MUSI być taki sam jak wartość parametru android.os.Build.ID.
◦ Ciągi "<language>" i "<country>" powinny być zgodne z konwencjami dotyczącymi
kodu kraju i języka oraz powinny odnosić się do bieżącej lokalizacji urządzenia w momencie wysłania żądania.

W implementacjach można użyć niestandardowego ciągu znaków klienta użytkownika w samodzielnej aplikacji przeglądarki. Co więcej, samodzielna przeglądarka MOŻE być oparte na innej technologii przeglądarki (takich jak Firefox,
Opera itp.).
Nawet jeśli w aplikacji jest dostępna inna przeglądarka, komponent WebView
udostępniany aplikacjom innych firm MUSI być oparty na WebKit, jak opisano powyżej.
Samodzielna aplikacja przeglądarki powinna obsługiwać Gears [Resources, 12] i MOŻE
obsługiwać niektóre funkcje HTML5 lub wszystkie.
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ą Androida dostępną w ramach projektu Android Open Source.
Oto niektóre obszary zgodności:
• Urządzenia NIE MOGĄ zmieniać zachowania ani znaczenia standardowego zamiaru
• Urządzenia NIE MOGĄ zmieniać cyklu życia ani semantyki cyklu życia określonego typu komponentu systemowego (np. usługi, aktywności, dostawcy treści itp.)

• Urządzenia NIE MOGĄ zmieniać semantyki danego uprawnienia.
Powyższa lista nie jest wyczerpująca. Obowiązek zapewnienia 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 (
), zamiast ponownie wdrażać istotne części systemu.
Pakiet Compatibility Test Suite (CTS) testuje znaczne części platformy pod kątem zgodności behawioralnej,
ale nie wszystkich. Wdrożeni powinni zadbać o zachowanie zgodności z Androidem
Open Source Project.
3.6. Przestrzenie nazw 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.*
Zabronione modyfikacje to m.in.:
• Implementacje na urządzeniach NIE MOGĄ modyfikować publicznie udostępnionych interfejsów API na platformie Android
poprzez zmianę sygnatur metod lub klas albo usunięcie klas lub pól klas.

• Deweloperzy urządzeń MOGĄ modyfikować implementację interfejsów API, ale takie
modyfikacje NIE MOGĄ wpływać na opisane zachowanie i sygnatura języka Java dla żadnych
publicznie udostępnionych interfejsów API.
• Implementujący urządzenie NIE MOGĄ dodawać do interfejsów API wymienionych powyżej żadnych publicznie dostępnych elementów (takich jak klasy lub interfejsy, pola lub metody do istniejących klas lub interfejsów).

„Publicznie dostępny element” to dowolna konstrukcja, która nie jest ozdobiona znacznikiem „@hide” w
górnym kodzie źródłowym Androida. Innymi słowy, implementatorzy urządzeń NIE MOGĄ udostępniać nowych interfejsów API ani modyfikować istniejących interfejsów API w wymienionych powyżej przestrzeniach nazw.
Implementatorzy urządzeń MOGĄ wprowadzać modyfikacje tylko na potrzeby wewnętrzne
, ale nie mogą reklamować tych modyfikacji ani w inny sposób udostępniać ich deweloperom.
Implementatorzy urządzeń mogą dodawać niestandardowe interfejsy API, ale nie mogą umieszczać ich w przestrzeni nazw należącej do innej organizacji ani do niej odwołującej się.
Na przykład implementatorzy urządzeń NIE MOGĄ dodawać interfejsów API do przestrzeni nazw
com.google.* lub podobnej. Mogą to robić tylko firmy Google. Podobnie Google NIE MOŻE dodawać interfejsów API do przestrzeni nazw innych firm.

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

Pamiętaj, że powyższe ograniczenia odpowiadają standardowym konwencjom nazewnictwa interfejsów API w języku programowania Java
. Celem tej sekcji jest po prostu wzmocnienie tych konwencji i uczynienie ich wiążącymi
poprzez uwzględnienie w tej definicji zgodności.
3.7. Zgodność z maszyną wirtualną
Zgodne urządzenie z Androidem musi obsługiwać pełną specyfikację bajtkodu Dalvik Executable (DEX) oraz semantykę maszyny wirtualnej Dalvik [Resources, 13].

3.8. Zgodność interfejsu użytkownika
Platforma Android zawiera interfejsy API dla deweloperów, które umożliwiają im tworzenie elementów interfejsu użytkownika
. Implementacje na urządzeniach MUSZĄ uwzględniać te standardowe interfejsy API w ramach niestandardowych interfejsów użytkownika
, które zostały przez nie opracowane, jak wyjaśniono 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, 14]. 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 (np. ekran główny) alternatywnym Launcherem.
Alternatywne Launchery POWINNA zawierać wbudowane wsparcie dla widżetów aplikacji oraz udostępniać elementy interfejsu użytkownika
, które umożliwiają dodawanie, wyświetlanie i usuwanie widżetów bezpośrednio w Launcherze. Alternatywne wygaszacze MOŻE
nie zawierać tych elementów interfejsu użytkownika. Jeśli jednak tak się stanie, implementator urządzenia MUSI udostępnić
oddzielną aplikację dostępną z wygaszacza, która umożliwia użytkownikom dodawanie, wyświetlanie i usuwanie
widżetów aplikacji.

3.8.2. Powiadomienia
Android zawiera interfejsy API, które umożliwiają deweloperom informowanie użytkowników o istotnych zdarzeniach [Resources, 15]. Wdrożyciele
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 poprawnie renderować wszystkie zasoby (ikony, pliki dźwiękowe itp.)
udostępnione w interfejsach API [Zasoby, 7] lub w przewodniku po stylu ikon na pasku stanu [Zasoby, 16]. Producenci
MOGĄ udostępnić użytkownikom alternatywne powiadomienia niż te dostępne w ramach referencyjnej implementacji Androida w wersji open source. Takie alternatywne systemy powiadomień MUSZĄ
obsługiwać istniejące zasoby powiadomień, jak opisano powyżej.

3.8.3. Wyszukiwarka
Android zawiera interfejsy API [Resources, 17], które umożliwiają deweloperom dodanie wyszukiwarki do aplikacji oraz udostępnienie danych aplikacji w globalnym wyszukiwaniu systemowym.
Ogólnie rzecz biorąc, ta funkcja
obejmowałaby jeden interfejs użytkownika obejmujący cały system, który umożliwia użytkownikom wpisywanie zapytań, wyświetlanie sugestii
w miarę ich wpisywania oraz wyświetlanie wyników. Interfejsy API Androida umożliwiają deweloperom ponowne używanie tego interfejsu do udostępniania funkcji
wyszukiwania w ich własnych aplikacjach oraz do udostępniania wyników w ramach wspólnego globalnego interfejsu wyszukiwania
.
Wdrożenia na urządzeniach MUSZĄ zawierać jeden wspólny interfejs wyszukiwania w całym systemie, który umożliwia
proponowanie sugestii w czasie rzeczywistym w odpowiedzi na dane wprowadzane przez użytkownika. Implementacje na urządzeniach MUSZĄ implementować interfejsy API, które
umożliwiają deweloperom ponowne użycie tego interfejsu użytkownika w celu udostępnienia wyszukiwania w ich własnych aplikacjach.
Wdrożenia 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 zainstalowano żadnych aplikacji innych firm, które
korzystają z tej funkcji, domyślnie powinny wyświetlać się wyniki wyszukiwarki internetowej i
sugestie.
Implementacje na urządzeniach mogą zawierać alternatywne interfejsy wyszukiwania, ale powinny zawierać przycisk wyszukiwania (fizyczny lub wirtualny),
którego można użyć w dowolnym momencie w dowolnej aplikacji, aby wywołać mechanizm wyszukiwania,
z zachowaniem opisanym w dokumentacji interfejsu API.
3.8.4. Toasty
Aplikacje mogą używać interfejsu Toast API (zdefiniowanego w [Zasoby, 18]), aby wyświetlać krótkie niemodalne ciągi znaków
użytkownikowi końcowemu. Po krótkim czasie znikają one z ekranu. Implementacje na urządzeniach MUSZĄ wyświetlać komunikaty typu Toast
dla użytkowników w sposób dobrze widoczny.
4. Zgodność z oprogramowaniem referencyjnym
Deweloperzy urządzeń MUSZĄ przetestować zgodność implementacji za pomocą tych aplikacji open source:
• kalkulatora (dostępnego w pakiecie SDK)
• Lunar Lander (dostępnego w pakiecie SDK)
• ApiDemos (dostępnego w pakiecie SDK)
• aplikacji „Aplikacje na Androida” [Zasoby, 19]
Aby implementacja była uznawana za zgodną, MUSI się uruchamiać i działać prawidłowo w przypadku każdej z tych aplikacji.

5. Zgodność z pakowaniem aplikacji
Wdrożenia na urządzeniach MUSZĄ instalować i uruchamiać pliki „.apk” na Androida wygenerowane przez narzędzie „aapt”
zawarte w oficjalnym pakiecie SDK do Androida [Resources, 20].
Implementacje na urządzeniach NIE MOGĄ rozszerzać formatów plików .apk, Android Manifest ani kodu bajtowego Dalvik
w sposób uniemożliwiający ich prawidłowe instalowanie i uruchamianie na innych
urządzeniach zgodnych z aplikacją. Implementatorzy urządzeń powinni używać referencyjnej implementacji Dalvik
i systemu zarządzania pakietami referencyjnej implementacji.
6. Zgodność multimedialna
Zgodne urządzenie z Androidem musi obsługiwać te kodeki multimedialne. Wszystkie te kodeki
są udostępniane w ramach preferowanej implementacji Androida w ramach Projektu Android Open
Source [Resources, 4].
Pamiętaj, że ani Google, ani Open Handset Alliance nie gwarantują, że te kodeki nie są objęte patentami innych firm.
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
Szczegóły kodowania i dekodowania
Obsługiwane pliki
Mono/Stereo w dowolnym
3GPP (.3gp) i
połączenie standardowych szybkości transmisji bitów
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
do 160 kbps i pliki z szybkością próbkowania. Nie obsługuje plików w formacie raw
o szybkości od 8 do 48 kHz
AAC (.aac)
mono/stereo w dowolnym formacie
3GPP (.3gp) i
HE-AACv1
kombinacja standardowych szybkości transmisji bitów
MPEG-4 (.mp4, .m4a)
X
(AAC+)
do 96 kbps i częstotliwości próbkowania. Nie obsługujemy plików w formacie raw
o częstotliwości od 8 do 48 kHz
AAC (.aac)
mono lub stereo w dowolnym formacie
HE-AACv2
3GPP (.3gp) i
połączenie standardowych szybkości transmisji bitów
(ulepszone)
MPEG-4 (.mp4, .m4a)
X
do 96 kbps i częstotliwości próbkowania
AAC+)
plików. Nieobsługiwane:
8–48 kHz
AAC (.aac)
AMR-NB
4,75–12,2 kbps próbkowane @
Pliki 3GPP (.3gp)
X
X
8 kHz
AMR-WB
9 szybkości od 6,60 kbit/s do 23,85
Pliki 3GPP (.3gp)
X
kbit/s próbkowane @ 16 kHz
MP3
Mono/Stereo 8–320 kbps stały MP3 (.mp3)
X
(CBR) lub zmienna szybkość transmisji (VBR)
Typ 0 i 1 (.mid, .xmf,
MIDI Type 0 and 1. DLS w wersji 1
MIDI
X
.mxmf). Również RTTTL/RTX
i 2. XMF i Mobile XMF.
(.rtttl, .rtx), OTA (.ota),

Obsługa formatów dzwonka
i iMelody (.imy)
RTTTL/RTX, OTA i iMelody
Ogg Vorbis
.ogg
X
8- i 16-bitowy liniowy PCM (szybkości do
PCM
X
WAVE
do limitu sprzętu)
Obraz
Pliki
Nazwa
Szczegóły kodeka i dekodera
Obsługiwane
3GPP (.3gp)
H.263
X
X
pliki
3GPP (.3gp)
H.264
X
i MPEG-4
(.mp4)
MPEG4
X
Plik 3GPP (.3gp)
SP
7.

Zgodność z narzędziami dla deweloperów
Implementacje na urządzeniach MUSZĄ obsługiwać narzędzia dla deweloperów Androida udostępniane w pakiecie SDK Androida.
W szczególności urządzenia zgodne z Androidem MUSZĄ być zgodne z:
• Android Debug Bridge lub adb [Resources, 21]
Implementacje na urządzeniach MUSZĄ obsługiwać wszystkie funkcje adb zgodnie z dokumentacją w pakiecie SDK Androida.
Dzieciaj na urządzeniu powinien być domyślnie nieaktywny, ale musi istnieć mechanizm dostępny dla użytkownika
, który umożliwia włączenie Android Debug Bridge.
• Dalvik Debug Monitor Service lub ddms [Resources, 22]
Wdrożenia na urządzeniu MUSZĄ obsługiwać wszystkie funkcje ddms zgodnie z dokumentacją pakietu SDK Androida.
Ponieważ ddms używa polecenia adb, obsługa ddms MUSI być domyślnie nieaktywna, ale MUSI być obsługiwana
, gdy użytkownik aktywuje Android Debug Bridge (ADB), jak opisano powyżej.

• Monkey [Resources, 23]
Implementacje 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 form i konfiguracji.
W tym samym czasie 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 znajdziesz listę funkcji sprzętowych, które muszą obsługiwać wszystkie urządzenia zgodne z Androidem 1.6. W
Androidzie 1.6 wymagana jest większość funkcji sprzętowych (takich jak Wi-Fi, kompas i akcelerometr).
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 implementować ten interfejs API zgodnie z dokumentacją pakietu Android SDK
.
8.1. Wyświetlacz
Android 1.6 zawiera funkcje, które w pewnych okolicznościach
automatycznie wykonują operacje skalowania i przekształcania, aby aplikacje innych firm działały w stosunkowo dobry sposób na sprzęcie
w konfiguracjach, dla których nie zostały one zaprojektowane ([Resources, 24]). Urządzenia MUSZĄ
prawidłowo realizować te zachowania zgodnie z opisem w tej sekcji.
8.1.1. Standardowe konfiguracje wyświetlacza
W tej tabeli wymieniono standardowe konfiguracje ekranu uznawane za zgodne z Androidem:
Pion
Rozmiar ekranu
Gęstość ekranu
Typ ekranu
Szerokość (piksele)
Wysokość (piksele)
Zakres długości
Grupa
Grupa
(cale)
QVGA
240
320
2,6–3,0
Mały
Niski
WQVGA
240
400
3,2–3,5
Normalny
Niski
FWQVGA
240
432
3,5–3,8
Normalny
Niski
HVGA
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

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

• W implementacjach urządzeń należy interpretować wszystkie obecne zasoby jako domyślnie
"medium" (w dokumentacji pakietu SDK określane jako „mdpi”).
• W przypadku ekranu o „niskiej” gęstości implementacje na urządzeniu MUSZĄ zmniejszyć zasoby o średniej gęstości (
) mdpi o współczynnik 0, 75.
• W przypadku ekranu o „wysokiej” gęstości implementacje na urządzeniu MUSZĄ skalować zasoby o rozdzielczości medium/
mdpi 1, 5 raza.
• Implementacje urządzeń NIE MOGĄ skalować komponentów w zakresie gęstości, a MOGĄ skalować
komponenty dokładnie o te współczynniki w różnych zakresach gęstości.
8.1.2. Niestandardowe konfiguracje wyświetlania
Konfiguracje wyświetlania, które nie pasują do żadnej ze standardowych konfiguracji wymienionych w sekcji 8.2.1, wymagają
dodatkowego rozważenia i działania, aby były zgodne. Implementatorzy urządzeń MUSZĄ skontaktować się z zespołem ds. zgodności z Androidem
, jak to opisano w sekcji 12, aby uzyskać klasyfikację pod kątem rozmiaru ekranu, gęstości
i współczynnika skalowania. W przypadku tych informacji implementacje na urządzeniach MUSZĄ je stosować
zgodnie z określeniami.
Należy pamiętać, że niektóre konfiguracje wyświetlacza (np. bardzo duże lub bardzo małe ekrany oraz niektóre formaty obrazu)
są całkowicie niezgodne z Androidem 1.6. Dlatego implementatorzy urządzeń powinni
jak najszybciej skontaktować się z zespołem ds. zgodności Androida.
8.1.3. Dane wyświetlania
W implementacjach na urządzeniach MUSISZ zgłaszać prawidłowe wartości wszystkich danych wyświetlania zdefiniowanych w
android.util.DisplayMetrics [Resources, 26].
8.2. Klawiatura
Wdrożone na urządzeniu:
• MUSI zawierać obsługę mechanizmu zarządzania wprowadzaniem danych (umożliwiającą deweloperom firm zewnętrznych tworzenie mechanizmów zarządzania wprowadzaniem danych, czyli klawiatur wirtualnych), jak opisano na stronie
developer.android.com
• MUSI zawierać co najmniej 1 wdrożenie klawiatury wirtualnej (niezależnie od tego, czy jest dostępna klawiatura
fizyczna)
• MOŻE zawierać dodatkowe wdrożenia klawiatur wirtualnych
• MOŻE zawierać klawiaturę sprzętową
• NIE MOŻE zawierać klawiatury sprzętowej, która nie pasuje do żadnego z formatów określonych
w android.content.res.Configuration [Resources, 25] (czyli QWERTY lub 12 klawiszy)
8.3.
Nawigacja bezdotykowa
Wdrożenia na urządzeniu:
• MOŻNA pominąć opcje nawigacji bezdotykowej (czyli można pominąć trackball, 5-kierunkowy pad kierunkowy lub
koło)
• NALEŻY zgłosić za pomocą android.content.res.Configuration [Resources, 25] prawidłową wartość dla
sprzętu urządzenia

8.4. Orientacja ekranu
Zgodne urządzenia MUSZĄ obsługiwać dynamiczną orientację ekranu w ustawieniach pionowych lub poziomych
. Oznacza to, że urządzenie musi uwzględnić prośbę aplikacji o określoną orientację ekranu
. Implementacje urządzeń MOGĄ domyślnie wybierać orientację pionową lub poziomą.
Urządzenia MUSZĄ zgłaszać prawidłową wartość bieżącego położenia urządzenia, gdy zostanie zapytanie o to za pomocą interfejsu
android.content.res.Configuration.orientation, android.view.Display.getOrientation() lub innego interfejsu API.
8.5. Dane wejściowe z ekranu dotykowego
Wdrożenia na urządzeniu:
• Urządzenie MUSI mieć ekran dotykowy
• Urządzenie MOŻE mieć ekran dotykowy pojemnościowy lub oporowy
• Urządzenie MUSI przekazywać wartość android.content.res.Configuration [Resources, 25] odpowiadającą
rodzajowi ekranu dotykowego na urządzeniu
8.6. USB
Wdrażanie na urządzeniu:
• NALEŻY zaimplementować 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)
• NALEŻY zaimplementować klienta pamięci masowej USB dla wymiennej/multimediów
• NALEŻY użyć formatu micro USB po stronie urządzenia
• NALEŻY zaimplementować obsługę specyfikacji pamięci masowej USB (aby można było uzyskać dostęp do wymiennej
lub stałej pamięci na urządzeniu z poziomu hosta PC)
• MOŻNA użyć niestandardowego portu po stronie urządzenia, ale w takim przypadku NALEŻY dostarczyć kabel umożliwiający
podłączenie niestandardowego złącza do standardowego portu USB-A
8.7.
Klawisze nawigacyjne
Funkcje Strona główna, Menu i Wstecz są niezbędne do korzystania z Androida. Wdrożenia na urządzeniu
MUSZĄ udostępniać te funkcje użytkownikowi przez cały czas, niezależnie od stanu aplikacji
. Te funkcje NALEŻY implementować 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
zakłócać dostępnej powierzchni wyświetlacza aplikacji.
Implementatorzy urządzeń powinni też podać specjalny klucz wyszukiwania. Wdrożyciele urządzeń MOŻE również
dostarczać klucze wysyłania i kończenia połączeń telefonicznych.
8.8. WiFi
Wdrożenia urządzeń MUSZĄ obsługiwać standardy 802.11b i 802.11g oraz MOŻE obsługiwać standard 802.11a.

8.9. Aparat
Wdrożenia na urządzeniach MUSZĄ zawierać aparat. Wbudowany aparat:
• MUSI mieć rozdzielczość co najmniej 2 Mpix
• POWINIEN mieć sprzętowy lub programowy autofokus zaimplementowany w sterowniku kamery
(przezroczysty dla oprogramowania aplikacji)
• MOŻE mieć sprzętowy lub EDOF (rozszerzona głębia ostrości) sprzętowy autofokus
• MOŻE mieć lampę błyskową. Jeśli aparat ma lampę błyskową, lampa błyskowa MUSI być wyłączona, gdy instancja
android.hardware.Camera.PreviewCallback została zarejestrowana na powierzchni
Kamera podglądowa.
W przypadku implementacji interfejsów API związanych z kamerą należy zaimplementować te zachowania:
[Resources, 27]:
1. Jeśli aplikacja nigdy nie wywołała android.hardware.Camera.Parameters.setPreviewFormat(int),
to urządzenie MUSI używać android.hardware.PixelFormat.YCbCr_420_SP do danych podglądu
przekazanych 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 tablicy byte[] przekazane do onPreviewFrame() muszą być w dalszym ciągu w formacie kodowania NV21.
(To jest format używany natywnie przez rodzinę urządzeń 7k.)
Oznacza to, że NV21 MUSI być ustawiony jako domyślny.
8.9.1. Aparaty bez autofokusu
Jeśli urządzenie nie ma aparatu z autofokusem, implementator MUSI spełnić dodatkowe wymagania podane w tej sekcji.
Implementacje urządzeń MUSZĄ w rozsądny sposób zaimplementować pełny interfejs Camera API zawarty w dokumentacji pakietu SDK Androida 1.6
, niezależnie od rzeczywistych możliwości sprzętowych kamery.
W przypadku Androida 1.6, jeśli kamera nie ma autofokusa, implementacja urządzenia MUSI być zgodna z tymi wymaganiami:
1. System MUSI zawierać tylko do odczytu właściwość systemową o nazwie „ro.workaround.noautofocus”
o wartości „1”. Ta wartość ma być używana przez aplikacje takie jak Android Market do
selektywnego identyfikowania możliwości urządzenia. W przyszłej wersji Androida zostanie zastąpiona
solidnym interfejsem API.
2. Jeśli aplikacja wywołuje funkcję android.hardware.Camera.autoFocus(), system MUSI wywołać metodę wywołania zwrotnego
onAutoFocus() w przypadku dowolnego zarejestrowanego wystąpienia
android.hardware.Camera.AutoFocusCallback, nawet jeśli nie nastąpiło żadne skupianie.
Ma to na celu uniknięcie problemów z obecnymi aplikacjami, które mogłyby wystąpić w przypadku nieskończonego oczekiwania na wywołanie autofocus
, które nigdy nie nastąpi.
3. Wywołanie metody AutoFocusCallback.onAutoFocus() MUSI zostać wywołane przez sterownik lub
ramę w nowym zdarzeniu w głównym wątku pętli ramy. Oznacza to, że Camera.autoFocus()
NIE MOŻE bezpośrednio wywoływać AutoFocusCallback.onAutoFocus(), ponieważ spowoduje to naruszenie modelu wątków w ramach Androida
i uszkodzi aplikacje.
8.10. Przyspieszeniomierz
Wdrożenia 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
czujników Androida, jak to opisano w interfejsach API Androida (Zasoby, 28).

8.11. Kompas
Wdrożenia na urządzeniu MUSZĄ zawierać 3-osiowy kompas 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 czujników Androida
, jak określono w interfejsie API Androida [Resources, 28].
8.12. GPS
Wdrożenia na urządzeniach MUSZĄ zawierać GPS-a i POWINNY zawierać jakąś formę techniki „wspomagania GPS”
, aby zminimalizować czas ustalania pozycji przez GPS.
8.13. Telefonia
Wdrożenia na urządzeniu:
• MUSI zawierać telefonię GSM lub CDMA
• MUSI implementować odpowiednie interfejsy API zgodnie z dokumentacją Android SDK na stronie
developer.android.com
Pamiętaj, że to wymaganie oznacza, że urządzenia inne niż telefony nie są zgodne z Androidem 1.6; urządzenia z Androidem
1.6 MUSZĄ zawierać sprzęt telefoniczny. Informacje o urządzeniach innych niż telefony
znajdziesz w Załączniku C.
8.14. Sterowanie głośnością
Urządzenia zgodne z Androidem MUSZĄ zawierać mechanizm umożliwiający użytkownikowi zwiększanie i zmniejszanie głośności
dźwięku. Implementacje na urządzeniu MUSZĄ udostępniać te funkcje użytkownikowi przez cały czas
,niezależnie od stanu aplikacji. Te funkcje mogą być implementowane za pomocą fizycznych klawiszy sprzętowych,
oprogramowania, gestów, panelu dotykowego itp., ale muszą być zawsze dostępne i nie mogą zasłaniać ani zakłócać
dostępnej powierzchni wyświetlacza aplikacji (patrz sekcja „Wyświetlacz” powyżej).
Gdy użytkownik używa tych przycisków, odpowiednie kluczowe zdarzenia MUSZĄ zostać wygenerowane i wysłane do aplikacji
na pierwszym planie. Jeśli zdarzenie nie zostanie przechwycone i odrzucone przez aplikację, implementacja urządzenia
MUSI obsłużyć zdarzenie jako system sterowania głośnością.
9. Zgodność z wydajnością
Jednym z celów programu zgodności z Androidem jest zapewnienie spójnego działania aplikacji dla konsumentów.
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żytkowników.
Wdrożenia na urządzeniach MUSZĄ spełniać kluczowe kryteria wydajności urządzeń zgodnych z Androidem 1.6,
jak w tabeli poniżej:
Dane
Próg wydajności
Komentarze

To jest testowane przez CTS.
Te aplikacje
Czas uruchamiania jest mierzony jako łączny czas
powinien się uruchomić w ramach
pełnego wczytania domyślnej aktywności w
Aplikacji
określonym czasie.
aplikacji, w tym czas potrzebny na uruchomienie
Czas uruchamiania
Przeglądarka: mniej niż 1300 ms
Proces Linux, wczytywanie pakietu Androida do
MMS/SMS: mniej niż 700 ms
Wirtualnej maszyny Dalvik i wywołania onCreate.
AlarmClock: mniej niż 650 ms
Uruchomione zostaną różne aplikacje
Testowane przez CTS.
Ponowne uruchomienie aplikacji
Równoległe pierwsze uruchomienie aplikacji
Aplikacje
powinno zająć mniej czasu niż
pierwotne uruchomienie.
10. Zgodność z modelem zabezpieczeń
Wdrożenia na urządzeniach MUSZĄ implementować model zabezpieczeń zgodny z modelem zabezpieczeń platformy Android
, jak określono w dokumentacji referencyjnej dotyczącej zabezpieczeń i uprawnień w interfejsach API [Zasoby, 29] w dokumentacji
dla deweloperów Androida. Implementacje urządzeń MUSZĄ obsługiwać instalowanie samodzielnie podpisanych aplikacji bez konieczności uzyskiwania dodatkowych uprawnień lub certyfikatów od stron trzecich/autorytetów.

W szczególności zgodne urządzenia MUSZĄ obsługiwać te mechanizmy zabezpieczeń:
10.1. Uprawnienia
Wdrożenia na urządzeniach MUSZĄ obsługiwać model uprawnień Androida określony w dokumentacji dla deweloperów
[Zasoby, 9]. W szczególności implementacje MUSZĄ stosować się do każdego uprawnienia
zdefiniowanego zgodnie z opisem w dokumentacji pakietu SDK. Żadne uprawnienia nie mogą być pomijane, zmieniane ani ignorowane.
Implementacje MOGĄ dodawać dodatkowe uprawnienia, o ile nowe ciągi znaków identyfikatora uprawnienia nie znajdują się w przestrzeni nazw
android.*.
10.2. Izolacja użytkowników i procesów
Wersje na urządzenia MUSZĄ obsługiwać model piaskownicy aplikacji na Androida, w którym każda aplikacja
działa jako unikalny identyfikator UID w stylu Unixa i w ramach osobnego procesu.
Wdrożenia urządzeń MUSZĄ obsługiwać uruchamianie wielu aplikacji z tym samym identyfikatorem użytkownika Linuksa, pod warunkiem, że aplikacje są odpowiednio podpisane i skonstruowane zgodnie z opisem w dokumentacji dotyczącej zabezpieczeń i uprawnień
[Resources, 29].

10.3. Uprawnienia dotyczące systemu plików
Wdrożenia na urządzeniach MUSZĄ obsługiwać model uprawnień dostępu do plików w Androidzie zgodnie z opisem w dokumentacji na temat zabezpieczeń i uprawnień [Resources, 29].

11. Compatibility Test Suite
Wdrożenia na urządzeniach MUSZĄ przejść testy zgodności z Androidem (Compatibility Test Suite, CTS) [Zasoby 3], dostępne w ramach projektu Android Open Source Project, korzystając z ostatecznego oprogramowania na urządzeniu.
Dodatkowo
implementatorzy urządzeń powinni w jak największym stopniu korzystać z implementacji referencyjnej w drzewie Androida Open Source oraz MUSZĄ zadbać o zgodność w przypadku niejednoznaczności w CTS i w przypadku wszelkich
reimplementacji części kodu źródłowego referencyjnego.

Test CTS jest przeznaczony do uruchamiania na rzeczywistym urządzeniu. Podobnie jak inne oprogramowanie, pakiet CTS może zawierać błędy.
Wersje pakietu CTS będą wydawane niezależnie od tej definicji zgodności, a na potrzeby Androida 1.6 może być wydawanych wiele wersji
CTS. Takie wersje będą jednak zawierać tylko poprawki błędów związanych z zachowaniem w testach CTS
i nie będą wprowadzać żadnych nowych testów, zachowań ani interfejsów API dla danej wersji platformy.
12. Skontaktuj się z nami
Aby uzyskać wyjaśnienia dotyczące
tej definicji zgodności lub podzielić się opinią na jej temat, skontaktuj się z zespołem ds. zgodności Androida pod adresem compatibility@android.com .

Załącznik A. Wymagane intencje aplikacji
UWAGA: ta lista jest tymczasowa i zostanie zaktualizowana w przyszłości.
Akcje aplikacji
Schematy Typy MIME
(nic)
tekst/zwykły
http
tekst/html
Przeglądarka
android.intent.action.VIEW
https
aplikacja/xhtml+xml
aplikacja/
vnd.wap.xhtml+xml
(nic)
android.intent.action.WEB_SEARCH
http
(nic)
https
android.media.action.PRZECHWYTYWANIE OBRAZU
android.media.action.KAMERA_ZDJĘCIOWA
Kamera
android.media.action.KAMERA_WIDEO
android.media.action.VIDEO_CAPTURE
vnd.android.kursor.dir/
android.intent.action.VIEW
obraz
android.intent.action.GET_CONTENT
vnd.android.kursor.dir/
android.intent.action.PICK
wideo
android.intent.action.ATTACH_DATA
obraz/*
wideo/*
android.intent.action.VIEW
rtsp
wideo/mp4
wideo/3gp
android.intent.action.VIEW
http
wideo/3gpp
wideo/3gpp2
android.intent.action.DIAL
Telefon /
android.intent.action.VIEW
telefon
Łączność
android.intent.action.CALL
android.intent.action.DIAL
vnd.android.kursor.dir/
android.intent.action.VIEW
osoba

vnd.android.kursor.dir/
osoba
vnd.android.kursor.dir/
android.intent.action.PICK
telefon
vnd.android.kursor.dir/
adres pocztowy
vnd.android.cursor.item/
osoba
vnd.android.cursor.item/
android.intent.action.GET_CONTENT
telefon
vnd.android.cursor.item/
adres pocztowy
tekst/zwykły
E-mail
android.intent.action.WYŚLIJ
obraz/*
wideo/*
android.intent.action.VIEW
wysłać pocztą
android.intent.action.WYŚLIJ DO
SMS-y
android.intent.action.VIEW
smsto
SMS / MMS android.intent.action.SENDTO
mms
mmsto
audio/*
aplikacja/ogg
Muzyka
android.intent.action.VIEW
plik
aplikacja/x-ogg
aplikacja/itunes
dźwięk/mp3
dźwięk/x-mp3
android.intent.action.VIEW
http
dźwięk/mpeg
dźwięk/mp4
dźwięk/mp4a-latm
vnd.android.kursor.dir/
album artystyczny
vnd.android.kursor.dir/
album
vnd.android.kursor.dir/
android.intent.action.PICK
aktualnie odtwarzane
vnd.android.kursor.dir/
ścieżka
nd.android.kursor.dir/
lista odtwarzania
vnd.android.kursor.dir/
wideo
głoska bezdźwięczna/*
audio/*
android.intent.action.GET_CONTENT
aplikacja/ogg
aplikacja/x-ogg
wideo/*

treść
Pakiet
android.intent.action.VIEW
plik
Instalator
pakiet
plik
android.intent.action.PACKAGE_INSTALL
http
https
android.intent.action.WSZYSTKIE_APLIKACJE
android.settings.USTAWIENIA
android.settings.USTAWIENIA_BEZPRZEWODOWE
android.settings.USTAWIENIA_TRYBU_SAMOLOTU
android.settings.WIFI_SETTINGS
android.settings.USTAWIENIA_APN
android.settings.USTAWIENIA_BLUETOOTH
android.settings.USTAWIENIA_DATY
android.settings.LOCALE_SETTINGS
Ustawienia
android.settings.USTAWIENIA_METODY_WEJŚCIOWEJ
com.android.settings.USTAWIENIA_DŹWIĘKU
com.android.settings.DISPLAY_SETTINGS
android.settings.USTAWIENIA_BEZPIECZEŃSTWA
android.settings.USTAWIENIA_ŹRÓDŁA_LOKACJI
android.settings.INTERNAL_STORAGE_SETTINGS
android.settings.USTAWIENIA_KARTY_PAMIĘCI
android.intent.action.SET_WALLPAPER
Szukaj
android.intent.action.SZUKAJ
zapytanie
android.intent.action.SEARCH_LONG_PRESS
Głos
android.intent.action.KOMENDA_GŁOSOWA
Zarządzanie kontaktami
Zamiar Akcja
Opis
Rozpoczyna działanie, które umożliwia użytkownikowi wybór
DOŁĄCZ OBRAZEK
kontakt, do którego można dołączyć obraz.
Używany
EXTRA_CREATE_DESCRIPTION
z SHOW_OR_CREATE_CONTACT do
określania dokładnego opisu, który ma być

wyświetlany, gdy użytkownik
tworzy nowy kontakt.
Używany
z SHOW_OR_CREATE_CONTACT do
EXTRA_FORCE_CREATE
wymuszania utworzenia nowego kontaktu, jeśli nie
zostanie znaleziony pasujący kontakt.
To jest intencja wywoływana, gdy użytkownik kliknie
SEARCH_SUGGESTION_CLICKED
sugestie wyszukiwania.
Ta intencja jest wywoływana, gdy użytkownik kliknie
SEARCH_SUGGESTION_CREATE_CONTACT_CLICKED sugestie wyszukiwania
dotyczącej utworzenia kontaktu.
To jest intencja wywoływana, gdy
SEARCH_SUGGESTION_DIAL_NUMBER_CLICKED
kliknięto propozycję wyszukiwania numeru telefonu
.
Weź pod uwagę, że jako dane wejściowe należy podać identyfikator URI danych z adresem mailto:
SHOW_OR_CREATE_CONTACT
lub schematem tel: .

Załącznik B. Wymagane intencje transmisjiUWAGA: ta lista jest tymczasowa i będzie
aktualizowana w przyszłości.
Działanie w intencji
Opis
Działanie w ramach transmisji: jest ono wysyłane raz po zakończeniu wczytywania systemu
ACTION_BOOT_COMPLETED
.
Działanie rozgłoszeniowe: jest ono rozgłaszane raz, gdy zostanie odebrany sygnał
ACTION_CALL_BUTTON
przez przycisk.
Działanie w ramach transmisji: naciśnięty został przycisk „Aparat”
ACTION_CAMERA_BUTTON
.
Działanie przesyłania: bieżąca
ACTION_CONFIGURATION_CHANGED
urządzenia Konfiguracja (orientacja, lokalizacja itp.)
uległa zmianie.
ACTION_DATE_CHANGED
Działanie rozgłoszenia: data została zmieniona.
Działanie w ramach transmisji: wskazuje na niski poziom pamięci
ACTION_DEVICE_STORAGE_LOW
na urządzeniu
Działanie w ramach transmisji: wskazuje na niski poziom pamięci
ACTION_DEVICE_STORAGE_OK
na urządzeniu nie istnieje już
Działanie w ramach transmisji: przewodowe słuchawki są podłączone lub
ACTION_HEADSET_PLUG
odłączone.
Działanie rozgłaszane: metoda wprowadzania została
ACTION_INPUT_METHOD_CHANGED
zmieniona.
Działanie w ramach transmisji: zewnętrzne nośniki zostały usunięte
ACTION_MEDIA_BAD_REMOVAL
z gniazda karty SD, ale punkt zamontowania nie został
odłączony.
Działanie transmisji: naciśnięty został przycisk „Media”
ACTION_MEDIA_BUTTON
.
Działanie transmisji: obecne są zewnętrzne nośniki danych i
jest przeprowadzana kontrola dysku. Ścieżka do punktu zamontowania dla
ACTION_MEDIA_CHECKING
nośnika danych do sprawdzania zawartości jest zawarta w polu
Intent.mData.
Działanie w ramach transmisji: użytkownik wyraził chęć
ACTION_MEDIA_EJECT
usunięcia zewnętrznego nośnika danych.
Działanie transmisji: obecne są nośniki zewnętrzne
ACTION_MEDIA_MOUNTED
zamontowane w punkcie montażu.
Działanie przesyłania: obecne są zewnętrzne nośniki, ale
używają one niekompatybilnego fs (lub jest pusty). Ścieżka do
ACTION_MEDIA_NOFS
punktu montowania dla nośników do sprawdzania
znajduje się w polu Intent.mData.
Działanie transmisji: zewnętrzne media zostały
ACTION_MEDIA_REMOVED
usunięte.
Działanie transmisji: skanowanie mediów zostało zakończone
ACTION_MEDIA_SCANNER_FINISHED
skanowanie katalogu.
Działanie transmisji: poproś skaner multimediów o
ACTION_MEDIA_SCANNER_SCAN_FILE
skanowanie pliku i dodanie go do bazy danych multimediów.

Działanie w ramach transmisji: skaner multimediów rozpoczął
ACTION_MEDIA_SCANNER_STARTED
skanowanie katalogu.
Działanie transmisji: nośnik zewnętrzny jest odmontowany
ACTION_MEDIA_SHARED
ponieważ jest udostępniany przez interfejs USB Mass Storage.
Działanie transmisji: nośnik zewnętrzny jest obecny, ale
ACTION_MEDIA_UNMOUNTABLE
nie można go zamontować.
Działanie transmisji: nośnik zewnętrzny jest obecny, ale
ACTION_MEDIA_UNMOUNTED
nie jest zamontowany w miejscu docelowym.
Działanie w ramach transmisji:
ACTION_NEW_OUTGOING_CALL
będzie nawiązywane.
Działanie w ramach transmisji: na urządzeniu zainstalowano nowy pakiet aplikacji
ACTION_PACKAGE_ADDED

Działanie rozgłoszenia: zmieniono istniejący pakiet aplikacji
ACTION_PACKAGE_CHANGED
(np. włączono lub wyłączono komponent
).
Działanie w ramach transmisji: użytkownik usunął dane
pakietu. Należy to poprzedzić
wiadomością ACTION_PACKAGE_RESTARTED, po której
wysłana zostaje wiadomość ACTION_PACKAGE_DATA_CLEARED
, a wszystkie trwałe dane są kasowane i wysyłana jest ta
wiadomość. Pamiętaj, że pakiet z oczyszczonymi danymi
nie otrzymuje tej transmisji. Dane zawierają
nazwę pakietu.
Działanie w ramach transmisji: istniejący pakiet aplikacji
został usunięty z urządzenia. Dane
ACTION_PACKAGE_REMOVED
zawierają nazwę pakietu. Instalowany pakiet
nie otrzymuje tej intencji.
Działanie przesyłania: zainstalowano nową wersję pakietu aplikacji
ACTION_PACKAGE_REPLACED
, która zastąpiła wcześniej zainstalowaną
.
Działanie rozgłoszenia: użytkownik ponownie uruchomił
pakiet, a wszystkie jego procesy zostały zakończone.
Cały stan działania powiązany z tym pakietem (procesy,
ACTION_PACKAGE_RESTARTED
alarmy, powiadomienia itp.) powinien zostać usunięty.
Pamiętaj, że wznowiony pakiet nie otrzymuje
tego kanału. Dane zawierają nazwę pakietu
.
Broadcast Action: niektórzy dostawcy treści mają
części swoich przestrzeni nazw, w których publikują nowe
ACTION_PROVIDER_CHANGED
zdarzenia lub elementy, które mogą szczególnie zainteresować użytkownika.

ACTION_SCREEN_OFF
Działanie przesyłania: wysyłane po wyłączeniu ekranu.
ACTION_SCREEN_ON
Działanie przesyłania: wysyłane po włączeniu ekranu.
Działanie transmisji: identyfikator użytkownika został usunięty
ACTION_UID_REMOVED
z systemu.
Działanie przesyłania: urządzenie weszło w tryb USB
ACTION_UMS_CONNECTED
Tryb pamięci masowej.

Działanie przesyłania: urządzenie wyłączyło tryb USB
ACTION_UMS_DISCONNECTED
Tryb pamięci masowej.
Działanie rozgłoszenia: wysyłane, gdy użytkownik jest obecny
ACTION_USER_PRESENT
po przebudzeniu urządzenia (np.gdy blokada ekranu
zniknie).
Działanie rozgłoszenia: zmieniło się bieżące tapeta pulpitu
ACTION_WALLPAPER_CHANGED
.
ACTION_TIME_CHANGED
Działanie przesyłania: ustawiono czas.
ACTION_TIME_TICK
Działanie transmisji: zmienił się bieżący czas.
ACTION_TIMEZONE_CHANGED
Działanie rozgłoszenia: strefa czasowa została zmieniona.
Akcja przesyłania: stan ładowania lub poziom naładowania
ACTION_BATTERY_CHANGED
baterii zmienił się.
Działanie w ramach transmisji: wskazuje niski stan naładowania baterii
ACTION_BATTERY_LOW
na urządzeniu. Ta transmisja odpowiada
dialogowi systemowemu „Ostrzeżenie o niskim stanie baterii”.
Działanie w ramach transmisji: wskazuje, że bateria jest w porządku
po tym, jak była słaba. Zostanie wysłana
ACTION_BATTERY_OKAY
po ACTION_BATTERY_LOW , gdy bateria
wróci do prawidłowego stanu.
Stan sieci
Działanie intencji
Opis
Działanie intencji rozgłoszenia wskazujące, że
NETWORK_STATE_CHANGED_ACTION
stan łączności Wi-Fi uległ zmianie.
Broadcast intent action indicating that the
RSSI_CHANGED_ACTION
RSSI (siła sygnału) has changed.
Broadcast intent action indicating that a
SUPPLICANT_STATE_CHANGED_ACTION
connection to the supplicant has been
established or lost.
Rozgłaszanie działania intencji wskazującego, że Wi-Fi
WIFI_STATE_CHANGED_ACTION
zostało włączone, wyłączone, jest włączane lub wyłączane albo jest nieznane.

Identyfikatory sieci skonfigurowanych sieci
NETWORK_IDS_CHANGED_ACTION
mogły ulec zmianie.
Akcja intencji przesyłania, która wskazuje, że
ustawienie
ACTION_BACKGROUND_DATA_SETTING_CHANGED dotyczące użycia danych w tle
zmieniło wartości.
Intencja rozgłoszenia wskazująca, że nastąpiła zmiana
CONNECTIVITY_ACTION
połączenia z siecią.
Działanie rozgłoszenia: użytkownik przełączył telefon
ACTION_AIRPLANE_MODE_CHANGED
w tryb samolotowy lub z niego.

Aneks C: przyszłe kwestie do rozważenia Ten aneks wyjaśnia niektóre części Definicji zgodności z Androidem
1.6, a w niektórych przypadkach omawia przewidywane lub planowane zmiany w przyszłej wersji platformy Android.
Ten dodatek służy wyłącznie do celów informacyjnych i planowania. Nie jest częścią definicji zgodności dla Androida 1.6.

1. Urządzenia inne niż telefony
Android 1.6 jest przeznaczony wyłącznie do telefonów; funkcje telefoniczne nie są opcjonalne. W przyszłych wersjach
platformy Android funkcje telefoniczne mają być opcjonalne (co umożliwi obsługę urządzeń z Androidem
innych niż telefony), ale tylko telefony są zgodne z Androidem 1.6.
2. Zgodność z Bluetooth
Android w wersji 1.6 nie obsługuje interfejsów Bluetooth API, więc pod względem zgodności
Bluetooth nie narzuca żadnych wymagań w przypadku tej wersji platformy. W przyszłej wersji
Androida zostaną jednak wprowadzone interfejsy API Bluetooth. Wtedy obsługa Bluetooth będzie wymagana ze względu na zgodność z
.
Dlatego zdecydowanie zalecamy, aby urządzenia z Androidem 1.6 miały Bluetooth, aby były kompatybilne z przyszłościowymi wersjami Androida, które będą wymagać Bluetootha.

3. Wymagane komponenty sprzętowe
Wszystkie komponenty sprzętowe wymienione w sekcji 8 (w tym Wi-Fi, magnetometr/kompas, akcelerometr itp.) są
wymagane i nie mogą być pominięte. W przyszłych wersjach Androida niektóre (ale nie wszystkie)
te komponenty staną się opcjonalne. Wraz z tym udostępnimy deweloperom zewnętrznym odpowiednie narzędzia do obsługi tych
zmian.
4. Przykładowe aplikacje
Dokument z definicją zgodności dla przyszłej wersji Androida będzie zawierać bardziej obszerną i
reprezentatywną listę aplikacji niż ta wymieniona w sekcji 4 powyżej. W przypadku Androida 1.6 należy przetestować aplikacje wymienione w sekcji 4.

5. Ekrany dotykowe
W przyszłych wersjach definicji zgodności może być dozwolone pomijanie ekranów dotykowych na urządzeniach.
Obecnie jednak wiele elementów implementacji platformy Android zakłada istnienie
ekranu dotykowego. Pominięcie ekranu dotykowego spowodowałoby znaczne uszkodzenie wszystkich obecnych aplikacji innych firm na Androida.
W Androidzie 1.6 ekran dotykowy jest wymagany do zapewnienia zgodności.

6. Wydajność
W przyszłych wersjach CTS będziemy też mierzyć wykorzystanie procesora i wydajność następujących
komponentów implementacji:
• grafika 2D
• grafika 3D
• odtwarzanie wideo
• odtwarzanie dźwięku
• odtwarzanie Bluetooth A2DP

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

Konspekt dokumentu

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