Interfejsy API Androida 3.1

Poziom API: 12

Dla deweloperów platforma Android 3.1 (HONEYCOMB_MR1) jest dostępna jako komponent pakietu Android SDK, który można pobrać. Platforma do pobrania zawiera bibliotekę Androida i obraz systemu, a także zestaw skórek emulatorów. Platforma do pobrania nie zawiera bibliotek zewnętrznych.

Dla programistów platforma Android 3.1 jest dostępna jako komponent pakietu Android SDK, który można pobrać. Platforma do pobrania zawiera bibliotekę Androida i obraz systemu, a także zestaw skórek emulatorów. Aby zacząć programować lub testować Androida w wersji 3.1, pobierz platformę do swojego pakietu SDK za pomocą Menedżera pakietu Android SDK.

Omówienie interfejsu API

Sekcje poniżej zawierają omówienie nowości dla deweloperów w Androidzie 3.1, w tym informacje o nowych funkcjach i zmianach w interfejsie Framework API od poprzedniej wersji.

Interfejsy API USB

Android 3.1 wprowadza nowe zaawansowane interfejsy API do integracji połączonych urządzeń peryferyjnych z aplikacjami działającymi na platformie. Interfejsy API opierają się na stosie USB (Universal Serial Bus) i wbudowanych w nią usługach. Obejmuje to obsługę interakcji z hostem USB i urządzeniami. Za pomocą interfejsów API programiści mogą tworzyć aplikacje umożliwiające wykrywanie różnych typów urządzeń połączonych przez USB, komunikowanie się z nimi i zarządzanie nimi.

Stos i interfejsy API rozróżniają 2 podstawowe typy sprzętu USB w zależności od tego, czy urządzenie z Androidem działa jako host, czy sprzęt zewnętrzny działa jako host:

  • Urządzenie USB to podłączony sprzęt, który działa jako host przez urządzenie z Androidem. Na przykład większość urządzeń wejściowych, myszy, joysticków, i wielu kamer, koncentratorów itp., to urządzenia USB.
  • Akcesorium USB to połączony sprzęt, który jest wyposażony w kontroler hosta USB, zasilający oraz zaprojektowany do komunikacji z urządzeniami z Androidem przez USB. Różne urządzenia peryferyjne można podłączyć jako akcesoria, od kontrolerów robotycznych po sprzęt muzyczny, rowery treningowe i nie tylko.

W przypadku obu typów urządzeń – urządzeń USB i akcesoriów USB – interfejsy API USB platformy obsługują wykrywanie przez komunikat o intencji po podłączeniu lub odłączeniu, a także standardowe interfejsy, punkty końcowe i tryby przesyłania (sterowanie, zbiorowe i przerwane).

Interfejsy API USB są dostępne w pakiecie android.hardware.usb. Klasa centralna to UsbManager, która udostępnia metody pomocnicze do identyfikowania urządzeń USB i akcesoriów USB oraz komunikacji z nimi. Aplikacje mogą pozyskiwać instancję UsbManager, a potem wysyłać zapytania o listę dołączonych urządzeń lub akcesoriów, a potem komunikować się z nimi i nimi zarządzać. UsbManager deklaruje również działania intencji sygnalizowane przez system, aby informować o podłączeniu lub odłączeniu urządzenia USB lub akcesoriów.

Inne klasyfikacje to m.in.:

  • UsbDevice – klasa reprezentująca sprzęt zewnętrzny podłączony jako urządzenie USB (z urządzeniem z Androidem działającym jako host).
  • UsbAccessory – reprezentuje sprzęt zewnętrzny podłączony jako host USB (urządzenie z Androidem działającym jako urządzenie USB).
  • UsbInterface i UsbEndpoint, które zapewniają dostęp do standardowych interfejsów USB i punktów końcowych urządzenia.
  • UsbDeviceConnection i UsbRequest: do wysyłania i odbierania danych oraz wiadomości sterujących do i z urządzenia USB, synchronicznie i asynchronicznie.
  • UsbConstants, który zawiera stałe do deklarowania typów punktów końcowych, klas urządzeń itd.

Pamiętaj, że chociaż stos USB jest wbudowany w platformę, faktyczna obsługa trybów hosta USB i otwartych akcesoriów na określonych urządzeniach zależy od producentów. Tryb hosta zależy w szczególności od odpowiedniego kontrolera USB w urządzeniu z Androidem.

Deweloperzy mogą też poprosić o filtrowanie w Google Play, dzięki czemu ich aplikacje nie będą dostępne dla użytkowników, których urządzenia nie obsługują odpowiedniego złącza USB. Aby poprosić o filtrowanie, dodaj do pliku manifestu aplikacji co najmniej jeden z tych elementów:

  • Jeśli aplikacja powinna być widoczna tylko dla urządzeń obsługujących tryb hosta USB (podłączanie urządzeń USB), zadeklaruj ten element:

    <uses-feature android:name="android.hardware.usb.host" android:required="true">

  • Jeśli aplikacja powinna być widoczna tylko dla urządzeń obsługujących akcesoria USB (podłączanie hostów USB), zadeklaruj ten element:

    <uses-feature android:name="android.hardware.usb.accessory" android:required="true">

Szczegółowe informacje o tworzeniu aplikacji korzystających z akcesoriów USB znajdziesz w dokumentacji dla programistów.

Przykładowe aplikacje, które korzystają z interfejsu API hosta USB, znajdziesz w artykułach ADB Test i Missile Launcher (Program uruchamiający pociski).

Interfejs API MTP/PTP

Android 3.1 udostępnia nowy interfejs API MTP, który umożliwia aplikacjom bezpośrednią interakcję z podłączonymi kamerami i innymi urządzeniami PTP. Nowy interfejs API ułatwia aplikacjom otrzymywanie powiadomień o podłączeniu i usunięciu urządzenia, zarządzanie plikami i pamięcią na tych urządzeniach oraz przenoszenie plików i metadanych do i z tych urządzeń. Interfejs MTP API implementuje podzbiór specyfikacji PTP (Picture Transfer Protocol) specyfikacji MTP (Media Transfer Protocol).

Interfejs MTP API jest dostępny w pakiecie android.mtp i udostępnia te klasy:

  • Element MtpDevice zawiera urządzenie MTP podłączone przez magistralę hosta USB. Aplikacja może utworzyć instancję obiektu tego typu, a następnie za pomocą swoich metod uzyskać informacje o urządzeniu i zapisanych na nim obiektach, a także otworzyć połączenie i przesłać dane. Oto niektóre z nich:
    • getObjectHandles() zwraca listę nicków dla wszystkich obiektów na urządzeniu, które pasują do określonego formatu i elementu nadrzędnego. Aby uzyskać informacje o obiekcie, aplikacja może przekazać nick do getObjectInfo().
    • importFile() umożliwia aplikacji kopiowanie danych obiektu do pliku w pamięci zewnętrznej. To wywołanie może blokować na dowolny czas w zależności od rozmiaru danych i szybkości urządzeń, dlatego powinno być wykonywane z wątku spearate.
    • open() umożliwia aplikacji otwieranie połączonego urządzenia MTP/PTP.
    • getThumbnail() zwraca miniaturę obiektu w postaci tablicy bajtów.
  • MtpStorageInfo zawiera informacje o jednostce pamięci masowej na urządzeniu MTP, zgodnie ze zbiorem danych StorageInfo opisanym w sekcji 5.2.2 specyfikacji MTP. Metody klasy pozwalają aplikacji na pobranie ciągu opisu jednostki pamięci masowej, ilości wolnego miejsca, maksymalnej pojemności pamięci, identyfikatora miejsca na dane oraz identyfikatora woluminu.
  • MtpDeviceInfo zawiera informacje o urządzeniu MTP odpowiadającym zbiorowi danych DeviceInfo opisanemu w sekcji 5.1.1 specyfikacji MTP. Metody w tej klasie pozwalają aplikacjom uzyskać informacje o producenta, modelu, numerze seryjnym i wersji urządzenia.
  • MtpObjectInfo zawiera informacje o obiekcie przechowywanym na urządzeniu MTP zgodnie ze zbiorem danych ObjectInfo opisanym w sekcji 5.3.1 specyfikacji MTP. Metody klasy pozwalają aplikacjom na pobieranie informacji o rozmiarze obiektu, formacie danych, typie powiązania, dacie utworzenia i miniaturze.
  • MtpConstants podaje stałe do deklarowania kodów formatów plików MTP, typu powiązania i stanu ochrony.

Obsługa nowych urządzeń wejściowych i zdarzeń ruchu

Android 3.1 rozszerza podsystem wprowadzania danych o obsługę nowych urządzeń wejściowych i nowych typów zdarzeń ruchu we wszystkich widokach i oknach. Deweloperzy mogą wykorzystać te możliwości, aby umożliwić użytkownikom korzystanie z aplikacji za pomocą myszy, kulek, joysticków, padów do gier i innych urządzeń, a także klawiatury i ekranów dotykowych.

Platforma obsługuje dwa nowe działania zdarzeń ruchu:

  • ACTION_SCROLL określa miejsce wskaźnika, w którym został przewinięty niedotykowy ruch przewijania, np. kółkiem przewijania w myszce. W obiekcie MotionEvent wartość osi AXIS_HSCROLL i AXIS_VSCROLL określa względny ruch przewijania.
  • ACTION_HOVER_MOVE informuje o bieżącej pozycji myszy, gdy nie zostały naciśnięte żadne przyciski, oraz o wszystkich punktach pośrednich od ostatniego zdarzenia HOVER_MOVE. Powiadomienia o włączeniu kursorem myszy i wyjściu nie są jeszcze obsługiwane.

Aby obsługiwać joysticki i pady do gier, klasa InputDevice zawiera nowe źródła urządzeń wejściowych:

Aby opisać zdarzenia ruchu pochodzące z tych nowych źródeł, a także z myszy i kulek, platforma definiuje teraz kody osi w MotionEvent, podobnie jak w KeyEvent. Nowe kody osi dla joysticków i kontrolerów do gier to między innymi AXIS_HAT_X, AXIS_HAT_Y, AXIS_RTRIGGER, AXIS_ORIENTATION, AXIS_THROTTLE i wiele innych. Istniejące osie MotionEvent są reprezentowane przez AXIS_X, AXIS_Y, AXIS_PRESSURE, AXIS_SIZE, AXIS_TOUCH_MAJOR, AXIS_TOUCH_MINOR, AXIS_TOOL_MAJOR, AXIS_TOOL_MINOR i AXIS_ORIENTATION.

Dodatkowo MotionEvent definiuje wiele ogólnych kodów osi, które są używane, gdy platforma nie wie, jak zmapować konkretną oś. Określone urządzenia mogą używać ogólnych kodów osi do przekazywania do aplikacji niestandardowych danych o ruchu. Pełną listę osi i ich zamierzonych interpretacji znajdziesz w dokumentacji klas MotionEvent.

Platforma udostępnia dla aplikacji zdarzenia ruchu partiami, więc pojedyncze zdarzenie może zawierać bieżącą pozycję i wiele tak zwanych ruchów historycznych. Aplikacje powinny używać metody getHistorySize(), aby uzyskać liczbę próbek historycznych, a następnie pobierać i przetwarzać wszystkie próbki historyczne w celu korzystania z metody getHistoricalAxisValue(). Później aplikacje powinny przetworzyć bieżącą próbkę za pomocą funkcji getAxisValue().

Niektóre osie można pobierać przy użyciu specjalnych metod akcesorium. Na przykład zamiast wywoływać getAxisValue(), aplikacje mogą wywoływać metodę getX(). Osie z wbudowanymi akcesorami to m.in. AXIS_X, AXIS_Y, AXIS_PRESSURE, AXIS_SIZE, AXIS_TOUCH_MAJOR, AXIS_TOUCH_MINOR, AXIS_TOOL_MAJOR, AXIS_TOOL_MINOR i AXIS_ORIENTATION.

Każde urządzenie wejściowe ma unikalny, przypisany przez system identyfikator i może też udostępniać wiele źródeł. Jeśli urządzenie dostarcza wiele źródeł, więcej niż jedno źródło może dostarczać dane osi przy użyciu tej samej osi. Na przykład zdarzenie dotyku pochodzące ze źródła dotyku używa osi X do określania pozycji ekranu, a zdarzenie joysticka pochodzące ze źródła joysticka używa osi X do określenia pozycji dźwigni. Z tego powodu ważne jest, aby aplikacje interpretowały wartości osi na podstawie źródła, z którego pochodzą. Podczas obsługi zdarzeń ruchu aplikacje powinny używać metod klasy InputDevice do określania osi obsługiwanych przez urządzenie lub źródło. W szczególności aplikacje mogą używać getMotionRanges() do wysyłania zapytań dotyczących wszystkich osi urządzenia lub wszystkich osi danego źródła urządzenia. W obu przypadkach informacje o zakresie dla osi zwróconych w obiekcie InputDevice.MotionRange określają źródło każdej wartości osi.

Ponieważ zdarzenia ruchu pochodzące z joysticka, pada do gier, myszy i kulki nie są zdarzeniami dotknięciami, platforma dodaje nową metodę wywołania zwrotnego, która będzie przekazywać je do View jako „ogólne” zdarzenia ruchu. W szczególności zgłasza zdarzenia ruchu niedotykowego w elemencie View za pomocą wywołania funkcji onGenericMotionEvent(), a nie onTouchEvent().

Platforma wysyła ogólne zdarzenia ruchu w różny sposób w zależności od klasy źródła zdarzenia. Zdarzenia SOURCE_CLASS_POINTER trafiają do elementu View pod wskaźnikiem, podobnie jak działają zdarzenia kliknięcia. Pozostali zostaną przekierowani do obecnie wybranego elementu View. Oznacza to na przykład, że aby odbierać zdarzenia joysticka, element View musi się zaznaczyć. W razie potrzeby aplikacje mogą obsługiwać te zdarzenia na poziomie aktywności lub okna, implementując w nim onGenericMotionEvent().

Przykładową aplikację, która wykorzystuje zdarzenia ruchu joysticka, znajdziesz w sekcjach GameControllerInput i GameView.

Interfejs API RTP

Android 3.1 udostępnia interfejs API we wbudowanym stosie RTP (Real-time Transport Protocol), którego aplikacje mogą używać do zarządzania interaktywnym strumieniem danych na żądanie. W szczególności aplikacje obsługujące VOIP, usługi push, rozmowy wideo i strumieniowe przesyłanie dźwięku mogą korzystać z interfejsu API, aby inicjować sesje oraz przesyłać lub odbierać strumienie danych w dowolnej dostępnej sieci.

Interfejs API RTP jest dostępny w pakiecie android.net.rtp. Obejmują one:

  • RtpStream, klasa podstawowa strumieni, które wysyłają i odbierają pakiety sieciowe z ładunkami multimediów przez RTP.
  • AudioStream, podklasa klasy RtpStream, która przenosi ładunki audio przez RTP.
  • AudioGroup – lokalne centrum audio do zarządzania głośnikiem urządzenia, mikrofonu i urządzenia AudioStream oraz ich miksowaniem.
  • AudioCodec, który zawiera zbiór kodeków zdefiniowanych przez Ciebie dla komponentu AudioStream.

Aby obsługiwać rozmowy audio i podobne zastosowania, aplikacja tworzy instancje 2 klas jako punktów końcowych strumienia:

  • AudioStream określa zdalny punkt końcowy i składa się z mapowania sieci oraz ze skonfigurowanego AudioCodec.
  • AudioGroup reprezentuje lokalny punkt końcowy dla co najmniej jednego elementu AudioStream. AudioGroup łączy wszystkie komponenty AudioStream i opcjonalnie w tym samym czasie wchodzi w interakcję z głośnikiem i mikrofonem.

Najprostsze zastosowanie obejmuje 1 zdalny punkt końcowy i lokalny punkt końcowy. W przypadku bardziej złożonych zastosowań zapoznaj się z ograniczeniami opisanymi w sekcji AudioGroup.

Aby korzystać z interfejsu RTP API, aplikacje muszą prosić użytkownika o pozwolenie, deklarując <uses-permission android:name="android.permission.INTERNET"> w plikach manifestu. Aby uzyskać dostęp do mikrofonu urządzenia, musisz też mieć uprawnienie <uses-permission android:name="android.permission.RECORD_AUDIO">.

Widżety aplikacji z możliwością zmiany rozmiaru

Począwszy od Androida 3.1 programiści mogą dostosować rozmiar widżetów ekranu głównego – w poziomie, w pionie lub na obu osiach. Użytkownik musi przytrzymać widżet, aby wyświetlić uchwyty zmiany rozmiaru, a następnie przeciągnąć uchwyty poziome lub pionowe, aby zmienić rozmiar siatki układu.

Deweloperzy mogą dostosować rozmiar dowolnego widżetu ekranu głównego, definiując atrybut resizeMode w metadanych AppWidgetProviderInfo widżetu. Wartości atrybutu resizeMode to „horizontal” (poziomo), „vertical” (pionowo) i „none” (brak). Aby zadeklarować, że widżet może zmieniać rozmiar w poziomie i w pionie, podaj wartość „horizontal|vertical”.

Oto przykład: 

<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
    android:minWidth="294dp"
    android:minHeight="72dp"
    android:updatePeriodMillis="86400000"
    android:previewImage="@drawable/preview"
    android:initialLayout="@layout/example_appwidget"
    android:configure="com.example.android.ExampleAppWidgetConfigure"
    android:resizeMode="horizontal|vertical" >
</appwidget-provider>

Więcej informacji o widżetach na ekranie głównym znajdziesz w dokumentacji widżetów aplikacji.

Struktura animacji

  • Nowa klasa ViewPropertyAnimator:
    • Nowa klasa ViewPropertyAnimator ułatwia programistom animowanie właściwości wybranych w obiektach View. Klasa automatyzuje i optymalizuje animację właściwości oraz ułatwia zarządzanie wieloma jednoczesnymi animacjami w obiekcie View.

      Korzystanie z ViewPropertyAnimator jest proste. Aby animować właściwości elementu View, wywołaj animate() w celu utworzenia obiektu ViewPropertyAnimator dla tego elementu View. Użyj metod w obiekcie ViewPropertyAnimator, aby określić właściwość do animowania i w jaki sposób ją animować. Aby na przykład zmienić kolor View na przezroczysty, wywołaj alpha(0);. Obiekt ViewPropertyAnimator obsługuje szczegóły konfigurowania bazowej klasy Animator i uruchamiania jej, a następnie renderowania animacji.

  • Kolor tła animacji
  • Pobieram animowany ułamek z: ViewAnimator
    • Nowa metoda getAnimatedFraction() pozwala uzyskać bieżący odsetek animacji (upływ czasu upływu/interpolacji używany w ostatniej aktualizacji klatki) z ValueAnimator.

Platforma UI

  • Wymuszone renderowanie warstwy
    • Nowa metoda buildLayer() umożliwia aplikacji wymuszanie utworzenia warstwy widoku danych i natychmiastowego wyrenderowania widoku. Aplikacja może na przykład użyć tej metody, aby wyrenderować widok w swojej warstwie przed uruchomieniem animacji. Jeśli widok jest złożony, wyrenderowanie go w warstwie przed rozpoczęciem animacji pozwoli uniknąć pominięcia klatek.
  • Odległość kamery
    • Aplikacje mogą używać nowej metody setCameraDistance(float) do ustawiania odległości od aparatu do widoku. Dzięki temu aplikacje mają większą kontrolę nad przekształceniami 3D widoku, np. obrotami.
  • Uzyskiwanie widoku kalendarza z funkcji DatePicker
  • Otrzymywanie wywołań zwrotnych po odłączeniu widoków danych
  • Detektor menu nawigacyjnego fragmentów, nowy podpis onInflate()
  • Wyświetl wynik wyszukiwania w nowej karcie:
  • Kursor tekstowy z możliwością rysowania
    • W nowym atrybucie zasobu textCursorDrawable możesz teraz wskazać obiekt, który można rysować jako kursor tekstowy.
  • Ustawianie wyświetlanego konta podrzędnego w widokach zdalnych
  • Standardowe klawisze do padów do gier i innych urządzeń wejściowych.
    • KeyEvent dodaje szereg ogólnych kodów klawiszy, aby obsługiwać przyciski na pada do gier. Klasa dodaje też metodę isGamepadButton(int) i kilka innych metod pomocniczych do pracy z kodami kluczy.

Grafika

  • pomoce do zarządzania bitmapami.
    • setHasAlpha(boolean) pozwala aplikacji wskazać, że wszystkie piksele bitmapy są nieprzezroczyste (fałsz) lub niektóre z nich mogą zawierać nieprzezroczyste wartości alfa (true). Uwaga: w przypadku niektórych konfiguracji (np. RGB_565) to wywołanie jest ignorowane, ponieważ nie obsługuje wartości alfa poszczególnych pikseli. To wskazówka, ponieważ w niektórych przypadkach bitmapa, która jest nieprzezroczysta, może szybciej rysować niż ta, która ma nieprzezroczyste wartości alfa na piksel.
    • getByteCount() pobiera rozmiar mapy bitowej w bajtach.
    • getGenerationId() umożliwia aplikacji sprawdzenie, czy mapa bitowa została zmodyfikowana, np. na potrzeby buforowania.
    • sameAs(android.graphics.Bitmap) określa, czy dana bitmapa różni się od bieżącej mapy bitowej danymi dotyczącymi wymiarów, konfiguracji lub pikseli.
  • ustawianie lokalizacji i obrotu kamery;

Sieć

  • Blokada Wi-Fi o wysokiej wydajności
    • Nowa, bardzo wydajna blokada Wi-Fi umożliwia aplikacjom utrzymywanie wysokiej jakości połączeń Wi-Fi nawet po wyłączeniu ekranu urządzenia. Aplikacje, które przez długi czas odtwarzają strumieniowo muzykę, filmy lub głos, mogą uzyskać blokadę Wi-Fi o wysokiej wydajności, aby zapewnić wydajność transmisji nawet na wyłączonym ekranie. Ponieważ zużywają one więcej energii, aplikacje powinny korzystać z wydajnej sieci Wi-Fi, gdy zachodzi potrzeba długotrwałego aktywnego połączenia.

      Aby utworzyć blokadę o wysokiej wydajności, przekaż WIFI_MODE_FULL_HIGH_PERF jako tryb blokady w wywołaniu funkcji createWifiLock().

  • Więcej statystyk ruchu
    • Aplikacje mogą teraz korzystać ze statystyk dotyczących innych typów wykorzystania sieci za pomocą nowych metod w TrafficStats. Aplikacje mogą używać tych metod do uzyskiwania statystyk UDP, liczby pakietów, przesyłania i odbierania bajtów ładunku TCP dla danego identyfikatora UID.
  • Nazwa użytkownika uwierzytelniania SIP

Menedżer pobierania

  • Obsługa ukończonych pobrań
  • Pokaż pobrane pliki posortowane według rozmiaru.

Platforma IME

  • Uzyskiwanie dodatkowego klucza wartości metody wprowadzania

Multimedia

  • Nowe formaty strumieniowania audio
    • Platforma multimediów dodaje wbudowaną obsługę nieprzetworzonych treści AAC w formacie ADTS, lepsze strumieniowanie dźwięku, a także obsługę dźwięku FLAC w celu uzyskania najwyższej jakości (bezstratnego) skompresowanego dźwięku. Więcej informacji znajdziesz w artykule o obsługiwanych formatach multimediów.

Opcje uruchamiania w zatrzymanych aplikacjach

Począwszy od Androida 3.1 menedżer pakietów systemu śledzi aplikacje w stanie zatrzymania i umożliwia kontrolowanie ich uruchamiania z poziomu procesów w tle oraz innych aplikacji.

Pamiętaj, że stan zatrzymania aplikacji to nie to samo co stan zatrzymania aktywności. System osobno zarządza tymi 2 stanami zatrzymania.

Platforma definiuje 2 nowe flagi intencji, które pozwalają nadawcy określić, czy intencja powinna aktywować komponenty w zatrzymanej aplikacji.

Jeśli w intencji nie zdefiniowano żadnej z tych flag lub żadna z tych, domyślnym działaniem jest dodanie filtrów zatrzymanych aplikacji na liście potencjalnych celów.

Pamiętaj, że system dodaje element FLAG_EXCLUDE_STOPPED_PACKAGES do wszystkich intencji. Ma to na celu zapobieganie przypadkowemu lub nieuzasadnionemu uruchomieniu komponentów zatrzymanych aplikacji przez transmisje z usług działających w tle. Usługa lub aplikacja działająca w tle może zastąpić to zachowanie, dodając flagę FLAG_INCLUDE_STOPPED_PACKAGES do intencji, które powinny zezwolić na aktywowanie zatrzymanej aplikacji.

Aplikacje są w stanie zatrzymania w chwili pierwszej instalacji, ale jeszcze nie uruchomione oraz po ręcznym zatrzymaniu przez użytkownika (w sekcji Zarządzaj aplikacjami).

Powiadomienie o pierwszym uruchomieniu i uaktualnieniu aplikacji

Platforma dodaje ulepszone powiadomienia o pierwszym uruchomieniu i uaktualnieniu aplikacji przez 2 nowe działania intencji:

  • ACTION_PACKAGE_FIRST_LAUNCH – wiadomości są wysyłane do pakietu instalatora aplikacji przy pierwszym uruchomieniu (czyli przy pierwszym uruchomieniu ze stanu zatrzymania). Dane te zawierają nazwę pakietu.
  • ACTION_MY_PACKAGE_REPLACED – powiadamia aplikację, że została zaktualizowana, przy czym została zainstalowana nowa wersja zamiast wersji istniejącej. Dane są wysyłane tylko do aplikacji, która została zastąpiona. Nie zawiera on żadnych dodatkowych danych. Aby go odebrać, zadeklaruj filtr intencji dla tego działania. Możesz użyć intencji, aby aktywować kod, który pomoże przywrócić prawidłowe działanie aplikacji po uaktualnieniu.

    Ta intencja jest wysyłana bezpośrednio do aplikacji, ale tylko wtedy, gdy została uaktualniona w czasie, gdy była uruchomiona (a nie zatrzymana).

Podstawowe narzędzia

  • Pamięć podręczna LRU
    • Nowa klasa LruCache umożliwia aplikacjom korzystanie z efektywnego buforowania. Aplikacje mogą korzystać z tej klasy do skrócenia czasu poświęcanego na obliczanie i pobieranie danych z sieci, a jednocześnie utrzymać rozsądną ilość pamięci podręcznej danych.LruCache to pamięć podręczna, która zawiera silne odwołania do ograniczonej liczby wartości. Za każdym razem, gdy uzyskano dostęp do wartości, jest ona przenoszona do nagłówka kolejki. Po dodaniu wartości do pełnej pamięci podręcznej wartość na końcu tej kolejki jest usuwana i może kwalifikować się do czyszczenia pamięci.
  • Deskryptor pliku jako int

WebKit,

  • Pliki cookie schematu plików
    • CookieManager obsługuje teraz pliki cookie, które korzystają ze schematu URI file:. Za pomocą polecenia setAcceptFileSchemeCookies() możesz włączyć lub wyłączyć obsługę plików cookie schematu plików przed utworzeniem wystąpienia WebView lub CookieManager. W instancji CookieManager możesz sprawdzić, czy pliki cookie schematu plików są włączone, wywołując metodę allowFileSchemeCookies().
  • Powiadomienie o prośbie o zalogowanie.
    • Aby obsługiwać funkcje automatycznego logowania w przeglądarce wprowadzone w Androidzie 3.0, nowa metoda onReceivedLoginRequest() powiadamia aplikację hosta o przetworzeniu żądania automatycznego logowania użytkownika.
  • Usunięte klasy i interfejsy:

Przeglądarka

Aplikacja Przeglądarka dodaje do obsługi aplikacji internetowych następujące funkcje:

  • Obsługa odtwarzania w tekście filmów umieszczonych w tagu HTML5 <video>. W miarę możliwości odtwarzanie jest wspomagane sprzętowo.
  • Obsługa warstwowa obsługi elementów o stałej pozycji dla wszystkich witryn (mobilnych i komputerowych).

Stałe nowych cech

Platforma dodaje nowe stałe funkcji sprzętowych, które deweloperzy mogą zadeklarować w plikach manifestu, aby poinformować podmioty zewnętrzne, takie jak Google Play, o wymaganiach aplikacji dotyczących nowych możliwości sprzętowych obsługiwanych w tej wersji platformy. Deweloperzy deklarują te i inne stałe funkcje w elementach manifestu <uses-feature>.

Google Play filtruje aplikacje na podstawie funkcji zadeklarowanych w elementach manifestu <uses-feature>. Więcej informacji o deklarowaniu funkcji w manifeście aplikacji znajdziesz w sekcji Filtry Google Play.

Raport Różnice w interfejsie API

Szczegółowe informacje o wszystkich zmianach dotyczących interfejsów API w Androidzie 3.1 (poziom 12 interfejsów API) znajdziesz w raporcie Różnice w interfejsach API.

Poziom API

Platforma Android 3.1 udostępnia zaktualizowaną wersję interfejsu API platformy. Do interfejsu API Androida 3.1 jest przypisany identyfikator w postaci liczby całkowitej (12), który jest przechowywany w samym systemie. Ten identyfikator, nazywany „poziomem interfejsu API”, pozwala systemowi przed jej zainstalowaniem prawidłowo określić, czy aplikacja jest z nim zgodna.

Aby korzystać z interfejsów API wprowadzonych w Androidzie 3.1, należy skompilować aplikację do biblioteki Androida udostępnianej na platformie SDK Androida 3.1. W zależności od potrzeb może być też konieczne dodanie atrybutu android:minSdkVersion="12" do elementu <uses-sdk> w pliku manifestu aplikacji.

Więcej informacji znajdziesz w artykule Co to jest poziom interfejsu API.