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.

Deweloperzy mogą pobrać platformę Android 4.0 jako komponent pakietu 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 aplikacji na Androida w wersji 4.0, użyj Menedżera pakietu SDK Androida, aby pobrać platformę do swojego pakietu SDK.

Omówienie interfejsu API

W sekcjach poniżej znajdziesz techniczny przegląd nowych interfejsów API w Androidzie 4.0.

Interfejsy API mediów społecznościowych w usługach dostawców kontaktów

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, który reprezentuje właściciela urządzenia zgodnie z definicją w tabeli ContactsContract.Profile. Aplikacje społecznościowe, które przechowują tożsamość użytkownika, mogą przyczynić się do danych profilu użytkownika, tworząc nowy wpis ContactsContract.RawContacts w sekcji 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 z 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. Większość aplikacji nie powinna jednak odczytywać profilu użytkownika, nawet jeśli dodaje do niego dane. Odczytywanie profilu użytkownika jest uprawnieniem poufnym i możesz oczekiwać, że sceptycznie wobec aplikacji, które o to proszą.

Zamiar zaproszenia

Działanie o intencji INVITE_CONTACT pozwala aplikacji wywołać działanie, które wskazuje, że użytkownik chce dodać kontakt do sieci społecznościowej. Aplikacja, która otrzymuje aplikację, używa jej do zaproszenia określonego kontaktu do tej sieci społecznościowej. Większość aplikacji stanie się stroną docelową tej operacji. 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 na liście „Dodaj połączenie”, musi zawierać adapter synchronizacji, który synchronizuje informacje o kontaktach z Twojej sieci społecznościowej. Następnie musisz wskazać systemowi, że Twoja aplikacja reaguje na intencję INVITE_CONTACT, dodając atrybut inviteContactActivity do pliku konfiguracji synchronizacji aplikacji, wraz z pełną nazwą aktywności, którą system powinien uruchomić podczas wysyłania 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). Możesz dodać duże zdjęcie do kontaktu, umieszczając je w zwykłej kolumnie PHOTO wiersza danych. System przetworzy je następnie na odpowiednią miniaturę i wyświetli rekordy zdjęć.

Opinie na temat wykorzystania

Nowe interfejsy API ContactsContract.DataUsageFeedback umożliwiają śledzenie, jak często użytkownik korzysta z określonych metod kontaktowania się z ludźmi, np. jak często używa poszczególnych numerów telefonów lub adresów e-mail. Te informacje pomagają poprawić ranking każdego sposobu kontaktu powiązanego z każdą osobą i przedstawiać lepsze sugestie dotyczące kontaktu z każdą osobą.

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 informacje dotyczące konkretnego kalendarza. Każdy wiersz w tej tabeli zawiera informacje o poszczególnych kalendarzach, takie jak nazwa, kolor czy informacje o synchronizacji.
  • Tabela CalendarContract.Events zawiera informacje o danym zdarzeniu. Każdy wiersz tej tabeli zawiera informacje o pojedynczym zdarzeniu, takie jak tytuł, lokalizacja, czas rozpoczęcia, czas zakończenia itd. Wydarzenie może wystąpić raz lub wielokrotnie. Uczestnicy, przypomnienia i rozszerzone właściwości są przechowywane w osobnych tabelach i używają wartości _ID wydarzenia, aby je z nim powiązać.
  • Tabela CalendarContract.Instances zawiera godziny rozpoczęcia i zakończenia dla okresu wystąpienia zdarzenia. Każdy wiersz w tej tabeli odpowiada pojedynczemu wystąpieniu. W przypadku jednorazowych zdarzeń każde wystąpienie jest powiązane z jednym zdarzeniem. 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 reprezentuje pojedynczego 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 alarmowi dotyczącemu zdarzenia. Wypadek może mieć 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ą określane w liczbie minut przed zaplanowanym zdarzeniem i określają metodę alarmu, np. alert, e-mail lub SMS.
  • Tabela CalendarContract.ExtendedProperties zawiera nieprzezroczyste pola danych używane przez adapter synchronizacji. Usługodawca nie podejmuje żadnych działań dotyczących elementów w tej tabeli, z wyjątkiem ich usuwania, gdy zostaną usunięte powiązane zdarzenia.

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

Zamiar 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ąć działanie w aplikacji Kalendarz, które 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 urządzenia, aby wyświetlać wszystkie wiadomości głosowe użytkownika w jednym widoku. Użytkownik może mieć na przykład kilka źródeł poczty głosowej, takich jak poczta głosowa od dostawcy usług telefonicznych oraz poczta głosowa od VoIP lub innych alternatywnych usług głosowych. Te aplikacje mogą używać interfejsów API dostawcy poczty głosowej, aby dodawać wiadomości głosowe na urządzeniu. 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).

Obecnie interfejsy API nie zezwalają aplikacjom innych firm na odczytywanie wszystkich wiadomości głosowych z systemu. Dlatego tylko aplikacje innych firm, które mają wiadomości głosowe do przekazania użytkownikowi, powinny korzystać z interfejsów API wiadomości głosowych.

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ład aplikacji dostawcy poczty głosowej znajdziesz w artykule Demo aplikacji dostawcy poczty głosowej.

Multimedia

Android 4.0 dodaje kilka nowych interfejsów API dla aplikacji, które współpracują z multimediami, takimi jak zdjęcia, filmy i muzyka.

Efekty multimedialne

Nowa platforma efektów multimedialnych umożliwia stosowanie różnych efektów wizualnych do obrazów i obrazów. filmy. Efekty obrazu umożliwiają na przykład łatwe usuwanie efektu czerwonych oczu, konwertowanie obrazu na skalę szarości, dostosowywanie jasności, dostosowywanie nasycenia, obracanie obrazu, stosowanie efektu rybiego oka i wiele innych funkcji. do uzyskania maksymalnej wydajności system wykonuje wszystkie przetwarzanie efektów w GPU.

Aby zapewnić maksymalną wydajność, efekty są stosowane bezpośrednio do tekstur OpenGL, więc aplikacja musi mieć prawidłowy kontekst OpenGL, zanim będzie mogła korzystać z interfejsów API efektów. Tekstury, do których stosujesz efekty, mogą pochodzić z map bitowych, filmów, a nawet z 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 mipmap

Obiekt Effect definiuje pojedynczy efekt multimedialny, który możesz zastosować do ramki obrazu. Podstawowy proces tworzenia 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 do tekstury, wywołaj funkcję apply() w obiekcie Effect i przekaż teksturę wejściową, jej szerokość i wysokość oraz teksturę wyjściową. Tekstura wejściowa musi być powiązana z obrazem tekstury GL_TEXTURE_2D (zwykle odbywa się to przez wywołanie funkcji glTexImage2D()). Możesz podać większą liczbę poziomów mipmap. Jeśli tekstura wyjściowa nie jest powiązana z obrazem tekstury, zostanie automatycznie powiązana przez efekt jako GL_TEXTURE_2D i z jednym poziomem mipmap (0), który będzie miał taki sam rozmiar jak wejście.

Wszystkie efekty wymienione w sekcji EffectFactory są 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

Nowa funkcja RemoteControlClient umożliwia odtwarzaczom włączanie elementów sterujących odtwarzaniem z dalszych urządzeń, takich jak ekran blokady urządzenia. Odtwarzacze multimediów mogą też udostępniać informacje o obecnie odtwarzanych treściach, które są wyświetlane na pilocie, np. informacje o utworze 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. Intencją musi być też deklaracja w aplikacji wyraźnego komponentu BroadcastReceiver, który obsługuje zdarzenie ACTION_MEDIA_BUTTON.

Aby określić, które dane wejściowe sterowania multimediami obsługuje odtwarzacz, musisz wywołać funkcję setTransportControlFlags() w obiekcie RemoteControlClient, przekazując zestaw flag FLAG_KEY_MEDIA_*, takich 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ą metody getParcelableExtra(Intent.EXTRA_KEY_EVENT).

Aby wyświetlić informacje o odtwarzanych multimediach na pilocie, wywołaj funkcję editMetaData() i dodaj metadane do zwróconego obiektu RemoteControlClient.MetadataEditor. Możesz przesłać bitmapę z grafiką multimedialną, informacje liczbowe, takie jak upływający czas, oraz informacje tekstowe, takie jak tytuł utworu. Dla: informacje o dostępnych kluczach są widoczne w flagach METADATA_KEY_* w narzędziu MediaMetadataRetriever.

Przykładową implementację znajdziesz w sekcji Losowy odtwarzacz muzyki, który zapewnia logikę kompatybilności, która umożliwia 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 Surface, który będzie działać jako odbiornik 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

Więcej informacji znajdziesz w artykule Obsługiwane formaty multimediów.

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ć urządzenie Camera.FaceDetectionListener, wywołując metodę setFaceDetectionListener(). Następnie możesz uruchomić kamerę i rozpocząć wykrywanie twarzy, wywołując startFaceDetection().

Gdy system wykryje co najmniej 1 twarz w scenie aparatu, wywołuje funkcję onFaceDetection() w Twojej implementacji Camera.FaceDetectionListener, przekazując tablicę obiektów Camera.Face.

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 wskazująca, jak pewny jest system, że obiekt to ludzka twarz.
  • niepowtarzalny identyfikator, dzięki któremu można śledzić wiele 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 aparat używa do ustawiania ostrości, pomiaru balansu bieli i automatycznego naświetlania. 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ępująca instancja klasy Camera.Area definiuje granice obszaru za pomocą Rect oraz wagę obszaru (będącą liczbą całkowitą) reprezentującą poziom znaczenia tego obszaru w stosunku do innych rozpatrywanych obszarów.

Zanim ustawisz obszar ostrości lub obszar pomiaru, musisz najpierw wywołać odpowiednio funkcję 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 będą się stale zmieniać w miarę, jak zmienia się scena.

Ciągły autofokus podczas robienia zdjęć

Możesz teraz włączyć ciągłe autofokus podczas robienia zdjęć. Aby włączyć CAF w aplikacji aparatu, prześlij FOCUS_MODE_CONTINUOUS_PICTURE do setFocusMode(). Gdy wszystko będzie gotowe, zadzwoń pod numer 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 nacisnąć takePicture(), aby zapisać zdjęcie bez przerywania nagrywania. Zanim to zrobisz, Wywołaj isVideoSnapshotSupported(), aby upewnić się, że sprzęt który ją obsługuje.
  • Możesz teraz zablokować automatyczne naświetlanie i wyważenie bieli za pomocą opcji setAutoExposureLock() i setAutoWhiteBalanceLock(), aby zapobiec zmianie tych właściwości.
  • Podczas podglądu aparatu możesz teraz zadzwonić do setDisplayOrientation(). Wcześniej można było to zrobić tylko przed rozpoczęciem podglądu, ale teraz orientację można zmienić w dowolnym momencie.

Intencje przesyłania z kamery

  • Camera.ACTION_NEW_PICTURE: oznacza, że użytkownik zrobił nowe zdjęcie. Wbudowana aplikacja Aparat uruchamia tę transmisję po zrobieniu zdjęcia, a aplikacje aparatu innych firm powinny również uruchamiać tę transmisję 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 w wiadomości NDEF mogą zawierać dowolne dane, które chcesz udostępnić na różnych urządzeniach. Na przykład aplikacja Kontakty 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 za pomocą funkcji Android Beam, musisz utworzyć NdefMessage zawierający informacje, które chcesz udostępnić, gdy Twoja aktywność jest 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:

    W każdej chwili możesz zadzwonić pod numer setNdefPushMessage(), aby ustawić wiadomość, którą chcesz wysłać. Możesz na przykład wywołać tę metodę i przekazać jej obiekt NdefMessage w ramach metody onCreate() aktywności. Gdy funkcja Android Beam jest aktywowana na innym urządzeniu, gdy aktywność jest na pierwszym planie, system wysyła NdefMessage na to urządzenie.

  • 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 takim przypadku, gdy Android Beam jest aktywowany na innym urządzeniu, gdy Twoja aktywność jest na pierwszym planie, system wywołuje createNdefMessage(), aby pobrać NdefMessage, który chcesz wysłać. Dzięki temu możesz zdefiniować NdefMessage tak, aby wysyłać je tylko po uruchomieniu Android Beam, jeśli treść wiadomości może się zmieniać w trakcie trwania aktywności.

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.

Na urządzeniu odbierającym system wysyła komunikaty NDEF Push w sposób podobny do zwykłych tagów 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 aktywności, na którą chcesz reagować, możesz zadeklarować filtry intencji dla adresów URL lub typów MIME, które są istotne dla Twojej aplikacji. Więcej informacji o rozsyłaniu tagów znajdziesz w przewodniku dla programistów dotyczącym 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.

Aby mieć pewność, że Twoja aplikacja obsłuży przychodzącą wiadomość NDEF, nawet jeśli inne aplikacje filtrują według tej samej akcji intencji, musisz też przekazać „rekord aplikacji na Androida” z wartością NdefMessage. 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 ma obecnie zainstalowanej aplikacji, system używa rekordu aplikacji na Androida do uruchomienia Google Play i przekierowania użytkownika do aplikacji w celu jej zainstalowania.

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 udostępnia zestaw interfejsów API Wi-Fi P2P, które umożliwiają wykrywanie innych urządzeń i łączenia się z nimi, jeśli tylko jedno z nich obsługuje Wi-Fi P2P. Następnie można komunikować się z nimi przez szybkie połączenie na znacznie większe odległości niż w przypadku połączenia Bluetooth.

Nowy pakiet (android.net.wifi.p2p) zawiera wszystkie interfejsy API do obsługi połączeń peer-to-peer połączenia z Wi-Fi. Główną klasą, z którą musisz pracować, jest WifiP2pManager, którą możesz uzyskać, wywołując funkcję getSystemService(WIFI_P2P_SERVICE). WifiP2pManager zawiera 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ń 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 obiektem serwera proxy profilu, musisz wywołać funkcję getProfileProxy() z typem profilu BluetoothProfile.ServiceListener i HEALTH.

Po uzyskaniu obiektu proxy profilu zdrowotnego (BluetoothHealth) połączenie z parowanymi urządzeniami medycznymi i komunikacja z nimi odbywają się za pomocą tych nowych klas Bluetooth:

  • BluetoothHealthCallback: musisz rozszerzyć tę klasę i zaimplementować metody wywołania, aby otrzymywać informacje o zmianach stanu rejestracji aplikacji i stanu 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 używaniu profilu Bluetooth dotyczącego zdrowia znajdziesz w dokumentacji BluetoothHealth.

Ułatwienia dostępu

Android 4.0 ułatwia korzystanie z urządzenia osobom niedowidzącym dzięki nowemu trybowi eksplorowania dotykiem oraz rozszerzonym interfejsom API, które umożliwiają wyświetlanie dodatkowych informacji o treśćach lub tworzenie zaawansowanych usług ułatwień.

Tryb czytania dotykiem

Użytkownicy z wadą wzroku mogą teraz dotykać i przeciągać palcem po ekranie, aby usłyszeć głosowe opisy treści. Tryb eksploracji za pomocą dotyku działa jak wirtualny kursor, dzięki czemu czytniki ekranu mogą identyfikować tekst opisowy w taki sam sposób jak w przypadku korzystania z klawiatury kierunkowej lub sterowania kulkowego – czytają informacje udostępniane przez android:contentDescription i setContentDescription() po symulowanym zdarzeniu „najechania”. 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 zwiększyć ilość informacji dostępnych dla usług ułatwień dostępu, takich jak czytniki ekranu, możesz zaimplementować w niestandardowych komponentach View nowe metody wywołania dla zdarzeń ułatwień dostępu.

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

  1. Gdy są wywoływane, metody sendAccessibilityEvent() i sendAccessibilityEventUnchecked() odsyłają do metody onInitializeAccessibilityEvent().

    W przypadku niestandardowych implementacji View warto zaimplementować onInitializeAccessibilityEvent(), aby dołączyć do AccessibilityEvent dodatkowe informacje ułatwiające dostępność. Należy też wywołać superimplementację, aby podać domyślne informacje, takie jak standardowy opis treści, indeks elementów itp. Nie należy jednak dodawać w tym wywołaniu zwrotnym dodatkowego tekstu. Zrobisz to w następnym kroku.

  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() W takim przypadku każda metoda ułatwień dostępu w widoku odkłada wywołanie do odpowiedniej metody w delegacie. Na przykład jeśli widok odbiera wywołanie funkcji onPopulateAccessibilityEvent(), przekazuje je do w tabeli View.AccessibilityDelegate. Wszystkie metody, których nie obsługuje delegat, są przekazywane z powrotem do widoku w celu zachowania domyślnego zachowania. Umożliwia to zastąpienie tylko wartości metod niezbędnych dla danego widoku bez rozszerzania klasy View.

Jeśli chcesz zachować zgodność z wersjami Androida starszymi niż 4.0, a jednocześnie obsługiwać nowe interfejsy API ułatwień dostępności, możesz to zrobić za pomocą najnowszej wersji biblioteki pomocniczej w wersji 4 (w pakiecie zgodności, r4), korzystając z zestawu klas pomocniczych, które zapewniają nowe interfejsy API ułatwień dostępności w wersji zgodnej wstecz.

Usługi ułatwień dostępu

Jeśli opracowujesz usługę ułatwień dostępu, informacje o różnych zdarzeniach związanych z ułatwieniami dostępu zostały znacznie rozszerzone, aby umożliwić użytkownikom bardziej zaawansowane informacje zwrotne. W szczególności zdarzenia są generowane na podstawie kompozycji widoku, co zapewnia lepsze informacje kontekstowe i pozwala usługom ułatwień dostępu na przechodzenie przez hierarchie widoków w celu uzyskiwania dodatkowych informacji o widoku i rozwiązywania szczególnych przypadków.

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łaj funkcję AccessibilityEvent.getRecord(), aby pobrać konkretny AccessibilityRecord (do zdarzenia może być dołączonych 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 mogła publikować się w systemie jako usługa ułatwień dostępu, musi zadeklarować plik konfiguracji XML odpowiadający wartości AccessibilityServiceInfo. Więcej informacji o tworzeniu usługi ułatwień dostępu znajdziesz w artykule AccessibilityService, a informacje o konfiguracji XML – w artykule SERVICE_META_DATA.

Inne interfejsy API ułatwień dostępu

Jeśli interesuje Cię stan ułatwień dostępu na urządzeniu, AccessibilityManager zawiera nowe interfejsy API, takie jak:

Usługi sprawdzania pisowni

Nowa platforma sprawdzania pisowni umożliwia aplikacjom tworzenie sprawdzarek pisowni w sposób podobny do platformy metody wprowadzania (w przypadku metod wprowadzania). Aby utworzyć nową funkcję sprawdzania pisowni, musisz zaimplementować usługę rozszerzającą klasę SpellCheckerService i rozszerzającą klasę SpellCheckerService.Session, aby udostępniać sugestie dotyczące pisowni na podstawie tekstu dostarczonego przez metody wywołania zwrotnego interfejsu. W metodach wywołania zwrotnego SpellCheckerService.Session musisz zwracać sugestie pisowni jako obiekty SuggestionsInfo.

Aplikacje z usługą sprawdzania pisowni muszą deklarować uprawnienie BIND_TEXT_SERVICE, jeśli jest ono wymagane przez usługę. 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żywać klasy TextToSpeech do wykonywania operacji zamiany tekstu na mowę za pomocą mechanizmu zamiany tekstu na mowę udostępnianego przez system lub do konfigurowania niestandardowego mechanizmu za pomocą klasy 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.

Tworzenie mechanizmów zamiany tekstu na mowę

Wcześniej silniki niestandardowe wymagały utworzenia za pomocą nieudokumentowanego pliku 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 silnik musi wywołać funkcję start(), aby wskazać, że jest gotowy do odtworzenia dźwięku, a potem wywołać funkcję audioAvailable(), przekazując jej dane dźwięku w buforze bajtów. Gdy silnik prześle cały dźwięk przez bufor, wywołaj funkcję 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 TTS korzystający z nowych interfejsów API znajdziesz w przykładowej aplikacji Text To Speech Engine.

Wykorzystanie sieci

Android 4.0 zapewnia użytkownikom dokładne informacje o tym, ile danych sieciowych wykorzystują 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 Twoja aplikacja wykonuje dużo transakcji sieciowych, udostępnij ustawienia, które pozwolą użytkownikom kontrolować jej nawyki dotyczące danych, np. częstotliwość synchronizowania danych, czy przesyłać/pobierać tylko przez Wi-Fi, czy używać danych w roamingu itp. Dzięki tym opcjom użytkownicy rzadziej wyłączają dostęp aplikacji do danych, gdy zbliżają się do limitów, ponieważ mogą zamiast tego dokładnie kontrolować ilość danych używanych przez aplikację. Jeśli udostępniasz aktywność preferencji z tymi ustawieniami, w deklaracji pliku manifestu musisz uwzględnić filtr intencji dla działania ACTION_MANAGE_NETWORK_USAGE. 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ść, która kontroluje użycie danych przez aplikację. Dlatego, gdy użytkownik sprawdza, ile danych zużywa Twoja aplikacja w aplikacji Ustawienia, jest dostępny przycisk „Wyświetl ustawienia aplikacji”, który uruchamia aktywność związaną z ustawieniami, dzięki której użytkownik może dostosować ilość danych zużywaną przez aplikację.

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 biznesowych o te 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.

Ponieważ usługa VPN może przechwytywać pakiety, ma to wpływ na bezpieczeństwo. Jeśli więc chcesz zaimplementować VpnService, Twoja usługa musi wymagać uprawnienia BIND_VPN_SERVICE, aby tylko system mógł się z nią powiązać (tylko systemowi przyznawane jest to uprawnienie – aplikacje nie mogą go 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 zarządzające ograniczeniami urządzenia mogą teraz wyłączyć kamerę za pomocą funkcji setCameraDisabled() i właściwości USES_POLICY_DISABLE_CAMERA (zastosowanej 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ę zarówno certyfikatów klienta (do weryfikacji tożsamości użytkownika), jak i certyfikatów urzędu certyfikacji (do weryfikacji 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 2 nowe typy czujników:

  • TYPE_AMBIENT_TEMPERATURE: czujnik temperatury, który mierzy temperaturę otoczenia (w pomieszczeniu) w stopniach Celsjusza.
  • TYPE_RELATIVE_HUMIDITY: czujnik wilgotności, który podaje wilgotność względną otoczenia (pomieszczenia) 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 syntetyczne czujniki Androida zostały znacznie ulepszone, dzięki czemu mają teraz mniejsze opóźnienie i płynniejsze dane wyjściowe. Te czujniki to czujnik grawitacji (TYPE_GRAVITY), czujnik wektora obrotu (TYPE_ROTATION_VECTOR) i czujnik przyspieszenia liniowego (TYPE_LINEAR_ACCELERATION). Ulepszone czujniki korzystają z czujnika żyroskopowego, więc pojawiają się tylko na urządzeniach z żyroskopem.

Pasek działań

ActionBar został zaktualizowany, aby obsługiwać kilka nowych zachowań. Co najważniejsze, system płynnie zarządza rozmiarem i konfiguracją paska czynności na mniejszych ekranach, aby zapewnić użytkownikom optymalne wrażenia na wszystkich rozmiarach ekranów. Jeśli ekran jest wąski (np. gdy telefon jest w orientacji pionowej), karty nawigacyjne paska akcji są wyświetlane na „pasku złożonym”, który znajduje się bezpośrednio pod głównym paskiem. 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 elementów, nie wszystkie z nich zmieszczą się na pasku na wąskim ekranie, dlatego system umieści więcej z nich w menu przepełnienia. 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ć podzieloną belkę działań, dodaj tag android:uiOptions z wartością "splitActionBarWhenNarrow" do tagu <application> lub do poszczególnych tagów <activity> w pliku manifestu. Gdy ta opcja jest włączona, system doda dodatkowy pasek na dole ekranu dla wszystkich elementów czynności, gdy ekran jest wąski (na głównym pasku czynności nie będą widoczne żadne elementy czynności).

Jeśli chcesz używać kart nawigacyjnych udostępnianych przez interfejsy API ActionBar.Tab, ale nie potrzebujesz głównego paska czynności u góry (chcesz, aby u góry były widoczne tylko karty), włącz podzielony pasek czynności w sposób opisany powyżej, a potem wywołaj setDisplayShowHomeEnabled(false), aby wyłączyć ikonę aplikacji na pasku czynności. Gdy na głównym pasku działań nie ma nic, znika on – pozostają tylko karty nawigacyjne u góry i elementy działania u dołu ekranu.

Style paska działań

Jeśli chcesz zastosować niestandardowy styl do paska akcji, możesz użyć nowych właściwości stylu backgroundStacked i backgroundSplit, aby odpowiednio zastosować tło drawable lub kolor do nałożonego paska i paska 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łania, domyślne zachowanie działania oraz menu podrzędne dla każdego elementu działania, z którym jest powiązany. 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 to rozszerzenie ActionProvider, które umożliwia działanie „udostępnij” z poziomu paska działań. Zamiast tradycyjnego elementu działania wywołującego intencję ACTION_SEND możesz użyć tego dostawcy działań, aby wyświetlić widok działania z listą aplikacji obsługujących 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łań dla elementu działania, dodaj atrybut android:actionProviderClass do elementu <item> w menu opcji aktywności, podając jako wartość nazwę klasy dostawcy działań. Na przykład:

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

W metodie wywołania onCreateOptionsMenu() aktywności pobierz instancję dostawcy działań z elementu menu i ustaw intencję:

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ą teraz przełączać się 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 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 element czynności zawierający widok czynności ma być zwijany, dodaj flagę “collapseActionView" w atrybucie android:showAsAction elementu <item> w pliku XML menu.

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ć widokiem składanego działania, możesz wywołać metody collapseActionView() i expandActionView() na odpowiednim obiekcie 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 rolę 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 fragment został dodany do aktywności, ale nie jest widoczny, więc elementy menu powinny być ukryte.
  • FragmentManager.invalidateOptionsMenu()umożliwia unieważnienie menu opcji aktywności w różnych stanach cyklu życia fragmentu, w których użycie równoważnej metody z Activity może być niedostępne.

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 podrzędne w prostokątnym GridLayout. 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 elementy podrzędne są domyślnie układane w poziomie czy w pionie. Odstępy między elementami podrzędnymi można określić, używając instancji widoku Space lub ustawiając odpowiednie parametry marginesu dla elementów podrzędnych.

Przykłady użycia interfejsu GridLayout znajdziesz w artykule ApiDemos.

Widok tekstury

TextureView to nowy widok, który umożliwia wyświetlanie strumienia treści, jako film lub scenę OpenGL. Chociaż obiekt TextureView jest podobny do obiektu SurfaceView, ma tę zaletę, że zachowuje się jak zwykły widok, a nie tworzy osobnego okna. Możesz więc traktować go jak dowolny inny obiekt View. Możesz na przykład stosować przekształcenia, animować obiekt za pomocą ViewPropertyAnimator lub dostosowywać 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.

Widżet przełącznika

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.

Za pomocą atrybutów android:textOn i android:textOff możesz określić tekst, który ma się wyświetlać na przełączniku w przypadku włączenia i wyłączenia. Atrybut android:text umożliwia też umieszczenie etykiety obok przełącznika.

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

Android 3.0 wprowadził PopupMenu do tworzenia krótkich menu kontekstowych, które pojawiają się w określonym punkcie kotwicznym (zwykle w miejscu wybranego elementu). Android 4.0 rozszerzony PopupMenu z kilkoma przydatnymi funkcjami:

  • Teraz możesz łatwo sztucznie zwiększać 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 funkcja SwitchPreference to rozszerzenie funkcji TwoStatePreference, która udostępnia widżet Switch w widoku preferencji, aby umożliwić użytkownikom włączanie i wyłączanie ustawień bez konieczności otwierania dodatkowego ekranu lub okna dialogowego preferencji. Na przykład aplikacja Ustawienia używa SwitchPreference do ustawień Wi-Fi i Bluetooth.

Motywy systemowe

Domyślny motyw dla wszystkich aplikacji kierowanych na Androida 4.0 (za pomocą ustawienia targetSdkVersion lub minSdkVersion na “14" lub wyższy) to teraz motyw „domyślny dla urządzenia”: 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 w swoich działaniach zastosujesz jeden z motywów Theme.Holo, możesz mieć pewność, że nie zmieni on swojego charakteru na różnych urządzeniach w ramach tej samej wersji platformy.

Jeśli chcesz, aby Twoja aplikacja pasowała do ogólnego motywu urządzenia (np. gdy różni producenci OEM udostępniają różne domyślne motywy systemu), musisz wyraźnie zastosować motywy z grupy Theme.DeviceDefault.

Przycisk menu opcji

Od wersji 4.0 Androida telefony nie wymagają już przycisku menu. Nie musisz się jednak tym przejmować, jeśli Twoja obecna aplikacja zawiera menu opcji i oczekuje, że będzie dostępny przycisk menu. Aby zapewnić, że istniejące aplikacje będą działać zgodnie z oczekiwaniami, system udostępnia przycisk menu na ekranie w przypadku aplikacji zaprojektowanych na potrzeby starszych wersji Androida.

Aby zadbać o 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 użytkownika

Od początku istnienia Androida system zarządzał komponentem interfejsu użytkownika zwanym paskiem stanu, który znajduje się u góry ekranu telefonu i przekazuje informacje takie jak sygnał sieci komórkowej, godzina czy powiadomienia. Android 3.0 wprowadził pasek systemowy na tabletach, który znajduje się u dołu ekranu i zawiera elementy sterujące systemem (Strona główna, Wstecz itp.), a także interfejs elementów tradycyjnie wyświetlanych na pasku stanu. W Androidzie 4.0 system udostępnia nowy typ interfejsu użytkownika, tzw. pasek nawigacyjny. Pasek nawigacji to zmodyfikowana wersja paska systemu przeznaczonego dla telefonów komórkowych. Zawiera elementy sterujące nawigacją na urządzeniach, które nie mają odpowiedników sprzętowych do nawigacji w systemie, ale nie zawiera elementów sterujących interfejsem powiadomień ani ustawień paska systemu. Dlatego na urządzeniu, które ma pasek nawigacyjny, u góry znajduje się też pasek stanu.

Obecnie możesz ukryć pasek stanu na telefonach za pomocą flagi FLAG_FULLSCREEN. W Androidzie 4.0 interfejsy API, które kontrolują widoczność paska systemowego, zostały zaktualizowane, aby lepiej odzwierciedlały działanie zarówno paska systemowego, jak i paska nawigacyjnego:

  • 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 przygasną, a inne elementy na pasku systemowym również znikną. 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 nowy parametr, który powoduje całkowite ukrycie paska nawigacyjnego. Pamiętaj, że ta funkcja działa tylko w przypadku paska nawigacyjnego używanego przez niektóre telefony (nie ukrywa pasek systemowy na tabletach). Pasek nawigacyjny wraca do widoku, gdy tylko system otrzyma dane wejściowe od użytkownika. 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) wszystkie flagi ze wszystkich widoków w oknie oraz 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

Android 4.0 obsługuje zdarzenia związane z kursorem i nowe zdarzenia związane z przyciskami rysika i myszy.

Zdarzenia związane z najechaniem

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(). Gdy w widoku wystąpi zdarzenie hover, detektor otrzyma wywołanie onHover(), które zawiera View, który otrzymało zdarzenie, oraz MotionEvent opisujący typ zdarzenia hover. Zdarzeniem najechania kursorem może być jedno z tych zdarzeń:

Funkcja View.OnHoverListener powinna zwracać wartość true z funkcji onHover(), jeśli obsługuje zdarzenie najechania kursorem. Jeśli listener zwróci wartość false, zdarzenie hover zostanie wysłane do widoku nadrzędnego jak zwykle.

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.

Demonstrację nowych zdarzeń związanych z najeżdżaniem kursorem znajdziesz w klasie Hover w ramach pakietu ApiDemos.

Zdarzenia rysika i przycisku myszy

Android udostępnia teraz interfejsy API do odbierania danych z urządzenia wejściowego z rysikiem, takiego jak urządzenie peryferyjne dotykowe lub ekran dotykowy obsługujący 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 użytkownika przyciski wstecz i dalej są automatycznie mapowane na klawisze 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. Aplikacja może wysyłać zapytania o te informacje za pomocą funkcji 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. Umożliwia też przekazywanie odwołań do pól i metod oraz ustawianie i pobieranie wartości właściwości bez znajomości szczegółów dotyczących 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ę ustawiania dla prywatnego pola podrzędnego bar, wcześniej musisz wykonać te czynności:

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

Jeśli jednak chcesz przekazać instancję foo i ustawić wartość bar za pomocą innego kodu, nie ma możliwości wykonania tej czynności w wersjach Androida starszych niż 4.0.

Za pomocą klasy Property możesz zadeklarować obiekt Property BAR w klasie Foo, aby móc ustawić pole w instancji foo klasy Foo w ten sposób:

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 też 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 przyspieszenie sprzętowe wszystkich okien jest domyślnie włączone, jeśli w aplikacji ustawiono wartość targetSdkVersion lub minSdkVersion“14" lub wyższą. 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ą za pomocą atrybutu hardwareAccelerated w przypadku poszczególnych elementów <activity> lub elementu <application>. Możesz też wyłączyć akcelerację sprzętową w przypadku poszczególnych widoków, wywołując funkcję setLayerType(LAYER_TYPE_SOFTWARE).

Więcej informacji o przyspieszaniu sprzętowym, w tym o liście operacji rysowania, które nie są obsługiwane, znajdziesz w dokumentacji Przyspieszanie sprzętowe.

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 było to problemem, dopóki zbieracz śmieci nie przenosił obiektów, ale wydawało się, że działa, ponieważ umożliwiało to pisanie kodu z błędami. W Androidzie 4.0 system używa teraz odwołań pośrednich do wykrywania tych błędów.

Szczegóły dotyczące odwołań lokalnych JNI znajdziesz w artykule „Odwołania lokalne i globalne” w poradach dotyczących JNI. W Androidzie 4.0 Ulepszyliśmy CheckJNI, aby wykrywały te błędy. Na blogu dla deweloperów aplikacji na Androida wkrótce pojawi się post o częstych błędach związanych z odwołaniami do JNI oraz o sposobach ich naprawiania.

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 te atrybuty mają ustawioną niższą wartość, odwołania lokalne JNI działają tak samo jak w poprzednich wersjach.

WebKit

  • Aktualizacja WebKit do wersji 534.30
  • Obsługa czcionek indyjskich (Devanagari, bengalijskiego i tamilijskiego, w tym obsługa znaków złożonych, która jest potrzebna do łączenia glif) w WebView i wbudowanej przeglądarce
  • Obsługa czcionek etiopskich, gruzińskich i ormiańskich w WebView i wbudowanej przeglądarce
  • 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ółowe informacje o wszystkich zmianach w interfejsie API w Androidzie 4.0 (poziom interfejsu API 14) znajdziesz w raporcie z różnicami w interfejsie API.

Wcześniejsze interfejsy API

Oprócz wszystkich funkcji wymienionych powyżej Android 4.0 obsługuje też 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ą Ci umknąć, a które są teraz dostępne także na telefonach:

Android 3.0
  • Fragment: komponent platformy, który umożliwia rozdzielenie różnych elementów aktywności na niezależne moduły definiujące własny interfejs i cykl życia. Zapoznaj się z przewodnikiem dla programistów Fragmentów.
  • ActionBar: zastępuje tradycyjny pasek tytułu u góry okna aktywności. Zawiera logo aplikacji w lewym rogu i nowy interfejs dla pozycji menu. Zobacz Pasek działań – przewodnik dla programistów.
  • Loader: komponent frameworku, który umożliwia asynchroniczne wczytywanie danych w połączeniu z komponentami interfejsu użytkownika, aby wczytywać dane dynamicznie bez blokowania wątku głównego. Zapoznaj się z przewodnikiem dla programistów dotyczącym ładowarek.
  • Schowek systemowy: aplikacje mogą kopiować i wklejać dane (oprócz zwykłego tekstu) do i z ze schowka systemowego. Wycięte dane mogą mieć format zwykłego tekstu, adresu URI lub intencji. Zapoznaj się z przewodnikiem dla programistów dotyczącym kopiowania i wklejania.
  • Przeciąganie i upuszczanie: zestaw interfejsów API wbudowanych w ramy widoku, które ułatwiają operacje przeciągania i upuszczania. Zapoznaj się z przewodnikiem dla programistów dotyczącym funkcji przeciągania i upuszczania.
  • 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, takich jak czas trwania, interpolacja, powtórzenie itp. Nowa platforma sprawia, że animacje na Androida prostsza niż kiedykolwiek. Zapoznaj się z poradnikiem dla deweloperów dotyczącym animacji właściwości.
  • Renderowanie grafiki i obsługa obliczeniowa RenderScript: RenderScript zapewnia wydajne renderowanie grafiki 3D i interfejs obliczeniowy na poziomie natywnym. Programy napisane w języku C (standard C99) zapewniają wydajność oczekiwaną od natywnego środowiska, a jednocześnie są przenośne na różnych procesorach i procesorach graficznych. Zapoznaj się z przewodnikiem dla programistów dotyczącym RenderScript.
  • Grafika 2D z przyspieszeniem sprzętowym: teraz możesz włączyć w swojej aplikacji renderowanie OpenGL, ustawiając {android:hardwareAccelerated="true"} w elemencie <application> elementu pliku manifestu lub w przypadku 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 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 podzbiór PTP (Picture Transfer Protocol) w ramach specyfikacji MTP (Media Transfer Protocol). Zobacz Dokumentacja android.mtp.
  • Interfejsy RTP API: Android udostępnia interfejs API do obsługi wbudowanego pakietu RTP (protokół transportu w czasie rzeczywistym), którego aplikacje mogą używać do zarządzania strumieniowaniem danych na żądanie lub interaktywnym. W szczególności aplikacje, które zapewniają usługi VOIP, push-to-talk, konferencji i strumieniowego przesyłania dźwięku, mogą używać interfejsu API do inicjowania sesji oraz przesyłania i odbierania strumieni danych w dowolnej dostępnej sieci. Zobacz dokumentację android.net.rtp.
  • Obsługa joysticków i innych ogólnych urządzeń wejściowych reagujących na ruch.
  • 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. Interfejs API rozszerza dotychczasowy model obsługi ekranów o możliwość dokładnego kierowania reklam na określone zakresy rozmiarów ekranu według wymiarów mierzonych w pikselach niezależnych od gęstości (np. 600 dp lub 720 dp szerokości) zamiast ogólnych 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 byłyby tradycyjnie zgrupowane jako „large” ekrany. Przeczytaj wpis 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.
  • Konfiguracja „rozmiaru ekranu” urządzenia zmienia się teraz podczas zmiany 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ą. identyfikatora 14, który jest przechowywany w samym systemie. Ten identyfikator, zwany „poziomem interfejsu API”, umożliwia systemowi prawidłowe określenie, czy aplikacja jest zgodna z systemem, zanim zostanie zainstalowana.

Aby używać w swojej aplikacji interfejsów API wprowadzonych w Androidzie 4.0, musisz skompilować aplikację na platformę Androida, która obsługuje poziom interfejsu API 14 lub nowszy. W zależności od potrzeb możesz też dodać atrybut android:minSdkVersion="14" do elementu <uses-sdk>.

Więcej informacji znajdziesz w artykule Co to jest poziom dostępu API?