Interfejsy API Androida 4.0

Poziom API: 14

Android 4.0 (ICE_CREAM_SANDWICH) to duża wersja platformy, która dodaje różne nowe funkcje dla użytkowników dla programistów. Oprócz wszystkich nowych funkcji i interfejsów API omówionych poniżej Android 4.0 jest ważnym jako że udostępnia ona bogaty zestaw interfejsów API i holograficznych motywów z Androida 3.x na mniejsze ekrany. Jako deweloper aplikacji masz teraz jedną platformę i ujednoliconą platformę interfejsów API który umożliwia opracowanie i opublikowanie aplikacji za pomocą jednego pliku APK, który udostępnia zoptymalizowaną pod kątem telefonów, tabletów i innych urządzeń, gdy ta sama wersja Android – Android 4.0 (poziom interfejsu API 14) lub nowszy.

Dla programistów platforma Android 4.0 jest dostępna jako dostępny do pobrania komponent Android SDK. Platforma do pobrania zawiera biblioteki Androida i obraz systemu, a także zestaw skórek emulatora i innych. Aby rozpocząć tworzenie lub testowanie wersji Androida 4.0, użyj Menedżera pakietów Android SDK, aby pobrać platformę do pakietu SDK.

Omówienie interfejsu API

Poniższe sekcje zawierają omówienie techniczne nowych interfejsów API w Androidzie 4.0.

Interfejsy API społecznościowe w usłudze Kontakty

Interfejsy API kontaktów zdefiniowane przez dostawcę ContactsContract zostały Rozbudowana o nowe funkcje społecznościowe, takie jak osobisty profil właściciela urządzenia możliwość zapraszania poszczególnych kontaktów do sieci społecznościowych, urządzenia.

Profil użytkownika

Android zawiera teraz profil osobisty reprezentujący właściciela urządzenia zdefiniowany przez Tabela ContactsContract.Profile. Aplikacje społecznościowe, które zachowują tożsamość użytkowników może współtworzyć dane profilowe użytkownika, tworząc nowy wpis ContactsContract.RawContacts w elemencie ContactsContract.Profile. Oznacza to, że nieprzetworzone kontakty, które reprezentują użytkownika urządzenia, nie należą do tradycyjnej tabeli nieprzetworzonych kontaktów zdefiniowanej przez identyfikator URI ContactsContract.RawContacts; musisz dodać do profilu nieprzetworzony kontakt stolik na CONTENT_RAW_CONTACTS_URI. Nierafinowane Kontakty w tej tabeli są następnie agregowane w pojedynczy widoczny dla użytkownika profil o nazwie „Ja”.

Dodanie nowego nieprzetworzonego kontaktu w profilu wymaga Uprawnienie android.Manifest.permission#WRITE_PROFILE. Podobnie, aby czytać z poziomu profilu , musisz poprosić o uprawnienie android.Manifest.permission#READ_PROFILE. Pamiętaj jednak: większość aplikacji nie musi odczytywać profilu użytkownika, nawet jeśli udostępnia dane profil. Odczytywanie profilu użytkownika jest uprawnieniem poufnym i możesz oczekiwać, że sceptycznie wobec aplikacji, które o to proszą.

Zamiar zaproszenia

Działanie intencji INVITE_CONTACT umożliwia aplikacji aby wywołać działanie wskazujące, że użytkownik chce dodać kontakt do sieci społecznościowej. Aplikacja odbierający aplikację używa jej, aby zaprosić określony kontakt do tego sieć społecznościowa. Większość aplikacji zostanie odesłanych przez tę operację. Na przykład parametr wbudowana aplikacja Osoby wywołuje intencję zaproszenia, gdy użytkownik wybierze „Dodaj połączenie” dla określonego aplikację społecznościową wymienioną w danych kontaktowych użytkownika.

Aby aplikacja była widoczna jako widoczna po wybraniu opcji „Dodaj połączenie” aplikacja musi udostępniać adapter synchronizacji synchronizować informacje kontaktowe z Twojej sieci społecznościowej. Następnie należy wskazać systemowi, aplikacja odpowiada na intencję INVITE_CONTACT przez dodaj atrybut inviteContactActivity do pliku konfiguracji synchronizacji aplikacji z atrybutem pełna i jednoznaczna nazwa działania, które system powinien uruchamiać się po wysłaniu intencji zaproszenia. Rozpoczęte działanie może następnie pobrać identyfikator URI kontaktu, którego dotyczy problem, z metody intencji swoje dane i wykonać czynności niezbędne do zaproszenia tego kontaktu do sieci lub dodania osoby do połączeń użytkownika.

Duże zdjęcia

Android obsługuje teraz zdjęcia kontaktów w wysokiej rozdzielczości. Po przekazaniu zdjęcia do system przetwarza go zarówno na miniaturę 96x96 (tak jak wcześniej), „Wyświetl zdjęcie” 256 x 256 przechowywanych w nowym magazynie zdjęć opartym na plikach (dokładnie wymiary, system może w przyszłości ulec zmianie). Aby dodać do kontaktu duże zdjęcie, umieść duże zdjęcie w zwykłej kolumnie PHOTO, danych, który system przetwarza na odpowiednią miniaturę i wyświetla zdjęcie. .

Opinie na temat użytkowania kontaktów

Nowe interfejsy API ContactsContract.DataUsageFeedback pomagają śledzić jak często użytkownik korzysta z określonych metod kontaktu z innymi osobami, np. jak często używa każdy numer telefonu lub adres e-mail. Te informacje pomagają poprawić pozycję kontaktu w rankingu z daną osobą i zapewniają lepsze sugestie dotyczące kontaktowania się z nią.

Dostawca kalendarza

Nowe interfejsy API kalendarza umożliwiają odczytywanie, dodawanie, modyfikowanie i usuwanie kalendarzy, wydarzeń, uczestników przypomnienia i alerty, które są przechowywane u dostawcy kalendarza.

Wiele aplikacji i widżetów może używać tych interfejsów API do odczytywania i modyfikowania wydarzeń w kalendarzu. Pamiętaj jednak: z najbardziej przekonujących przypadków użycia są adaptery synchronizacji, które synchronizują kalendarz użytkownika z innymi usługami kalendarza, aby zapewnić jednolitą lokalizację dla wszystkich zdarzeń użytkownika. Wydarzenia z Kalendarza Google są na przykład synchronizowane z dostawcą kalendarza przez Adapter synchronizacji Kalendarza Google, który umożliwia wyświetlanie takich wydarzeń Kalendarz.

Model danych dla kalendarzy i informacji związanych z wydarzeniami u dostawcy kalendarza to zdefiniowane przez CalendarContract. Wszystkie dane kalendarza użytkownika są przechowywane w liczba tabel zdefiniowanych przez różne podklasy klasy CalendarContract:

  • Tabela CalendarContract.Calendars zawiera tabelę z danymi kalendarzowymi i informacjami o nich. Każdy wiersz w tej tabeli zawiera szczegóły pojedynczego kalendarza, takie jak jego nazwa, kolor, dane o synchronizacji itp.
  • Tabela CalendarContract.Events zawiera informacje dotyczące zdarzeń. Każdy wiersz tej tabeli zawiera informacje o pojedynczym zdarzeniu, takie jak tytuł, lokalizacja, czas rozpoczęcia, czas zakończenia itd. Zdarzenie może mieć miejsce jednorazowo lub cyklicznie wiele razy. Uczestnicy, przypomnienia i właściwości rozszerzone są przechowywane w oddzielnych tabelach i użyj właściwości _ID wydarzenia, aby połączyć je z tym wydarzeniem.
  • Tabela CalendarContract.Instances zawiera godziny rozpoczęcia i zakończenia dla okresu wystąpienia zdarzenia. Każdy wiersz w tej tabeli odpowiada 1 wystąpieniu. Wydarzenia jednorazowe istnieje mapowanie instancji 1:1 na zdarzenia. W przypadku wydarzeń cyklicznych wiele wierszy jest generowane automatycznie, aby odpowiadały wielokrotnemu wystąpieniu danego zdarzenia.
  • Tabela CalendarContract.Attendees zawiera uczestnika lub gościa wydarzenia i informacjami o nich. Każdy wiersz odpowiada jednemu gościa wydarzenia. Określa typ gościa oraz odpowiedź tej osoby na wydarzenie.
  • Tabela CalendarContract.Reminders zawiera dane alertów/powiadomień. Każdy wiersz odpowiada jednemu alertowi dla zdarzenia. Wydarzenie może zawierać wiele przypomnień. Liczba przypomnień na zdarzenie jest określana w MAX_REMINDERS, która jest ustawiana przez adapter synchronizacji, właścicielem danego kalendarza. Przypomnienia są podawane w ciągu liczby minut przed wydarzeniem zaplanować i określić metodę alarmu, np. przy użyciu alertu, e-maila lub SMS-a użytkownika.
  • Tabela CalendarContract.ExtendedProperties zawiera nieprzezroczyste pola danych używane przez adapter synchronizacji. Dostawca nie wykonuje żadnych działań z elementami w tej tabeli z wyjątkiem usunięcia po usunięciu powiązanych z nimi wydarzeń.

Aby uzyskać dostęp do danych kalendarza użytkownika za pomocą dostawcy kalendarza, aplikacja musi poprosić o dostęp uprawnienia READ_CALENDAR (dostęp do odczytu) oraz WRITE_CALENDAR (dostęp do zapisu).

Intencja zdarzenia

Jeśli chcesz tylko dodać wydarzenie do kalendarza użytkownika, możesz użyć intencji ACTION_INSERT z danymi zdefiniowanymi przez Events.CONTENT_URI, aby rozpocząć aktywność w aplikacji Kalendarz, która tworzy nowe wydarzenia. Użycie intencji nie wymaga dodania uprawnienia i możesz określić szczegóły wydarzenia, dodając następujące dodatki:

Dostawca poczty głosowej

Nowy dostawca poczty głosowej umożliwia aplikacjom dodawanie wiadomości głosowych do na urządzeniu w celu przedstawienia wszystkich wiadomości głosowych użytkownika w jednej prezentacji wizualnej. Przykład: możliwe, że użytkownik ma wiele źródeł poczty głosowej, jedno od operatora sieci komórkowej, a inne dane VoIP lub innego głosu usług Google. Te aplikacje mogą dodawać wiadomości głosowe do urządzenia za pomocą interfejsów API dostawcy poczty głosowej. z wbudowaną aplikacją Telefon, następnie prezentuje wszystkie wiadomości głosowe w ujednoliconej prezentacji. Mimo że systemowa aplikacja Telefon jest jedyną aplikacją, która może odczytać wszystkie wiadomości głosowe, każda aplikacja udostępniająca pocztę głosową może odczytywać wiadomości dodane do systemu (ale nie odczytywanie poczty głosowej z innych usług).

Ponieważ obecnie interfejsy API nie zezwalają aplikacjom innych firm na odczytywanie całej poczty głosowej jedynymi aplikacjami innych firm, które powinny korzystać z interfejsów API poczty głosowej, są aplikacje obsługujące pocztę głosową. które chcesz przedstawić użytkownikowi.

Klasa VoicemailContract określa dostawcę treści dla komponentu Provder poczty głosowej. Podklasy VoicemailContract.Voicemails i VoicemailContract.Status zawierają tabele, w których aplikacje mogą wstawić dane poczty głosowej w celu przechowywania ich na urządzeniu. Przykładową aplikację dostawcy poczty głosowej znajdziesz w Dostawca poczty głosowej Wersja demonstracyjna.

Multimedia

Do Androida 4.0 dodaliśmy kilka nowych interfejsów API dla aplikacji korzystających z multimediów, takich jak zdjęcia, filmów i muzyki.

Efekty multimedialne

Nowa platforma efektów multimedialnych umożliwia stosowanie różnych efektów wizualnych do obrazów i obrazów. filmy. Efekty graficzne pozwalają np. usunąć efekt czerwonych oczu, przekonwertować obraz na tryb szarości, Dostosuj jasność, nasycenie, obróć zdjęcie, zastosuj efekt rybiego oka i nie tylko. do uzyskania maksymalnej wydajności system wykonuje wszystkie przetwarzanie efektów w GPU.

Aby uzyskać maksymalną wydajność, efekty są stosowane bezpośrednio do tekstur OpenGL, dzięki czemu aplikacja musi mieć prawidłowy kontekst OpenGL, aby móc używać interfejsów API efektów. Tekstury, do których zastosujesz tekstury mogą to być mapy bitowe, filmy, a nawet efekt aparatu. Istnieją jednak pewne ograniczenia, tekstury muszą spełniać:

  1. Muszą być powiązane z obrazem tekstury GL_TEXTURE_2D
  2. Muszą zawierać co najmniej 1 poziom miMPmap

Obiekt Effect definiuje pojedynczy efekt multimedialny, do którego możesz go zastosować w ramce obrazu. Podstawowy proces tworzenia obiektu Effect:

  1. Wywołaj funkcję EffectContext.createWithCurrentGlContext() z kontekstu OpenGL ES 2.0.
  2. Użyj zwróconego pola EffectContext, aby wywołać funkcję EffectContext.getFactory(), która zwraca instancję z EffectFactory.
  3. Zadzwoń do użytkownika createEffect() i przekaż go nazwa efektu z @link android.media.effect.EffectFactory}, na przykład EFFECT_FISHEYE lub EFFECT_VIGNETTE.

Parametry efektu możesz dostosować, wywołując funkcję setParameter() i przekazując nazwę i wartość parametru. Każdy rodzaj efektu jest akceptowany różnych parametrów, które są opisane wraz z nazwą efektu. Na przykład pole EFFECT_FISHEYE zawiera 1 parametr dla argumentu scale funkcji lub zniekształcenia.

Aby zastosować efekt na teksturę, wywołaj funkcję apply() w Effect i przekazać teksturę wejściową, szerokość i wysokość oraz dane wyjściowe, teksturę. Tekstura wejściowa musi być powiązana z teksturą GL_TEXTURE_2D obrazu (zwykle wykonywane jest wywołanie metody glTexImage2D() ). Możesz udostępnić wiele poziomów mipmmap. Jeśli tekstura wyjściowa nie była powiązana z zostanie on automatycznie powiązany z tym efektem jako obiekt GL_TEXTURE_2D i z jednym poziomem mipmmap (0), który będzie miał taki sam jako danych wejściowych.

Wszystkie efekty wymienione w EffectFactory muszą być obsługiwane. Pewne dodatkowe efekty dostępne w bibliotekach zewnętrznych nie są jednak obsługiwane na wszystkich urządzeniach, więc musisz najpierw sprawdzić, czy pożądany efekt z zewnętrznej biblioteki jest obsługiwany przez wywołanie isEffectSupported()

Klient pilota

RemoteControlClient umożliwia odtwarzaczom multimediów włączanie odtwarzania elementów sterujących z klientów zdalnego sterowania, takich jak ekran blokady urządzenia. Odtwarzacze multimedialne mogą też informacje o multimediach odtwarzanych w danym momencie na pilocie, takie jak utwór informacje i okładkę albumu.

Aby umożliwić korzystanie z klientów zdalnego sterowania w odtwarzaczu, utwórz wystąpienie RemoteControlClient za pomocą jego konstruktora, przekazując do niego wartość PendingIntent, która wysyła komunikat ACTION_MEDIA_BUTTON. Intencja musi też zadeklarować w aplikacji jawny komponent BroadcastReceiver, który obsługuje zdarzenie ACTION_MEDIA_BUTTON.

Aby zadeklarować, które wejścia sterowania multimediami może obsługiwać odtwarzacz, musisz wywołać funkcję setTransportControlFlags() na RemoteControlClient, przekazując zestaw flag FLAG_KEY_MEDIA_*, taki jak FLAG_KEY_MEDIA_PREVIOUS i FLAG_KEY_MEDIA_NEXT.

Musisz wtedy zarejestrować RemoteControlClient, przekazując go firmie MediaManager.registerRemoteControlClient(). Po rejestracji odbiornik zadeklarowany przy tworzeniu instancji RemoteControlClient otrzyma ACTION_MEDIA_BUTTON zdarzeń po naciśnięciu przycisku na pilocie. Odebrana intencja zawiera element KeyEvent powiązany z naciśniętym klawiszem multimedialnym, który można pobrać z intencji za pomocą funkcji getParcelableExtra(Intent.EXTRA_KEY_EVENT).

Aby wyświetlić na pilocie informacje o odtwarzanych multimediach, wywołaj editMetaData() i dodaj metadane do zwróconego RemoteControlClient.MetadataEditor Możesz dodać bitmapę dla grafiki multimedialnej, dane liczbowe, takie jak czas, jaki upłynął, oraz dane tekstowe, np. tytuł utworu. Dla: informacje o dostępnych kluczach są widoczne dla flag METADATA_KEY_* w języku MediaMetadataRetriever.

Przykładową implementację znajdziesz w sekcji Losowy odtwarzacz muzyki, który zapewnia logikę zgodności, która pozwala na korzystanie z klienta zdalnego sterowania na Androidzie 4.0 tych urządzeń, a jednocześnie nadal obsługiwać urządzenia z Androidem 2.1.

Odtwarzacze multimediów

  • Strumieniowe przesyłanie multimediów online z urządzenia MediaPlayer wymaga teraz uprawnienia INTERNET. Jeśli używasz aplikacji MediaPlayer do: odtwarzania treści z internetu, pamiętaj, aby dodać INTERNET dostęp do pliku manifestu, w przeciwnym razie odtwarzanie multimediów nie będzie działać na Androidzie 4,0
  • setSurface() umożliwia zdefiniowanie obiektu Surface, który ma działać jako ujście wideo.
  • setDataSource() umożliwia: wysyłać razem z żądaniem dodatkowe nagłówki HTTP, które mogą być przydatne podczas transmisji na żywo przez HTTP(S)
  • Transmisje na żywo przez HTTP(S) obsługują teraz pliki cookie HTTP w żądaniach

Typy multimediów

Android 4.0 obsługuje:

  • Protokół transmisji na żywo HTTP/HTTPS w wersji 3
  • Nieprzetworzone kodowanie dźwięku AAC w ADTS
  • Obrazy WEBP
  • Matroska – film

Aby dowiedzieć się więcej, zobacz Obsługiwane multimedia Formaty.

Aparat

Klasa Camera zawiera teraz interfejsy API do wykrywania twarzy i sterowania i obszary pomiaru.

Wykrywanie twarzy

Aplikacje aparatu mogą teraz zwiększać swoje możliwości dzięki interfejsom API do wykrywania twarzy na Androidzie, które nie wymagają wykrywają tylko twarz obiektu, ale też określone rysy twarzy, np. oczy czy usta.

Aby wykrywać twarze w aplikacji aparatu, musisz zarejestrować Camera.FaceDetectionListener, wywołując setFaceDetectionListener(). Następnie możesz powierzchnię kamery i zacząć wykrywać twarze, dzwoniąc pod numer startFaceDetection().

Gdy system wykryje co najmniej 1 twarz w scenie kamery, wywoła wywołanie zwrotne onFaceDetection() na implementacja Camera.FaceDetectionListener, w tym tablicę Camera.Face obiektów.

Instancja klasy Camera.Face dostarcza różnych informacji o wykrytej twarzy, w tym:

  • Rect, który określa granice ścianki względem bieżące pole widzenia
  • Liczba całkowita z zakresu od 1 do 100, która wskazuje, z jaką pewnością system jest pewny, że obiekt ludzka twarz
  • Unikalny identyfikator umożliwiający śledzenie wielu twarzy
  • Kilka obiektów Point, które wskazują, gdzie znajdują się oczy i usta z siedzibą

Uwaga: wykrywanie twarzy może nie być obsługiwane na niektórych urządzeniach urządzeń, więc sprawdź, kontaktując się z firmą getMaxNumDetectedFaces() i upewnij się, że produkt został zwrócony jest większa od zera. Niektóre urządzenia mogą nie obsługiwać rozpoznawania oczu i ust. W takim przypadku pola te w obiekcie Camera.Face będą miały wartość null.

Główny obszar i pomiary

Aplikacje aparatu mogą teraz kontrolować obszary, których używa aparat do ustawiania ostrości i pomiaru bieli saldo i automatyczną ekspozycję. Obie funkcje używają nowej klasy Camera.Area do określania obszar bieżącego pola widzenia kamery, który powinien być ustawiony jako obszar ostrości lub z pomiarem użycia danych. Wystąpienie klasy Camera.Area określa granice obszaru z atrybutem Rect oraz wagę obszaru, co oznacza poziom ważności w odniesieniu do innych uwzględnionych obszarów – jest to liczba całkowita.

Przed ustawieniem ostrości lub obszaru pomiaru musisz najpierw wywołać odpowiednio getMaxNumFocusAreas() lub getMaxNumMeteringAreas(). Jeśli te wyniki zwracają zero, urządzenie nie obsługuje odpowiedniej funkcji.

Aby określić główny obszar pomiaru lub obszar pomiaru, zadzwoń pod numer setFocusAreas() lub setMeteringAreas(). Każda z nich to List z Camera.Area obiektów wskazujących obszary do rozważenia. do ustawiania ostrości lub pomiaru wykorzystania limitu. Możesz na przykład wdrożyć funkcję, która pozwala użytkownikowi ustawiać obszar ostrości, dotykając obszaru podglądu. Następnie przetłumaczysz go na obiekt Camera.Area i ustawisz w polu widzenia kamery prośbę o skupienie się na tym obszarze sceny. Ostrość lub ekspozycja w tym obszarze są stale aktualizowane wraz ze zmianą scen.

Ciągły autofokus podczas robienia zdjęć

Możesz teraz włączyć ciągłe autofokus podczas robienia zdjęć. Aby włączyć CAF w aplikacja aparatu, przekaż FOCUS_MODE_CONTINUOUS_PICTURE do: setFocusMode(). Gdy wszystko gotowe zdjęcie, zadzwoń pod autoFocus(). Na urządzeniu Camera.AutoFocusCallback natychmiast zostanie oddzwonione, aby określić, czy udało się uzyskać informacje. Aby wznowić CAF po otrzymaniu wywołania zwrotnego, musisz wywołać funkcję cancelAutoFocus().

Uwaga: ciągły autofokus jest też obsługiwany podczas nagrywania za pomocą funkcji FOCUS_MODE_CONTINUOUS_VIDEO, która była dodano w API poziomu 9.

Inne funkcje aparatu

  • Podczas nagrywania filmu możesz teraz zadzwonić pod numer takePicture(), aby zapisać zdjęcie bez przerywania sesji wideo. Zanim to zrobisz, Wywołaj isVideoSnapshotSupported(), aby upewnić się, że sprzęt który ją obsługuje.
  • Możesz teraz zablokować automatyczną ekspozycję i balans bieli za pomocą funkcji setAutoExposureLock() i setAutoWhiteBalanceLock(), tych właściwości.
  • Podczas podglądu z aparatu możesz teraz wywołać funkcję setDisplayOrientation(). Wcześniej można było nazwać ją tylko przed rozpoczęciem podglądu. Teraz orientację można zmienić w dowolnej chwili.

Intencje przesyłania z kamery

  • Camera.ACTION_NEW_PICTURE: Oznacza to, że użytkownik zrobił nowe zdjęcie. Wbudowana aplikacja Aparat wywołuje tę przesyła komunikat po zrobieniu zdjęcia, a aplikacje innych firm również powinny przesyłać tę intencję po zrobieniu zdjęcia.
  • Camera.ACTION_NEW_VIDEO: Oznacza to, że użytkownik nagrał nowy film. Wbudowana aplikacja Aparat wywołuje tę jest przesyłana po nagraniu filmu, a aplikacje innych firm również powinny przesyłać tę intencję po nagraniu filmu.

Android Beam (NDEF Push z NFC)

Android Beam to nowa funkcja NFC, która umożliwia wysyłanie wiadomości NDEF z jednego urządzenia na innego (proces znany również jako „NDEF Push”). Przenoszenie danych rozpoczyna się, gdy 2 z nich Urządzenia z Androidem obsługujące Android Beam znajdują się w niewielkiej odległości (około 4 cm) się stykają. Dane wewnątrz wiadomości NDEF mogą zawierać dowolne dane, które chcesz udostępnić między urządzeniami. Na przykład aplikacja Osoby udostępnia kontakty, YouTube udostępnia filmy, a przeglądarka udostępnia adresy URL za pomocą Android Beam.

Aby przesyłać dane między urządzeniami przy użyciu Android Beam, musisz utworzyć NdefMessage zawierający informacje, które chcesz udostępniać w czasie trwania aktywności na pierwszym planie. Następnie musisz przekazać NdefMessage do systemu w jednym z dwóch sposoby:

  • Zdefiniuj pojedynczy element NdefMessage do przekazania w trakcie aktywności:

    Zadzwoń do użytkownika setNdefPushMessage() w dowolnym momencie, aby ustawić wiadomość, którą chcesz wysłać. Możesz na przykład wywołać tę metodę i przekazać ją jako NdefMessage podczas onCreate() aktywności . Następnie za każdym razem, gdy Android Beam zostanie aktywowany na innym urządzeniu w czasie, gdy aktywność pierwszy plan, system wysyła NdefMessage do drugiego urządzenia.

  • Określ NdefMessage, który ma zostać przekazany w momencie inicjowania funkcji Android Beam:

    Wdrożenie funkcji NfcAdapter.CreateNdefMessageCallback, w której: implementacja interfejsu createNdefMessage() zwraca wartość NdefMessage, którą chcesz wysłać. Następnie przekaż implementację NfcAdapter.CreateNdefMessageCallback do setNdefPushMessageCallback().

    W tym przypadku, gdy funkcja Android Beam zostanie aktywowana na innym urządzeniu, gdy aktywność jest w na pierwszym planie system wywołuje metodę createNdefMessage(), aby pobrać NdefMessage, który chcesz wysłać. Pozwala to określić, że NdefMessage ma uruchamiać się tylko po zainicjowaniu funkcji Android Beam, w przypadku, gdy dane może zmieniać się przez cały czas trwania działania.

Na wypadek, gdyby chcesz uruchomić określony kod po pomyślnym dostarczeniu pliku NDEF przez system na inne urządzenie, możesz zaimplementować NfcAdapter.OnNdefPushCompleteCallback i ustawić je za pomocą setNdefPushCompleteCallback(). System a następnie wywołaj onNdefPushComplete() po dostarczeniu wiadomości.

Z urządzenia odbierającego system wysyła wiadomości NDEF Push, podobnie jak zwykłe NFC. . System wywołuje intencję za pomocą funkcji ACTION_NDEF_DISCOVERED. aby rozpocząć aktywność, z adresem URL lub typem MIME ustawionym zgodnie z pierwszym NdefRecord w NdefMessage. W przypadku wybranej aktywności możesz zadeklarować filtry intencji dla adresów URL lub typów MIME, które są uwzględniane w aplikacji. Więcej informacje o wysyłaniu tagów znajdziesz w przewodniku dla programistów NFC.

Jeśli chcesz, aby urządzenie NdefMessage nosiło identyfikator URI, możesz teraz skorzystać z dodatkowych funkcji createUri do utworzenia nowego obiektu NdefRecord na podstawie ciągu znaków lub obiektu Uri. Jeśli identyfikator URI to w specjalnym formacie, który chcesz otrzymywać także podczas wydarzenia Android Beam, utworzyć filtr intencji dla Twojej aktywności, korzystając z tego samego schematu URI, przychodząca wiadomość NDEF.

Należy również przesłać „Rekord aplikacji na Androida” z urządzeniem NdefMessage w aby zagwarantować, że aplikacja będzie obsługiwać przychodzącą wiadomość NDEF, nawet jeśli inne filtrowanie aplikacji pod kątem tego samego działania intencji. Rekord aplikacji na Androida możesz utworzyć przez dzwoni do: createApplicationRecord(), przekazuję nazwę pakietu aplikacji. Gdy drugie urządzenie otrzyma wiadomość NDEF z identyfikatorem rekord aplikacji, a wiele aplikacji zawiera działania, które obsługują określoną intencję, system zawsze dostarcza komunikat do działania w aplikacji (na podstawie dopasowania rekord aplikacji). Jeśli na urządzeniu docelowym nie jest obecnie zainstalowana Twoja aplikacja, parametr system używa rekordu aplikacji Android do uruchomienia Google Play i przekierowania użytkownika do strony aplikacji.

Jeśli aplikacja nie używa interfejsów NFC do wysyłania wiadomości Push NDEF, Android udostępnia domyślne działanie: gdy aplikacja działa na pierwszym planie na jednym urządzeniu, a Android Beam jest wywołanego z innego urządzenia z systemem Android, to drugie urządzenie otrzyma komunikat NDEF z Rekord aplikacji na Androida, który ją identyfikuje. Jeśli urządzenie odbierające ma zainstalowana aplikacja, system ją uruchamia; jeśli nie jest zainstalowana, otwiera się Google Play i pobiera użytkownika do Twojej aplikacji w celu jej zainstalowania.

Więcej informacji o Android Beam i innych funkcjach NFC znajdziesz w przewodniku dla programistów Podstawy komunikacji NFC. Przykładowy kod przy użyciu Android Beam, zapoznaj się z sekcją Android Beam Tryb demonstracyjny Beam.

Wi-Fi P2P

Android obsługuje teraz połączenia Wi-Fi peer-to-peer (P2P) między urządzeniami z Androidem innych typów urządzeń (zgodnie z normą Wi-Fi DirectTM organizacji Wi-Fi Alliance. programu certyfikacji) bez użycia hotspotu czy połączenia z internetem. Platforma Androida zapewnia zestaw interfejsów API Wi-Fi P2P, które umożliwiają wykrywanie innych urządzeń i łączenie się z nimi, gdy każde urządzenie obsługuje sieć Wi-Fi P2P, a następnie komunikuje się za pomocą szybkiego połączenia na odległość znacznie większą niż Połączenie Bluetooth.

Nowy pakiet (android.net.wifi.p2p) zawiera wszystkie interfejsy API do obsługi połączeń peer-to-peer połączenia z Wi-Fi. Klasa podstawowa, z którą musisz pracować, to WifiP2pManager. Możesz ją uzyskać, wywołując metodę getSystemService(WIFI_P2P_SERVICE). WifiP2pManager obejmuje interfejsy API, które umożliwiają:

  • Zainicjuj aplikację dla połączeń P2P, wywołując initialize()
  • Wykrywaj urządzenia w pobliżu, dzwoniąc pod numer discoverPeers()
  • Rozpocznij połączenie P2P, dzwoniąc pod numer connect()
  • I nie tylko

Potrzebne są też inne interfejsy i klasy, takie jak:

  • Interfejs WifiP2pManager.ActionListener umożliwia otrzymywanie wywołań zwrotnych, gdy operacja, taka jak znajdowanie elementów równorzędnych lub nawiązywanie z nimi połączenia, zakończy się sukcesem lub niepowodzeniem.
  • Interfejs WifiP2pManager.PeerListListener umożliwia odbieranie i informacjach o wykrytych węzłach. Wywołanie zwrotne udostępnia element WifiP2pDeviceList, z którego można pobrać obiekt WifiP2pDevice dla każdego urządzenia w zasięgu i uzyskać takie informacje jak: nazwę urządzenia, adres, typ urządzenia, konfiguracje WPS obsługiwane przez urządzenie itp.
  • Dzięki interfejsowi WifiP2pManager.GroupInfoListener możesz: uzyskać informacje o grupie P2P. Wywołanie zwrotne dostarcza obiekt WifiP2pGroup z informacjami o grupie, takimi jak właściciel, nazwę sieci i hasło.
  • Interfejs WifiP2pManager.ConnectionInfoListener umożliwia otrzymywać informacje o bieżącym połączeniu. Wywołanie zwrotne dostarcza obiekt WifiP2pInfo z informacją, na przykład, czy grupa została oraz kto jest właścicielem grupy.

Aby korzystać z interfejsów API sieci Wi-Fi P2P, aplikacja musi prosić o te uprawnienia użytkownika:

  • ACCESS_WIFI_STATE
  • CHANGE_WIFI_STATE
  • INTERNET (chociaż aplikacja nie łączy się technicznie połączenia z internetem, komunikowanie się z sieciami Wi-Fi P2P przy użyciu standardowych gniazd java wymaga dostępu do internetu. uprawnienia).

Podczas niektórych zdarzeń związanych z siecią Wi-Fi P2P system Android przesyła też kilka różnych działań:

Więcej informacji znajdziesz w dokumentacji usługi WifiP2pManager. Poza tym spójrz na Prezentacja sieci Wi-Fi P2P przykładową aplikację.

Urządzenia Bluetooth Health

Android obsługuje teraz urządzenia z profilem zdrowia Bluetooth, więc można tworzyć aplikacje, które korzystają Bluetooth do komunikacji z urządzeniami zdrowotnymi obsługującymi Bluetooth, takimi jak pulsometr, mierniki krwi, termometry i wagi.

Podobnie jak w przypadku zwykłych zestawów słuchawkowych i urządzeń z profilem A2DP, aby nawiązać połączenie z profilem, musisz wywołać getProfileProxy() za pomocą typu BluetoothProfile.ServiceListener i HEALTH. obiektu proxy.

Gdy uzyskasz proxy Health Profile (BluetoothHealth ), nawiązanie połączenia ze sparowanymi urządzeniami zdrowotnymi i komunikowanie się z nimi wiąże się z następującymi nowymi Klasy Bluetootha:

  • BluetoothHealthCallback: musisz rozszerzyć tę klasę i zaimplementować metodę metod wywołania zwrotnego do otrzymywania aktualizacji o zmianach stanu rejestracji aplikacji oraz Stan kanału Bluetooth.
  • BluetoothHealthAppConfiguration: podczas wywołań zwrotnych do BluetoothHealthCallback otrzymasz wystąpienie tego obiektu, które dostarcza informacje o konfiguracji dostępnych urządzeń do monitorowania stanu Bluetooth, których należy użyć do wykonywania różnych operacji, takich jak inicjowanie i kończenie połączeń za pomocą interfejsów API BluetoothHealth.

Więcej informacji o korzystaniu z profilu Bluetooth Health Profile znajdziesz w dokumentacji urządzenia BluetoothHealth.

Ułatwienia dostępu

Android 4.0 to ułatwienie dla użytkowników z wadą wzroku dzięki nowemu trybowi poznawania dotykiem. i rozszerzonych interfejsach API, które pozwalają na przekazanie dodatkowych informacji o wyświetlaniu treści tworzyć zaawansowane usługi ułatwień dostępu.

Tryb czytania dotykiem

Użytkownicy niedowidzący mogą teraz poznawać ekran, dotykając i przeciągając palcem po ekranu, aby usłyszeć opisy treści. Ponieważ tryb poznawania dotykiem działa jak wirtualny kursor, umożliwia czytnikom ekranu identyfikowanie tekstu opisowego w taki sam sposób, jak gdy użytkownik porusza się za pomocą pada kierunkowego lub kulki – odczytując podane informacje przez użytkowników android:contentDescription i setContentDescription() po symulowanym „najechaniu” . A więc, pamiętaj o konieczności wprowadzenia tekstu opisowego dla widoków w swojej aplikacji, zwłaszcza ImageButton, EditText, ImageView i inne widżety, które mogą nie zawierać opisowych tekstu.

Ułatwienia dostępu w widokach

Aby ulepszyć informacje dostępne dla usług ułatwień dostępu, takich jak czytniki ekranu, możesz: zaimplementować nowe metody wywołania zwrotnego dla zdarzeń ułatwień dostępu w niestandardowych komponentach View.

Należy pamiętać, że sposób działania metody sendAccessibilityEvent() zmienił się na Androidzie. 4,0 Tak jak w poprzedniej wersji Androida, gdy użytkownik włączy usługi ułatwień dostępu na urządzeniu i wystąpi zdarzenie wejściowe, takie jak kliknięcie lub najechanie kursorem, odpowiedni widok zostanie powiadomiony z wywołaniem sendAccessibilityEvent() Wcześniej funkcja wdrożenie implementacji sendAccessibilityEvent() sprawiłoby, zainicjowanie zadania AccessibilityEvent i wysłanie go do AccessibilityManager. Nowy sposób działania wymaga dodatkowego wywołania zwrotnego które pozwalają widokowi i jego elementom nadrzędnym na dodawanie do zdarzenia dodatkowych informacji kontekstowych:

  1. Po wywołaniu metody sendAccessibilityEvent() i sendAccessibilityEventUnchecked() opóźniają się do: onInitializeAccessibilityEvent().

    Niestandardowe implementacje interfejsu View mogą chcieć zaimplementować onInitializeAccessibilityEvent(), aby należy dołączyć dodatkowe informacje o ułatwieniach dostępu do obiektu AccessibilityEvent, ale należy również wywołać funkcję podaj domyślne informacje, takie jak standardowy opis treści, indeks elementu i inne. Nie należy jednak dodawać w tym wywołaniu żadnej dodatkowej treści tekstowej, ponieważ co dalej.

  2. Po zainicjowaniu, jeśli zdarzenie należy do kilku typów, które powinny być wypełnione tekstem informacje, do widoku danych otrzyma wywołanie dispatchPopulateAccessibilityEvent(), które przekierowuje do onPopulateAccessibilityEvent() oddzwanianie.

    Niestandardowe implementacje interfejsu View powinny zwykle implementować tag onPopulateAccessibilityEvent(), aby zapewnić dodatkowe zawartość tekstową w funkcji AccessibilityEvent, jeśli brakuje tekstu android:contentDescription lub niewystarczające. Aby dodać więcej opisu do sekcji AccessibilityEvent, zadzwoń pod numer getText().add().

  3. Na tym etapie View przekazuje zdarzenie wyżej w hierarchii widoku, wywołując requestSendAccessibilityEvent() w: w widoku rodzica. Każdy widok rodzica może uzupełnić informacje o ułatwieniach dostępu, dodaję AccessibilityRecord, aż do ostatecznie dociera do widoku głównego, który wysyła zdarzenie do AccessibilityManager z sendAccessibilityEvent().

Oprócz nowych metod, które są przydatne przy rozszerzaniu klasy View, możesz też przechwytywać te wywołania zwrotne zdarzeń w dowolnym obiekcie View, rozszerzając AccessibilityDelegate i ustawiając ją w widoku za pomocą setAccessibilityDelegate() Gdy to zrobisz, każda metoda ułatwień dostępu w widoku odroczy wywołanie do odpowiedniej metody w przedstawiciel. Na przykład jeśli widok odbiera wywołanie funkcji onPopulateAccessibilityEvent(), przekazuje je do w tabeli View.AccessibilityDelegate. Wszystkie metody nieobsługiwane przez jest zwracany do widoku danych w celu wyświetlenia domyślnego. Umożliwia to zastąpienie tylko wartości metod niezbędnych dla danego widoku bez rozszerzania klasy View.

Jeśli chcesz zachować zgodność z Androidem w wersjach starszych niż 4.0, a jednocześnie obsługiwać nowych interfejsów API ułatwień dostępu, możesz to zrobić dzięki najnowszej wersji obsługi ułatwień dostępu v4 Library (w pakiecie zgodności, r4) za pomocą zestawu klas narzędzi, które udostępniają nowe interfejsy API ułatwień dostępu w zgodności wstecznej. projektu.

Usługi ułatwień dostępu

Jeśli opracowujesz usługę ułatwień dostępu, informacje o różnych zdarzeniach ułatwień dostępu została znacznie rozszerzona, aby zapewnić użytkownikom bardziej zaawansowane informacje zwrotne w zakresie ułatwień dostępu. W zdarzenia są generowane na podstawie struktury widoku, dzięki czemu zapewniają więcej informacji co umożliwia usługom ułatwień dostępu przemierzanie hierarchii widoków w celu uzyskiwania dodatkowych informacji o widokach w szczególnych przypadkach.

Jeśli tworzysz usługę ułatwień dostępu (taką jak czytnik ekranu), masz dostęp dodatkowe informacje o treści i hierarchie widoków, wykonując następującą procedurę:

  1. Po otrzymaniu AccessibilityEvent z aplikacji: wywołanie AccessibilityEvent.getRecord() w celu pobrania konkretnego AccessibilityRecord (do żądania może być przypisanych kilka rekordów ).
  2. Z poziomu AccessibilityEvent lub pojedynczego elementu AccessibilityRecord możesz wywołać getSource(), aby pobrać obiekt AccessibilityNodeInfo.

    AccessibilityNodeInfo reprezentuje jeden węzeł zawartości okna w formacie, który pozwala zapytania o informacje o ułatwieniach dostępu do węzła. Obiekt AccessibilityNodeInfo zwrócony z metody AccessibilityEvent opisuje źródło zdarzenia, a źródło z AccessibilityRecord opisuje poprzednik zdarzenia źródła.

  3. Dzięki AccessibilityNodeInfo możesz wyszukiwać informacje o nim, wywołaj getParent() lub getChild(), by przeglądać widok hierarchii, a nawet dodawać do węzła widoki podrzędne.

Aby aplikacja została opublikowana w systemie jako usługa ułatwień dostępu, musi zadeklarować plik konfiguracji XML odpowiadający AccessibilityServiceInfo. Więcej informacji o tworzeniu usługi ułatwień dostępu, informacje na temat konfiguracji XML znajdziesz w sekcjach AccessibilityService oraz SERVICE_META_DATA.

Inne interfejsy API ułatwień dostępu

Jeśli chcesz sprawdzić stan ułatwień dostępu urządzenia, możesz skorzystać z nowych interfejsów API AccessibilityManager:

Usługi sprawdzania pisowni

Nowa platforma sprawdzania pisowni umożliwia aplikacjom tworzenie modułów sprawdzania pisowni w sposób podobny do metody wprowadzania (dla IME). Aby utworzyć nowy moduł sprawdzania pisowni, musisz zaimplementować usługę, która rozciąga się SpellCheckerService i rozszerzaj zajęcia SpellCheckerService.Session, aby wyświetlać sugestie pisowni na tekście dostarczonym przez metody wywołań zwrotnych interfejsu. W metodach wywołania zwrotnego SpellCheckerService.Session musisz zwracać sugestie pisowni jako obiekty SuggestionsInfo.

Aplikacje korzystające z usługi sprawdzania pisowni muszą zadeklarować uprawnienie BIND_TEXT_SERVICE zgodnie z wymaganiami tej usługi. Usługa musi również zadeklarować filtr intencji z działaniem intencji <action android:name="android.service.textservice.SpellCheckerService" /> i powinna zawiera element <meta-data> deklarujący informacje o konfiguracji pisowni sprawdzania.

Zobacz przykład aplikację Usługa sprawdzania pisowni oraz przykład Aplikacja kliencka do sprawdzania pisowni, np. kod.

Mechanizmy zamiany tekstu na mowę

Interfejsy API zamiany tekstu na mowę na Androidzie zostały znacząco rozszerzone, aby aplikacje mogły opracowanie niestandardowych mechanizmów przetwarzania tekstu na mowę jest łatwiejsze, natomiast aplikacje, które korzystają z mechanizmu zamiany tekstu na mowę, kilka nowych interfejsów API do wyboru silnika.

Korzystanie z mechanizmów zamiany tekstu na mowę

W poprzednich wersjach Androida można było użyć klasy TextToSpeech przetwarzania tekstu na mowę za pomocą mechanizmu zamiany tekstu na mowę udostępnianego przez system lub Twoją wyszukiwarkę za pomocą setEngineByPackageName(). W Androidzie 4.0 metoda setEngineByPackageName() została wycofane. Teraz możesz wskazać wyszukiwarkę, która ma być używana z nowym konstruktorem TextToSpeech, który akceptuje nazwę pakietu mechanizmu zamiany tekstu na mowę.

Możesz też wysyłać zapytania do dostępnych mechanizmów przetwarzania tekstu na mowę za pomocą narzędzia getEngines(). Ta metoda zwraca listę obiektów TextToSpeech.EngineInfo, które zawierają metadane, takie jak ikonę, etykietę i nazwę pakietu.

Budowanie silników zamiany tekstu na mowę

Wcześniej wyszukiwarki niestandardowe wymagały tworzenia silnika przy użyciu nieudokumentowanego nagłówka natywnego . Android 4.0 udostępnia kompletny zestaw interfejsów API platformy do tworzenia silników zamiany tekstu na mowę.

Podstawowa konfiguracja wymaga implementacji usługi TextToSpeechService, która odpowiada na intencję INTENT_ACTION_TTS_SERVICE. główna praca związana z mechanizmem zamiany tekstu na mowę odbywa się podczas wywołania zwrotnego onSynthesizeText() w usłudze który obejmuje TextToSpeechService. System stosuje tę metodę 2. obiekty:

  • SynthesisRequest: zawiera różne dane, w tym tekst do syntetyzować, język, szybkość mowy i ton głosu.
  • SynthesisCallback: to jest interfejs, za pomocą którego mechanizm zamiany tekstu na mowę dostarcza wygenerowane dane głosowe jako strumieniowy dźwięk. Najpierw wyszukiwarka musi wywołać metodę start(), by wskazać, że jest gotowa do wyświetlenia. włącz dźwięk, a potem zadzwoń pod numer audioAvailable(), przekazywanie jej danych audio w buforze bajtów. Gdy silnik przekaże cały dźwięk przez bufor, wywołaj done().

Teraz, gdy platforma obsługuje rzeczywisty interfejs API do tworzenia mechanizmów zamiany tekstu na mowę, obsługa kodu natywnego została usunięta. Poszukaj posta na blogu na temat warstwy zgodności które można wykorzystać do konwersji starego mechanizmu zamiany tekstu na mowę do nowego środowiska.

Przykładowy mechanizm zamiany tekstu na mowę z wykorzystaniem nowych interfejsów API znajdziesz w przykładowej aplikacji Text to Speech Engine.

Wykorzystanie sieci

Android 4.0 zapewnia użytkownikom dokładny wgląd w ilość danych sieciowych zużywanych przez ich aplikacje. Aplikacja Ustawienia udostępnia opcje, które pozwalają użytkownikom zarządzać limitami transmisji danych w sieci nawet wyłączyć użycie danych w tle dla poszczególnych aplikacji. Aby uniknąć wyłączenia dostępu aplikacji do danych w tle, należy opracować strategie wykorzystywania tych danych i dostosować wykorzystanie zasobów do wybranego typu połączenia.

Jeśli aplikacja wykonuje wiele transakcji sieciowych, należy podać ustawienia użytkownika, które pozwalają użytkownikom kontrolować sposób, w jaki aplikacja korzysta z danych (np. jak często synchronizuje dane, przesyłać/pobierać tylko przez Wi-Fi, czy używać transmisji danych w roamingu itp. Przy tych dostępne dla nich ustawienia, istnieje mniejsze prawdopodobieństwo, że użytkownicy zablokują aplikacji dostęp do danych, zbliżają się do swoich limitów, ponieważ mogą zamiast tego dokładnie kontrolować ilość danych wykorzystywanych przez aplikację. Jeśli określisz aktywność związaną z preferencjami z tymi ustawieniami, musisz uwzględnić ją w pliku manifestu zadeklaruj filtr intencji na potrzeby tabeli ACTION_MANAGE_NETWORK_USAGE działania. Na przykład:

<activity android:name="DataPreferences" android:label="@string/title_preferences">
    <intent-filter>
       <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
       <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

Ten filtr intencji wskazuje systemowi, że jest to aktywność kontrolująca wykorzystanie transmisji danych przez aplikację. Gdy użytkownik sprawdza, ile danych aplikacja wykorzystuje Ustawienia, opcja „Wyświetl ustawienia aplikacji” dostępny jest przycisk, który uruchamia pozwala określić, ile danych zużywa aplikacja.

Strzeż się, że getBackgroundDataSetting() wycofane i zawsze zwracają wartość „prawda” – zamiast tego użyj getActiveNetworkInfo(). Zanim spróbujesz z dowolną siecią transakcji, należy zawsze wywoływać getActiveNetworkInfo() aby uzyskać parametr NetworkInfo, który reprezentuje bieżącą sieć, i zapytać isConnected(), aby sprawdzić, czy urządzenie połączenia. Następnie możesz sprawdzić inne właściwości połączenia, takie jak to, czy urządzenie w roamingu lub przez Wi-Fi.

Enterprise

Android 4.0 rozszerza możliwości aplikacji dla firm o następujące funkcje.

Usługi VPN

Nowa funkcja VpnService umożliwia aplikacjom tworzenie własnych sieci VPN (wirtualnych) sieć prywatna), działająca jako Service. Usługa VPN tworzy interfejs dla sieć wirtualna z własnymi adresami i regułami routingu oraz wszystkie odczyty i zapisy deskryptor pliku.

Aby utworzyć usługę VPN, użyj opcji VpnService.Builder. Pozwala ona określić adres sieciowy, serwer DNS, trasę sieciową i inne ustawienia. Po zakończeniu możesz określić, przez wywołanie establish(), które zwraca ParcelFileDescriptor.

Usługa VPN może przechwytywać pakiety, co ma wpływ na bezpieczeństwo. Dlatego, jeśli zaimplementuje VpnService, wtedy Twoja usługa musi wymagać BIND_VPN_SERVICE, aby było możliwe powiązanie z nią tylko przez system (tylko system otrzyma to uprawnienie – aplikacje nie mogą o niego prosić). Aby potem używać usługi VPN, użytkownicy muszą włączyć ją ręcznie w ustawieniach systemu.

Zasady dotyczące urządzeń

Aplikacje, które zarządzają ograniczeniami dotyczącymi urządzeń, mogą teraz wyłączyć kamerę za pomocą właściwości setCameraDisabled() i właściwości USES_POLICY_DISABLE_CAMERA (stosując ją za pomocą elementu <disable-camera /> w pliku konfiguracji zasad).

Zarządzanie certyfikatami

Nowa klasa KeyChain udostępnia interfejsy API, które umożliwiają importowanie i dostęp certyfikatów w magazynie kluczy systemu. Certyfikaty upraszczają instalację certyfikatów (do weryfikacji tożsamości użytkownika) i certyfikatów urzędu certyfikacji (w celu zweryfikowanie tożsamości serwera). Aplikacje, takie jak przeglądarki czy klienty poczty e-mail, mogą uzyskiwać dostęp do zainstalowanych certyfikatów do uwierzytelniania użytkowników na serwerach. Zobacz KeyChain dokumentacji.

Czujniki urządzenia

W Androidzie 4.0 dodaliśmy dwa nowe typy czujników:

  • TYPE_AMBIENT_TEMPERATURE: czujnik temperatury, który dostarcza temperatura otoczenia (w pomieszczeniu) w stopniach Celsjusza.
  • TYPE_RELATIVE_HUMIDITY: czujnik wilgotności, względna wilgotność otoczenia (w pomieszczeniu) w procentach.

Jeśli urządzenie ma czujniki TYPE_AMBIENT_TEMPERATURE i TYPE_RELATIVE_HUMIDITY, możesz ich używać do obliczania punktu rosy i wilgotność bezwzględną.

Poprzedni czujnik temperatury, TYPE_TEMPERATURE, został wycofane. Należy użyć czujnika TYPE_AMBIENT_TEMPERATURE .

Dodatkowo 3 czujniki syntetyczne Androida zostały znacznie ulepszone, więc opóźnienia i płynniejsze odtwarzanie. Czujniki to m.in. czujnik grawitacji (TYPE_GRAVITY), czujnik wektora obrotu (TYPE_ROTATION_VECTOR) i czujnik przyspieszenia liniowego (TYPE_LINEAR_ACCELERATION). Ulepszone czujniki wykorzystują żyroskop czujnika, aby poprawić jakość sygnału. Dzięki temu czujniki pojawiają się tylko w urządzeniach z żyroskopem.

Pasek działań

ActionBar obsługuje teraz kilka nowych sposobów działania. Większość System płynnie zarządza rozmiarem i konfiguracją paska działań, gdy działa on na na mniejszych ekranach, aby zapewnić optymalną wygodę użytkowników korzystających z urządzeń o dowolnych rozmiarach. Przykład: gdy ekran jest wąski (np. gdy telefon jest w orientacji pionowej), Karty nawigacyjne są wyświetlane na „skumulowanym pasku”, który znajduje się bezpośrednio pod głównym paskiem działań. Dostępne opcje włączyć „podzielony pasek działań”, Wszystkie działania są umieszczane na osobnym pasku u dołu gdy ekran jest wąski.

Podziel pasek działań

Jeśli pasek działań zawiera kilka działań, nie wszystkie z nich będą się mieścić na pasku działań do wąskiego ekranu, dzięki czemu system umieszcza ich więcej w rozszerzonym menu. Jednak Android 4.0 pozwala włączyć „podzielony pasek działań”, aby na ekranie pojawiło się więcej działań na osobnym pasku u dołu ekranu. Aby włączyć podzielony pasek działań, dodaj android:uiOptions z "splitActionBarWhenNarrow" do <application>. lub poszczególne tagi <activity> w pliku manifestu. Po włączeniu tej opcji system doda dodatkowy pasek u dołu okna we wszystkich działaniach. na pasku działań).

Jeśli chcesz korzystać z kart nawigacyjnych udostępnianych przez interfejsy API ActionBar.Tab, ale nie potrzebujesz głównego paska działań u góry (chcesz, by tylko karty były widoczne u góry), i włącz podzielony pasek działań w sposób opisany powyżej, a także wywołaj setDisplayShowHomeEnabled(false), aby wyłączyć ikonę aplikacji na pasku działań. Nie ma już nic więcej na głównym pasku działań, zniknie – zostaną jedynie karty nawigacyjne u góry i działania na do dołu ekranu.

Style paska działań

Jeśli chcesz zastosować własny styl do paska działań, możesz użyć nowych właściwości stylu backgroundStacked i backgroundSplit, aby zastosować tło do paska skumulowanego i podzielonego. Możesz także ustawić te style na w środowisku wykonawczym z setStackedBackgroundDrawable() i setSplitBackgroundDrawable().

Dostawca działania

Nowa klasa ActionProvider umożliwia utworzenie specjalistycznego modułu obsługi Działania. Dostawca działań może zdefiniować widok działań, domyślne zachowanie czynności oraz menu podrzędne dla każdego działania, z którym jest ono powiązane. Jeśli chcesz utworzyć działanie, które zawiera dynamicznych zachowań (takich jak zmienne widoki działań, domyślne działanie czy menu podrzędne) i rozszerzanie elementu ActionProvider jest dobrym rozwiązaniem, gdy chcesz utworzyć komponent wielokrotnego użytku. obsługi różnych przekształceń elementów działań we fragmencie lub aktywności.

Na przykład ShareActionProvider jest rozszerzeniem ActionProvider, które umożliwia „udostępnianie” z paska działań. Zamiast użycia tradycyjnego działania, które wywołuje intencję ACTION_SEND, możesz użyj tego dostawcy działań, aby przedstawić widok działań z listą aplikacji, które obsługują intencję ACTION_SEND. Gdy użytkownik wybierze aplikację, której chce używać dla działania ShareActionProvider pamięta ten wybór i poda go w widoku działań, aby mieć szybszy dostęp do funkcji udostępniania danej aplikacji.

Aby zadeklarować dostawcę działania dla elementu działania, dołącz android:actionProviderClass w elemencie <item> w menu opcji aktywności, wraz z nazwą klasy działania jako wartość. Na przykład:

<item android:id="@+id/menu_share"
      android:title="Share"
      android:showAsAction="ifRoom"
      android:actionProviderClass="android.widget.ShareActionProvider" />

W grupie onCreateOptionsMenu() Twojej aktywności wywołanie zwrotne, pobrać instancję dostawcy działania z elementu menu i ustawić wartość intencja:

Kotlin

override fun onCreateOptionsMenu(menu: Menu): Boolean {
    menuInflater.inflate(R.menu.options, menu)
    val shareActionProvider = menu.findItem(R.id.menu_share)?.actionProvider as? ShareActionProvider
    // Set the share intent of the share action provider.
    shareActionProvider?.setShareIntent(createShareIntent())
    ...
    return super.onCreateOptionsMenu(menu)
}

Java

public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.options, menu);
    ShareActionProvider shareActionProvider =
          (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider();
    // Set the share intent of the share action provider.
    shareActionProvider.setShareIntent(createShareIntent());
    ...
    return super.onCreateOptionsMenu(menu);
}

Przykład użycia właściwości ShareActionProvider znajdziesz w sekcji ActionBarShareActionProviderActivity w ApiDemos.

Zwijane widoki akcji

Działania zapewniające widok działań mogą się teraz przełączać między stanem widoku działań tradycyjnego stanu działania. Wcześniej obsługiwane były tylko usługi SearchView zwijania w widoku działania. Teraz możesz też dodać widok przełączać się między stanem rozwiniętym (widoczny jest widok czynności) i zwiniętym (element działania to widoczne).

Aby zadeklarować, że działanie zawierające widok działania można zwijać, w pliku XML menu atrybutu android:showAsAction elementu <item> w menu należy umieścić flagę “collapseActionView".

Aby otrzymywać wywołania zwrotne, gdy widok działania przełącza się między rozwiniętym a zwiniętym, zarejestruj instancji MenuItem.OnActionExpandListener z odpowiednim MenuItem, wywołując funkcję setOnActionExpandListener(). Zwykle należy to zrobić podczas wywołania zwrotnego onCreateOptionsMenu().

Aby sterować zwijanym widokiem akcji, możesz wywołać funkcje collapseActionView() i expandActionView() na odpowiednie MenuItem.

Tworząc niestandardowy widok działań, możesz też zaimplementować nowy interfejs CollapsibleActionView, aby otrzymywać wywołania zwrotne po rozwinięciu widoku zwinięto.

Inne interfejsy API do paska działań

  • setHomeButtonEnabled() umożliwia określenie od tego, czy ikona/logo pełni funkcję przycisku do przechodzenia do strony głównej, czy też przechodzenia do góry. (przekaż wartość „true”, aby deweloper działał jako przycisk).
  • setIcon() i setLogo() pozwalają zdefiniować ikonę lub logo na pasku działań w czasie działania.
  • Fragment.setMenuVisibility() umożliwia włączenie lub wyłączyć widoczność elementów menu opcji zadeklarowanych przez fragment. Jest to przydatne, jeśli został dodany do aktywności, ale nie jest widoczny, dlatego elementy menu powinny być ukryte.
  • FragmentManager.invalidateOptionsMenu() umożliwia unieważnienie menu opcji działań na różnych stanach cyklu życia fragmentu w których metoda równoważna z Activity może być niedostępna.

Interfejs użytkownika i widoki

Android 4.0 wprowadza różne nowe widoki i inne komponenty interfejsu.

Układ siatki

GridLayout to nowa grupa widoków, która umieszcza widoki dziecięce w prostokątnym kształcie siatkę. W przeciwieństwie do TableLayout GridLayout opiera się na płaskiej wartości i nie korzysta z widoków pośrednich, takich jak wiersze tabel, do określania struktury. Zamiast tego elementy podrzędne określają, które wiersze i kolumny mają się zajmować (komórki mogą obejmować większą liczbę wierszy). wiersze lub kolumny) i domyślnie są układane kolejno w wierszach i kolumnach siatki. Orientacja GridLayout określa, czy kolejne elementy podrzędne są może być domyślnie ułożony w orientacji poziomej lub pionowej. Odstęp między elementami podrzędnymi można określić za pomocą funkcji wystąpień nowego widoku Space lub przez ustawienie odpowiednich parametrów marży. na dzieci.

Zobacz ApiDemos w przypadku próbek korzystających z metody GridLayout.

Widok tekstury

TextureView to nowy widok, który umożliwia wyświetlanie strumienia treści, jako film lub scenę OpenGL. Chociaż jest podobny do SurfaceView, widok TextureView jest wyjątkowy pod tym względem, że działa jak zwykły widok, a nie tworzy osobnego okna, dzięki czemu możesz go traktować jak każdy inny obiekt View. Przykład: możesz zastosować przekształcenia, animować je za pomocą ViewPropertyAnimator lub dostosować jego przezroczystość za pomocą setAlpha().

Pamiętaj, że TextureView działa tylko w oknie z akceleracją sprzętową.

Więcej informacji znajdziesz w dokumentacji TextureView.

Przełącz widżet

Nowy widżet Switch to przełącznik z dwoma stanami, który użytkownicy mogą przeciągnąć z boku lub z boku (albo po prostu dotknij), aby przełączać się między dwoma stanami.

Aby określić tekst, możesz użyć atrybutów android:textOn i android:textOff aby był widoczny na przełączniku, gdy jest włączony lub wyłączony. Atrybut android:text również umożliwia umieszczenie etykiety obok przełącznika.

Przykład zastosowania przełączników znajdziesz w pliku układu switches.xml. i odpowiednich przełączników .

W Androidzie 3.0 wprowadzono PopupMenu, aby tworzyć krótkie menu kontekstowe, w określonym punkcie zakotwiczenia (zwykle w punkcie wybranego elementu). Android 4.0 rozszerzony PopupMenu z kilkoma przydatnymi funkcjami:

  • Teraz możesz łatwo zawyżać zawartość wyskakującego menu z zasobu menu XML za pomocą parametru inflate(), przekazując do niego identyfikator zasobu menu.
  • Możesz też utworzyć PopupMenu.OnDismissListener, który otrzyma oddzwanianie po zamknięciu menu.

Ustawienia

Nowa klasa abstrakcyjna TwoStatePreference jest podstawą preferencji z opcją wyboru dwóch stanów. Nowa aplikacja SwitchPreference jest rozszerzeniem aplikacji TwoStatePreference, które udostępnia widżet Switch w w widoku preferencji, aby umożliwić użytkownikom włączanie i wyłączanie ustawienia bez konieczności otwierania dodatkowych ekranu lub okna dialogowego ustawień. Na przykład aplikacja Ustawienia używa SwitchPreference do obsługi ustawień Wi-Fi i Bluetooth.

Motywy systemowe

Domyślny motyw dla wszystkich aplikacji kierowanych na Androida 4.0 (poprzez ustawienie targetSdkVersion lub minSdkVersion do “14" lub wyższa) jest teraz „domyślne urządzenie” motyw: Theme.DeviceDefault. Może to być ciemny motyw Holo lub inny ciemny motyw zdefiniowany przez konkretne urządzenie.

Rodzina motywów Theme.Holo na pewno się nie zmieni z jednego urządzenia na drugie, gdy masz tę samą wersję Androida. Jeśli wyraźnie zastosuj do swoich aktywności dowolny z Theme.Holo motywów, możesz Możesz mieć pewność, że motywy nie będą zmieniać charakteru na różnych urządzeniach w tym samym wersji platformy.

Jeśli chcesz, aby aplikacja pasowała do ogólnego motywu urządzenia (np. gdy różni dostawcy OEM (określenie różnych motywów domyślnych dla systemu), musisz wyraźnie zastosować motywy z rodziny Theme.DeviceDefault.

Przycisk menu opcji

Począwszy od Androida 4.0 można zauważyć, że telefony nie wymagają już przycisku Menu sprzętowego. Nie musisz się tym jednak przejmować, jeśli w Twojej aplikacji dostępne jest menu opcji i wymaga ona pojawienia się Przycisk menu. Aby istniejące aplikacje nadal działały zgodnie z oczekiwaniami, system udostępnia przycisk menu w aplikacjach zaprojektowanych na starsze wersje Androida.

Aby zadbać o jak największą wygodę użytkowników, nowe i zaktualizowane aplikacje powinny zamiast tego używać interfejsu ActionBar do uzyskiwania dostępu do pozycji menu, a targetSdkVersion ustaw na "14", aby korzystać z najnowszych domyślnych działań platformy.

Elementy sterujące widocznością interfejsu systemowego

Od początków Androida system zarządzał komponentem interfejsu o nazwie stan który znajduje się u góry telefonu i przekazuje informacje np. o operatorze sygnału, godziny, powiadomień itd. W Androidzie 3.0 dodaliśmy pasek systemowy na tablety urządzeń, które znajdują się u dołu ekranu i służą do sterowania nawigacją w systemie (Dom, wstecz itd.), a także interfejs do elementów dostępnych tradycyjnie przez pasek stanu. W Android 4.0 to nowy typ interfejsu systemu nazywany paskiem nawigacyjnym. Ty użytkownik może uznać pasek nawigacyjny za dostrojoną wersję paska systemowego, telefony – zawiera elementy sterujące nawigacją. w przypadku urządzeń, które nie mają swoich odpowiedników sprzętowych do nawigacji w systemie, ale pomijają interfejs powiadomień i elementy sterujące na pasku systemu. W związku z tym urządzenie nawigacyjne ma również pasek stanu u góry.

Obecnie możesz ukryć pasek stanu na telefonach za pomocą flagi FLAG_FULLSCREEN. W Androidzie 4.0 interfejsy API kontrolujące Widoczność paska systemowego została zaktualizowana, aby lepiej odzwierciedlić działanie paska systemowego i pasek nawigacyjny:

  • Flaga SYSTEM_UI_FLAG_LOW_PROFILE zastępuje flagę STATUS_BAR_HIDDEN. Po ustawieniu flaga włącza „niski profil” trybu paska systemowego na pasku nawigacyjnym. Przyciski nawigacyjne są przyciemnione, a inne elementy paska systemowego również są ukryte. Włączam Przydaje się to do tworzenia bardziej wciągających gier, które nie rozpraszają nawigacji w systemie. przyciskami.
  • Flaga SYSTEM_UI_FLAG_VISIBLE zastępuje flagę STATUS_BAR_VISIBLE i wyświetla pasek systemowy lub pasek nawigacyjny.
  • SYSTEM_UI_FLAG_HIDE_NAVIGATION to nowa flaga, która wysyła żądanie pasek nawigacyjny jest całkowicie ukryty. Pamiętaj, że działa to tylko w przypadku paska nawigacyjnego. w niektórych telefonach (nie ukrywa pasek systemowy na tabletach). Nawigacja gdy tylko system otrzyma dane wejściowe użytkownika, ponownie będzie je wyświetlać. Dlatego ten tryb jest przydatny głównie do odtwarzania filmów i w innych przypadkach, gdy potrzebny jest cały ekran, ale nie jest wymagane.

Możesz ustawić każdą z tych flag na pasku systemu i pasku nawigacyjnego, wywołując funkcję setSystemUiVisibility() w dowolnym widoku aktywności. menedżer okien łączy (LUB łącznie) wszystkie flagi ze wszystkich widoków w oknie i zastosować je w interfejsie systemu, o ile tylko okno zawiera fokus do wprowadzania danych. Gdy okno straci możliwość wprowadzania danych (użytkownik opuści aplikację lub pojawi się okno) flagi przestaną działać. Podobnie, jeśli usuniesz te widoki z hierarchii widoków, ich flagi przestaną być stosowane.

Aby zsynchronizować inne zdarzenia w swojej aktywności ze zmianami widoczności w interfejsie systemu (na na przykład ukryj pasek działań lub inne elementy interfejsu, gdy interfejs systemu jest ukrywany), zarejestruj View.OnSystemUiVisibilityChangeListener, aby otrzymać powiadomienie, gdy widoczność paska systemowego lub paska nawigacyjnego.

Zobacz OverscanActivity, która prezentuje różne opcje interfejsu systemu.

Struktura danych wejściowych

W Androidzie 4.0 dodaliśmy obsługę zdarzeń najechania kursorem oraz nowych zdarzeń związanych z rysikiem i przyciskiem myszy.

Zdarzenia po najechaniu

Klasa View obsługuje teraz funkcję „najechanie” Zdarzenia, które zapewniają dostęp do bardziej rozbudowanych interakcji za pomocą urządzeń wskazujących (np. myszy lub innych urządzeń, których obsługa kursor).

Aby otrzymywać zdarzenia najechania kursorem w widoku, zaimplementuj View.OnHoverListener oraz zarejestrować ją w setOnHoverListener(). Po najechaniu kursorem w tym widoku danych, detektor odbiera wywołanie metody onHover(), przy czym wartość View, która odebrano zdarzenie oraz MotionEvent opisujący typ zdarzenia najechania kursorem jakie miały miejsce. Zdarzeniem najechania kursorem może być jedno z tych zdarzeń:

Element View.OnHoverListener powinien zwracać wartość „prawda” z parametru onHover(), jeśli obsługuje zdarzenie najechania kursorem. Jeśli detektor zwraca wartość false (fałsz), zdarzenie najechania kursorem zostanie jak zwykle wysłane do widoku nadrzędnego.

Jeśli aplikacja korzysta z przycisków lub innych widżetów, które zmieniają swój wygląd w zależności od w bieżącym stanie możesz używać atrybutu android:state_hovered w stanie listy stanów, które można narysować, wyświetla inne tło, które można rysować po najechaniu kursorem na widok.

Demonstracja nowych zdarzeń najechania kursorem znajdziesz w sekcji Najechanie w ApiDemos

Zdarzenia rysika i przycisku myszy

Android udostępnia teraz interfejsy API do odbierania danych wejściowych z urządzenia wejściowego rysika, np. digitizera urządzeniu peryferyjnego tabletu lub ekranie dotykowym obsługującym rysik.

Pisanie rysikiem działa podobnie jak wprowadzanie tekstu za pomocą dotyku lub myszy. Gdy rysik ma kontakt z digitizerem aplikacje odbierają zdarzenia dotyku w taki sam sposób, jak gdyby dotykały palcem dotknij wyświetlacza. Gdy rysik znajdzie się nad cyfrowym panelem, aplikacje będą otrzymywać najechanie kursorem w taki sam sposób, jak gdyby wskaźnik myszy był przesuwany po ekranie, gdy nie było żadnych przycisków. jest wciśnięty.

Aplikacja potrafi odróżnić dane wejściowe użytkownika, np. palca, myszy, rysika i gumki, wysyłając zapytanie „typ narzędzia” powiązane z każdym wskaźnikiem w elemencie MotionEvent używającym getToolType(). Obecnie zdefiniowane typy narzędzi to: TOOL_TYPE_UNKNOWN, TOOL_TYPE_FINGER, TOOL_TYPE_MOUSE, TOOL_TYPE_STYLUS, i TOOL_TYPE_ERASER. Gdy wysyłasz zapytanie do typu narzędzia, może wybrać różne sposoby obsługi wprowadzania rysikiem – od palca lub myszy.

Aplikacja może też wysyłać zapytania o przycisk myszy lub rysika, wysyłając zapytanie województwo” MotionEvent za pomocą funkcji getButtonState(). Obecnie zdefiniowane stany przycisku to: BUTTON_PRIMARY, BUTTON_SECONDARY, BUTTON_TERTIARY, BUTTON_BACK i BUTTON_FORWARD. Dla wygody przyciski myszy (przód i tył) są automatycznie mapowane na klucze KEYCODE_BACK i KEYCODE_FORWARD. Twoja aplikacja może obsługiwać te klucze nawigacja wstecz i do przodu za pomocą przycisków myszy.

Oprócz precyzyjnego pomiaru pozycji i siły nacisku na kontakt może też wprowadzać niektóre dane rysikiem urządzenia informują też o odległości między końcówką rysika a digitizerem, kąt nachylenia rysika oraz kąta orientacji rysika. Twoja aplikacja może wysyłać zapytania do tych informacji za pomocą interfejsu getAxisValue() z kodami osi AXIS_DISTANCE, AXIS_TILT i AXIS_ORIENTATION.

Typy narzędzi, stany przycisków i nowe kody osi znajdziesz w sekcji TouchPaint w ApiDemos.

Właściwości

Nowa klasa Property pozwala szybko, wydajnie i łatwo określić w dowolnym obiekcie, która umożliwia obiektom wywołującym ogólne ustawianie/pobieranie wartości w obiektach docelowych. Dodatkowo umożliwia przesyłanie odwołań do pól/metod i pozwala kodowi ustawiać/pobierać wartości właściwości, nie znając dodatkowo pól i metod.

Jeśli na przykład chcesz ustawić wartość pola bar w obiekcie foo, musisz poprzednio wykonaj tę czynność:

Kotlin

foo.bar = value

Java

foo.bar = value;

Jeśli chcesz wywołać metodę ustawiającą dla bazowego pola prywatnego bar, musisz wcześniej wykonaj następujące czynności:

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

Jeśli jednak chcesz ominąć wystąpienie foo i ustawić inny kod, bar, tak naprawdę nie można tego zrobić w wersjach wcześniejszych niż 4.0.

Za pomocą klasy Property możesz zadeklarować Property obiekt BAR w klasie Foo, dzięki czemu możesz ustawić pole w instancji foo zajęcia Foo podobne do:

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

Klasa View korzysta teraz z klasy Property do: umożliwiają skonfigurowanie różnych pól, np. właściwości przekształcenia, które zostały dodane w Androidzie 3.0 (ROTATION, ROTATION_X, TRANSLATION_X itp.).

Klasa ObjectAnimator używa także Property , dzięki czemu możesz utworzyć ObjectAnimator z użyciem Property, który jest szybszy, wydajniejszy i bezpieczniejszy niż typ oparty na ciągach znaków. jak ważna jest pokora.

Akceleracja sprzętowa

Począwszy od Androida 4.0 akceleracja sprzętowa dla wszystkich okien jest domyślnie włączona, jeśli aplikacja ustawiła targetSdkVersion lub minSdkVersion do “14" lub więcej. Przyspieszenie sprzętowe zwykle zapewnia płynniejsze i bardziej płynne animacje. oraz zwiększać skuteczność i reagowanie na interakcje użytkowników.

W razie potrzeby możesz ręcznie wyłączyć akcelerację sprzętową w hardwareAccelerated dla poszczególnych elementów <activity> lub <application> . Możesz też wyłączyć akcelerację sprzętową w poszczególnych widokach, wywołując funkcję setLayerType(LAYER_TYPE_SOFTWARE).

Więcej informacji o akceleracji sprzętowej, w tym listę nieobsługiwanych rysowania można znaleźć w sekcji Sprzęt Acceleration.

Zmiany JNI

W poprzednich wersjach Androida odwołania do lokalnych plików JNI nie były pośrednimi nickami. Używany Android i bezpośrednich wskaźników. Nie stanowiło to problemu, o ile śmietnik nie przenosił obiektów, działa, ponieważ umożliwia pisanie błędów w kodzie. W Androidzie 4.0 system używa teraz pośrednich odwołań, które pozwalają wykryć te błędy.

Szczegóły dotyczące lokalnych odwołań JNI są opisane w sekcji „Źródła lokalne i globalne” w sekcji JNI Tip. W Androidzie 4.0 Ulepszyliśmy CheckJNI, aby wykrywały te błędy. Więcej informacji na temat nadchodzącego posta znajdziesz na blogu dla deweloperów aplikacji na Androida o typowych błędach dotyczących odwołań JNI i sposobach ich naprawy.

Ta zmiana w implementacji JNI ma wpływ tylko na aplikacje kierowane na Androida 4.0, jeśli ustawisz jedną z tych targetSdkVersion lub minSdkVersion na “14" lub wyższy. Jeśli ustawisz te atrybuty na jakąkolwiek niższą wartość, lokalne odwołania JNI zachowują się tak samo jak w poprzednich wersjach.

WebKit

  • Aktualizacja WebKit do wersji 534.30
  • obsługa czcionek indyjskich (dewanagari, bengalski i tamilski, w tym złożona obsługa znaków); potrzebnych do łączenia glifów) w usłudze WebView i we wbudowanej przeglądarce
  • Obsługa czcionek etiopskich, gruzińskich i ormiańskich w języku WebView oraz wbudowana przeglądarka
  • Obsługa domen WebDriver ułatwia testowanie aplikacji, które używają WebView

Przeglądarka w systemie Android

Do aplikacji Przeglądarka dodawane są następujące funkcje obsługujące aplikacje internetowe:

Uprawnienia

Oto nowe uprawnienia:

Funkcje urządzenia

Oto nowe funkcje urządzenia:

  • FEATURE_WIFI_DIRECT: deklaruje, że aplikacja zastosowania Wi-Fi na potrzeby komunikacji peer-to-peer.

Szczegółowy widok wszystkich zmian interfejsu API w Androidzie 4.0 (poziom API 14) zapoznaj się z raportem na temat różnic w interfejsach API.

Poprzednie interfejsy API

Oprócz wszystkich funkcji wymienionych powyżej Android 4.0 w naturalny sposób obsługuje wszystkie interfejsy API z poprzednich wersji. Ponieważ platforma Android 3.x jest dostępna tylko na urządzenia z dużym ekranem, głównie z myślą o telefonach, możesz nie wiedzieć o wszystkich interfejsach API dodanych do Androida w tych najnowszych wydaniach.

Oto niektóre z najważniejszych interfejsów API, które mogły Ci umknąć, i są już dostępne również w telefonach:

Android 3.0
  • Fragment: komponent platformy, który pozwala rozdzielić różne elementów aktywności w niezależnych modułach, które definiują własny interfejs użytkownika i cykl życia. Zobacz Fragmenty – przewodnik dla programistów.
  • ActionBar: zastępuje tradycyjny pasek tytułu u góry w oknie aktywności. Zawiera logo aplikacji w lewym rogu i zapewnia nowy elementów menu. Zobacz Pasek działań – przewodnik dla programistów.
  • Loader: komponent platformy, który umożliwia obsługę asynchronicznej ładowania danych w połączeniu z komponentami interfejsu w celu dynamicznego wczytywania danych bez blokowania w wątku głównym. Zobacz Przewodnik dla programistów dotyczący modułów ładujących.
  • Schowek systemowy: aplikacje mogą kopiować i wklejać dane (oprócz zwykłego tekstu) do i z ze schowka systemowego. Może to być zwykły tekst, identyfikator URI lub intencja. Zobacz Przewodnik dla programistów Kopiuj i wklej.
  • Przeciągnij i upuść: zestaw interfejsów API wbudowanych w platformę widoku, która umożliwia przeciąganie i upuszczanie operacji. Zobacz Przewodnik dla programistów funkcji Przeciągnij i upuść.
  • Zupełnie nowa elastyczna platforma animacji umożliwia animowanie dowolnych właściwości w dowolnym (View, Drawable, Fragment, Object itp.) i zdefiniować aspekty animacji, takie jak takich jak czas trwania, interpolacja czy powtórzenie. Nowa platforma sprawia, że animacje na Androida prostsza niż kiedykolwiek. Zobacz Programista animacji właściwości Google.
  • Mechanizm grafiki i ComputeScript RenderScript: umożliwia tworzenie filmów 3D o wysokiej wydajności. renderowania grafiki i interfejsu Compute API na natywnym poziomie, w języku C (standard C99), zapewnia typ wydajności, jakiego oczekujesz od środowiska natywnego, a jednocześnie pozostały przenośny na różnych CPU i GPU. Zobacz Programista RenderScript Google.
  • Akceleracja sprzętowa grafiki 2D: teraz można włączyć mechanizm renderowania OpenGL na aplikacji przez ustawienie {android:hardwareAccelerated="true"} w elemencie <application> w elemencie manifestu elementu lub poszczególnych elementów <activity> . Te wyniki płynniejsze animacje, płynniejsze przewijanie oraz ogólnie lepsze działanie i lepsze reakcje interakcji.

    Uwaga: jeśli ustawisz minSdkVersion lub targetSdkVersion aplikacji na "14" lub nowszego, akceleracja sprzętowa jest domyślnie włączona.

  • I to wiele, wiele innych. Zapoznaj się z platformą Android 3.0 .
Android 3.1
  • Interfejsy USB API: nowe, zaawansowane interfejsy API do integracji podłączonych urządzeń peryferyjnych Aplikacje na Androida. Interfejsy API są oparte na stosie USB i usługach, które z wbudowaną platformą, w tym obsługę interakcji z hostem USB i urządzeniem. Zobacz Przewodnik dla programistów dotyczący hostów i akcesoriów USB.
  • Interfejsy API MTP/PTP: aplikacje mogą wchodzić w bezpośrednią interakcję z podłączonymi kamerami i innymi urządzeniami PTP urządzenia, aby otrzymywać powiadomienia o podłączeniu i usunięciu urządzeń oraz zarządzać plikami i miejscem na dane oraz przesyłać pliki i metadane na te urządzenia i z nich. Interfejs MTP API implementuje PTP (Picture Transfer Protocol) specyfikacji MTP (Media Transfer Protocol). Zobacz Dokumentacja android.mtp.
  • Interfejsy API RTP: Android udostępnia interfejs API wbudowanemu stosowi RTP (Real-time Transport Protocol). za pomocą których aplikacje mogą zarządzać strumieniowym lub interaktywnym strumieniem danych na żądanie. Przede wszystkim aplikacje obsługujące VOIP, funkcje push, aby rozmawiać, rozmowy wideo i strumieniowanie dźwięku mogą zainicjować za pomocą interfejsu API i wysyłają lub odbierają strumienie danych w dowolnej dostępnej sieci. Zobacz dokumentację android.net.rtp.
  • Obsługa joysticków i innych typów ruchu.
  • Zobacz Platformę Androida 3.1. uwagi na temat wielu innych nowych interfejsów API.
Android 3.2
  • Nowe ekrany obsługują interfejsy API, które dają Ci większą kontrolę nad działaniem aplikacji wyświetlane na ekranach o różnych rozmiarach. Rozszerza istniejący model obsługi ekranu o możliwość precyzyjnego kierowania reklam na określone zakresy rozmiarów ekranu według wymiarów, mierzonych niezależne od gęstości jednostki pikseli (np. 600 dp lub 720 dp), a nie ich uogólnione wartości rozmiarów ekranu (np. duży lub bardzo duży). Jest to ważne na przykład, aby pomóc Ci rozróżnić 5-calowe i 7" które są tradycyjnie zgrupowane jako „large” ekrany. Przeczytaj post na blogu Nowe narzędzia do zarządzania rozmiarami ekranu.
  • Nowe stałe dla <uses-feature> na określ wymagania dotyczące orientacji ekranu w orientacji poziomej lub pionowej.
  • „Rozmiar ekranu” urządzenia. konfiguracja zmienia się teraz podczas orientacji ekranu . Jeśli aplikacja jest kierowana na interfejs API na poziomie 13 lub wyższym, musisz obsługiwać "screenSize" zmień konfigurację, jeśli chcesz obsługiwać też zmianę konfiguracji "orientation". Zobacz android:configChanges, aby dowiedzieć się więcej.
  • Zobacz Platformę Androida 3.2. uwagi na temat innych nowych interfejsów API.

Poziom API

Interfejs API Androida 4.0 ma przypisaną liczbę całkowitą. 14 – który jest przechowywany w samym systemie. Identyfikator ten, nazywany „poziomem interfejsu API”, pozwala systemowi poprawnie określić, czy jest zgodna z systemem.

Aby korzystać w aplikacji z interfejsów API wprowadzonych w Androidzie 4.0, musisz skompilować aplikacji na platformie Android obsługującej interfejs API poziomu 14 lub wyższe. W zależności od potrzeb konieczne może być też dodanie atrybutu android:minSdkVersion="14" do zbioru danych <uses-sdk>. .

Więcej informacji znajdziesz w artykule Co to jest interfejs API Poziom?