Interfejsy API Androida 3.1

Poziom API: 12

Dla programistów platforma Android 3.1 (HONEYCOMB_MR1) jest dostępny jako dostępny do pobrania komponent Android SDK. Platforma do pobrania zawiera biblioteki Androida i obraz systemu, a także zestaw skórek emulatora i innych. Platforma do pobrania nie zawiera bibliotek zewnętrznych.

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

Omówienie interfejsu API

W sekcjach poniżej znajdziesz techniczny przegląd nowości dla programistów w Androidzie 3.1, w tym nowe funkcje i zmiany w interfejsie API od poprzedniej wersji.

Interfejsy API USB

Android 3.1 wprowadza nowe, zaawansowane interfejsy API integrowanie połączonych urządzeń peryferyjnych z aplikacjami działającymi na platformie. Interfejsy API są oparte na stosie USB (Universal Serial Bus) i usługach, które: wbudowany w platformę, w tym obsługę hosta USB i urządzenia. interakcje. Za pomocą tych interfejsów API programiści mogą tworzyć aplikacje wykrywanie i komunikowanie się z różnymi rodzajami urządzeń połączonych przez USB.

Stos i interfejsy API rozróżniają 2 podstawowe typy sprzętu USB: czy urządzenie z systemem Android działa jako host, czy jako sprzęt zewnętrzny; działa jako host:

  • Urządzenie USB to połączone urządzenie, które zależy od Urządzenie z systemem Android pełniące funkcję hosta. Dotyczy to na przykład większości urządzeń wejściowych, myszy, i joysticki to urządzenia USB, podobnie jak wiele aparatów, koncentratorów i innych urządzeń.
  • Akcesorium USB to połączone urządzenie, które ma port USB kontroler hosta, zasilanie i zaprojektowany do komunikacji z Urządzenia z Androidem przez USB. Różne urządzenia peryferyjne można połączyć jako akcesoria, od kontrolerów dla robotów po sprzęt muzyczny, rowery treningowe i inne.

W przypadku obu typów urządzeń – urządzeń USB i akcesoriów USB – Interfejsy USB API platformy obsługują wykrywanie przez zamierzony komunikat po podłączeniu lub oraz standardowe interfejsy, punkty końcowe i tryby transferu (kontrola, zbiorcze i przerywanie).

Interfejsy API USB są dostępne w pakiecie android.hardware.usb. klasa centralna to UsbManager, która zapewnia metody pomocnicze do identyfikacji i komunikowania się zarówno urządzeń USB, jak i akcesoriów USB. Aplikacje mogą pozyskać instancję UsbManager, a następnie zapytanie o listę dołączonych urządzeń i akcesoriów, a następnie komunikować się z nimi lub nimi zarządzać. UsbManager deklaruje również działania intencji, które komunikatów systemowych, informując o podłączeniu urządzenia USB lub akcesorium; został odłączony.

Inne klasy to:

  • UsbDevice, klasa reprezentująca zasoby zewnętrzne podłączona jako urządzenie USB (urządzenie z systemem Android działa jako hosta).
  • UsbAccessory, reprezentujący zewnętrzny sprzęt połączony jako host USB (urządzenie z Androidem działające jako urządzenie USB).
  • UsbInterface i UsbEndpoint, które zapewniają dostęp do standardowego portu USB interfejsów i punktów końcowych urządzenia.
  • UsbDeviceConnection i UsbRequest do wysyłania i odbierania danych oraz kontroli synchronicznie i asynchronicznie, wysyłając wiadomości do lub z urządzenia USB.
  • UsbConstants, który zawiera stałe do deklarowania typów punktów końcowych, klas urządzeń itp.

Pamiętaj, że chociaż pakiet USB jest wbudowany w platformę, rzeczywiste wsparcie dla hosta USB i trybów akcesoriów na poszczególnych urządzeniach jest określane przez ich producentów. Tryb hosta opiera się na odpowiednich złączach USB, urządzenia z systemem Android.

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

  • Jeśli aplikacja ma być widoczna tylko na urządzeniach obsługujących tryb hosta USB (łączenie 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 USB akcesoriów (połączenia hostów USB), zadeklaruj ten element:

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

Pełne informacje na temat tworzenia aplikacji współpracujących z akcesoriów USB – zapoznaj się z dokumentację dla programistów.

Aby zapoznać się z przykładowymi aplikacjami, które korzystają z interfejsu API hosta USB, zapoznaj się z artykułami ADB Test i Missile Menu z aplikacjami

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 tworzenie aplikacja do otrzymywania powiadomień o podłączeniu i odłączeniu urządzeń, zarządzać plikami i miejscem na tych urządzeniach oraz przenosić pliki i metadane na i od nich. Interfejs MTP API implementuje podzbiór PTP (Picture Transfer Protocol) specyfikacji MTP (Media Transfer Protocol).

Interfejs MTP API jest dostępny w pakiecie android.mtp i zapewnia tych klasach:

  • Pole MtpDevice zawiera urządzenie MTP, przez magistralę hosta USB. Aplikacja może utworzyć instancję obiektu a następnie użyć jego metod, aby uzyskać informacje o urządzeniu zapisane w nim obiekty, a także otwarcie połączenia i przesyłanie danych. Oto niektóre z nich:
    • getObjectHandles() zwraca listę nicków wszystkich obiektów na urządzeniu, które 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 systemie zewnętrznym pamięci masowej. To wywołanie może zostać zablokowane na dowolny czas w zależności od rozmiaru danych i szybkości urządzeń, dlatego należy wybierać w wątku.
    • open() umożliwia aplikacji otwarcie podłączonego urządzenia MTP/PTP.
    • getThumbnail() za możliwość zwrotu i miniaturę obiektu w postaci tablicy bajtów.
  • MtpStorageInfo zawiera informacje o miejscu na dane na urządzeniu MTP odpowiadającemu zbiorowi danych StorageInfo opisanym w sekcji 5.2.2 specyfikacji MTP. Metody klasy umożliwiają aplikacji otrzymasz ciąg opisu jednostki pamięci masowej, informacje o wolnym miejscu, maksymalnej pojemności, identyfikatora miejsca na dane i identyfikatora woluminu.
  • MtpDeviceInfo zawiera informacje o urządzeniu MTP odpowiadające zbiorowi danych DeviceInfo opisanemu w sekcji 5.1.1 specyfikacji MTP. Metody w klasie umożliwiają aplikacjom uzyskanie informacji o producencie, modelu, numerze seryjnym i wersji urządzenia.
  • MtpObjectInfo zawiera informacje o przechowywanym obiekcie na urządzeniu MTP odpowiadające zbiorowi danych ObjectInfo opisanemu w sekcji 5.3.1 specyfikacji MTP. Metody w klasie umożliwiają aplikacjom uzyskanie informacji o rozmiarze obiektu, formacie danych, typie powiązania, dacie utworzenia i miniaturze.
  • MtpConstants zawiera stałe do deklarowania kodów formatu pliku MTP, typu powiązania i stanu ochrony.

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

Android 3.1 rozszerza podsystem wejściowy o obsługę nowych urządzeń wejściowych zdarzeń ruchu we wszystkich widokach i oknach. Deweloperzy mogą tworzyć te funkcje, dzięki którym użytkownicy mogą korzystać z aplikacji za pomocą myszy, kulki, joysticki, kontrolery do gier i inne urządzenia, a także klawiatury i ekrany dotykowe.

Do obsługi myszy, kółka przewijania i manipulatora kulkowego platforma obsługuje 2 nowe działania związane ze zdarzeniami ruchu:

  • ACTION_SCROLL, który opisuje położenie wskaźnika, w którym nastąpiło przewijanie bez dotyku, na przykład za pomocą kółka przewijania myszy. W zdarzenie ruchu wartości osi AXIS_HSCROLL i AXIS_VSCROLL określają względne przesunięcie.
  • ACTION_HOVER_MOVE, zwraca aktualne położenie myszy, gdy nie są naciśnięte żadne przyciski, a także wszystkie punkty pośrednie od ostatniego zdarzenia HOVER_MOVE. Najedź kursorem myszy na klawisz Enter i zamknij Powiadomienia nie są jeszcze obsługiwane.

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

Aby opisać zdarzenia ruchu pochodzące z tych nowych źródeł, a także od myszy i kulki, platforma definiuje teraz kody osi w elemencie MotionEvent, podobnie jak w przypadku kodów kluczy w systemie KeyEvent. Nowe kody osi dla joysticków i kontrolery do gier AXIS_HAT_X, AXIS_HAT_Y, AXIS_RTRIGGER, AXIS_ORIENTATION, AXIS_THROTTLE i wiele innych. Istniejące osie MotionEvent są reprezentowane przez wartości 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 kilka ogólnych kodów osi, które są używane, gdy platforma nie wie, jak zmapować dla danej osi. Określone urządzenia mogą używać ogólnych kodów osi, aby przekazywać niestandardowe wartości. z danymi ruchu do aplikacji. Pełną listę osi i ich przeznaczenia interpretacje znajdują się w dokumentacji klas MotionEvent.

Platforma dostarcza do aplikacji zdarzenia ruchu partiami, więc w jednym miejscu może obejmować bieżącą pozycję i wiele tak zwanych ruchów historycznych. Aplikacje powinny używać funkcji getHistorySize(), aby uzyskać liczbę historycznych próbek, a następnie pobierać i przetwarzać wszystkie historyczne próbki w kolejności za pomocą funkcji getHistoricalAxisValue(). Następnie aplikacje powinny przetworzyć bieżące próbkę wykorzystującą funkcję getAxisValue().

Niektóre osie można pobrać za pomocą specjalnych metod metody dostępu. Przykład: zamiast wywoływać getAxisValue(), aplikacje mogą wywoływać getX(). Osie z wbudowanymi akcesorami to 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 identyfikator przypisany przez system i może też dostarczać dane z kilku źródeł. Gdy urządzenie udostępnia wiele źródeł, może przekazywać dane osi za pomocą tej samej osi. Na przykład nadchodzące zdarzenie dotknięcia ze źródła dotykowego wykorzystuje oś X do określania pozycji ekranu, a joystick zdarzenie pochodzące ze źródła joysticka będzie używać osi X dla pozycji drążka . Z tego powodu ważne jest, aby aplikacje interpretowały oś według źródła, z którego pochodzą. Podczas obsługi zdarzenia ruchu aplikacje powinny używać metod klasy InputDevice, aby określić osie obsługiwane przez urządzenie lub źródło. Konkretnie: aplikacje mogą używać parametru getMotionRanges() do wysyłania zapytań dotyczących wszystkich osi urządzenia lub wszystkich osi danego elementu źródła urządzenia. W obu przypadkach informacje o zakresie osi zwracane w obiekcie InputDevice.MotionRange określają źródło każdej wartości osi.

Ponieważ zdarzenia ruchu generowane przez joysticki, kontrolery do gier, myszy kulki nie są zdarzeniami dotknięciami, platforma dodaje nową metodę wywołania zwrotnego dla przekazanie ich do kategorii View jako „standardowe” zdarzenia ruchu. W szczególności raportuje zdarzenia ruchu bezdotykowego do View za pomocą wywołania funkcji onGenericMotionEvent(), a nie onTouchEvent().

Platforma w różny sposób wysyła ogólne zdarzenia ruchu w zależności od klasę źródła zdarzeń. SOURCE_CLASS_POINTER zdarzeń przejdź do przycisku View pod wskaźnikiem, podobnie jak wydarzenia. Wszystkie pozostałe trafiają do aktywnego elementu View. Oznacza to na przykład, że View musi przejąć fokus, aby odbierać zdarzenia joysticka. W razie potrzeby aplikacje mogą obsługiwać te zdarzenia na poziomie aktywności lub dialogu, implementując tam onGenericMotionEvent().

Aby zapoznać się z przykładową aplikacją, która wykorzystuje ruch joysticka zdarzeń: patrz GameControllerInput. i GameView.

Interfejs API RTP

Android 3.1 udostępnia interfejs API wbudowanemu protokołem RTP (Real-time Transport Protocol) który pozwala aplikacjom zarządzać danymi na żądanie lub danymi interaktywnymi strumieniowanie danych. W szczególności chodzi o aplikacje umożliwiające korzystanie z VOIP, urządzeń typu push, aby rozmawiać, rozmów wideo a strumieniowanie audio może używać interfejsu API do inicjowania sesji oraz transmitowania i odbierania danych strumienie danych w dowolnej dostępnej sieci.

Interfejs API RTP jest dostępny w pakiecie android.net.rtp. Zajęcia uwzględnij:

  • RtpStream, klasa podstawowa strumieni, które wysyłają i odbieranie pakietów sieciowych z ładunkami multimedialnymi przez RTP.
  • AudioStream, podklasa RtpStream, która przenosi dane audio za pomocą protokołu RTP.
  • AudioGroup – lokalne centrum audio do zarządzania miksowanie głośnika, mikrofonu i urządzenia AudioStream.
  • AudioCodec, który zawiera zbiór kodeków zdefiniowanych na potrzeby elementu AudioStream.

Aby zapewnić obsługę rozmów audio i podobnych zastosowań, aplikacja tworzy instancję dwie klasy jako punkty końcowe strumienia:

  • AudioStream określa zdalny punkt końcowy i składa się mapowania sieci i skonfigurowanego AudioCodec.
  • AudioGroup to lokalny punkt końcowy dla jednego lub więcej: AudioStream. Składanka z muzyką z gatunku AudioGroup wszystkie moduły AudioStream i opcjonalnie współdziałają z urządzeniem głośnik i mikrofon.

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

Aby używać interfejsu API RTP, aplikacje muszą prosić użytkownika o zgodę przez deklaruję: <uses-permission android:name="android.permission.INTERNET"> w plikach manifestu. Aby uzyskać dostęp do mikrofonu urządzenia, wymagane jest też 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ą tworzyć swoje widżety na ekranie głównym z możliwością zmiany rozmiaru – w poziomie, w pionie lub na obu osiach. Użytkownicy przytrzymują klawisz A widżet, aby wyświetlić uchwyty zmiany rozmiaru, a następnie przeciągnij go w pionie lub poziomie uchwyty do zmiany rozmiaru siatki układu.

Programiści mogą zmienić rozmiar dowolnego widżetu na ekranie głównym, definiując Atrybut resizeMode w metadanych AppWidgetProviderInfo widżetu. Wartości atrybutu resizeMode to „horizontal”, „vertical” i „none”. Aby zadeklarować widżet jako możliwy do zmiany rozmiaru w poziomie i w pionie, podaj wartość „poziome|pionowe”.

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 artykule Widżety aplikacji. dokumentacji.

Schemat animacji

  • Nowa klasa ViewPropertyAnimator
    • Nowa klasa ViewPropertyAnimator udostępnia wygodny pozwala programistom animować wybrane właściwości obiektów View. Klasa automatyzuje i optymalizuje animację właściwości oraz ułatwia możesz zarządzać wieloma jednocześnie animowanymi animacjami w obiekcie View.

      Korzystanie z ViewPropertyAnimator jest proste. Aby animować właściwości elementu View, zadzwoń pod numer animate() Utwórz obiekt ViewPropertyAnimator dla tego elementu (View). Użyj w ViewPropertyAnimator, aby określić, którą właściwość ani sposobu ich animacji. Aby na przykład View stał się przezroczysty, wywołaj funkcję alpha(0);. Obiekt ViewPropertyAnimator obsługuje szczegóły konfigurowania bazowej klasy Animator i uruchamiania jej, a następnie renderowania animację.

  • Kolor tła animacji
  • Pobieram animowany ułamek z pola ViewAnimator
    • Nowy getAnimatedFraction() metoda pozwala poznać bieżący ułamek animacji – czas, jaki upłynął lub interpolowany. ułamek używany w ostatniej aktualizacji ramki – z ValueAnimator.

Platforma interfejsu

  • Wymuszone renderowanie warstwy
    • Nowa metoda buildLayer() pozwala aplikacji wymusza utworzenie warstwy widoku i natychmiastowe wyrenderowanie jej widoku. Aplikacja może na przykład użyć tej metody, aby przed rozpoczęciem animacji wyrenderować widok w swojej warstwie. Jeśli widok jest złożony, renderuj go w warstwa przed rozpoczęciem animacji pozwala uniknąć pomijania klatek.
  • Odległość kamery
    • Aplikacje mogą używać nowej metody setCameraDistance(float), aby ustawić odległość od kamera widoku. Dzięki temu aplikacje zyskują większą kontrolę nad przekształceniami 3D widoku, takimi jak jego obracanie.
  • Pobieranie widoku kalendarza z DatePickera
  • Otrzymywanie wywołań zwrotnych po odłączeniu widoków
  • Detektor menu nawigacyjnego fragmentu, nowy podpis onInflate()
  • Wyświetl wynik wyszukiwania w nowej karcie
  • Kursor tekstowy do rysowania
    • Teraz możesz określić obiekt rysowalny, który ma być używany jako kursor tekstowy, za pomocą nowego atrybutu zasobu textCursorDrawable.
  • Ustawianie wyświetlanego elementu podrzędnego w widokach zdalnych
  • Ogólne klawisze do padów do gier i innych urządzeń wejściowych
    • KeyEvent dodaje szereg ogólnych kodów kluczy do pod kątem przycisków do gier. Zajęcia pozwalają też dodać isGamepadButton(int) i kilka innych metod pomocniczych do pracy z kodami kluczy.

Grafika

  • Pomoc dotycząca zarządzania mapami bitowymi
    • setHasAlpha(boolean) pozwala aplikacji określić, że wszystkie piksele w Bitmapie są nieprzezroczyste (fałsz) lub że niektóre piksele mogą zawierać nieprzezroczyste wartości alfa (prawda). Uwaga: w przypadku niektórych konfiguracji (np. jako RGB_565) to wywołanie jest ignorowane, ponieważ nie obsługuje kanałów alfa na piksel . Jest to wskazówka dotycząca rysowania, ponieważ w niektórych przypadkach bitmapa, która jest nieprzejrzysta, może być rysowana szybciej niż bitmapa, która ma nieprzezroczyste wartości alfa na poziomie piksela.
    • getByteCount() uzyskuje rozmiar mapy bitowej w skale B.
    • getGenerationId() pozwala aplikacji sprawdzić, czy obraz Bitmap został zmodyfikowany, np. w celu wykorzystania w pamięci podręcznej.
    • sameAs(android.graphics.Bitmap) określa czy dana mapa bitowa różni się od bieżącej mapy bitowej pod względem wymiarów, konfiguracji i danych pikseli.
  • Ustawianie lokalizacji i obrotu kamery

Sieć

  • Wydajna blokada Wi-Fi
    • Nowa blokada sieci Wi-Fi o wysokiej wydajności umożliwia aplikacjom wydajne połączenia Wi-Fi nawet przy wyłączonym ekranie. Aplikacje, które przez dłuższy czas odtwarzają muzykę, filmy lub głosy głosowe, mogą pozyskiwać: wysokiej jakości blokada Wi-Fi, która umożliwia strumieniowanie nawet na ekranie jest wyłączony. Ze względu na większe zużycie energii aplikacje powinny pobierać Wi-Fi o wysokiej wydajności, gdy wymagane jest długotrwałe uruchomienie połączenia.

      Aby utworzyć bardzo skuteczną blokadę, przekaż WIFI_MODE_FULL_HIGH_PERF jako tryb blokady w połączenie z numerem createWifiLock().

  • Więcej statystyk ruchu
    • Aplikacje mogą teraz uzyskiwać dostęp do statystyk dotyczących większej liczby typów wykorzystania sieci za pomocą nowych metod w TrafficStats. Aplikacje mogą korzystać z metod pobierania statystyk UDP, liczby pakietów, bajtów transmisji/odbierania TCP dla danego identyfikatora UID.
  • Nazwa użytkownika uwierzytelniania SIP

Menedżer pobierania

platforma IME

  • Uzyskiwanie klucza wartości dodatkowej metody wprowadzania

Multimedia

  • Nowe strumieniowane formaty audio
    • Platforma multimedialna ma wbudowaną obsługę nieprzetworzonych materiałów AAC ADTS, ulepszone strumieniowanie dźwięku oraz obsługa dźwięku FLAC zapewniające najwyższą jakość (bezstratnych) skompresowanych treści audio; Zobacz obsługiwane formaty multimediów dokument, aby dowiedzieć się więcej.

Zatrzymano elementy sterujące uruchamianiem aplikacji

Począwszy od Androida 3.1 menedżer pakietów systemu śledzi aplikacje, które są w stanie zatrzymanym, i zapewnia możliwość kontrolowania ich uruchamiania z procesów działających w tle i z innych aplikacji.

Pamiętaj, że stan zatrzymania aplikacji to nie to samo co stan działania zatrzymano. System oddzielnie zarządza tymi 2 stanami zatrzymania.

Platforma definiuje 2 nowe flagi intencji, które umożliwiają nadawcy czy intencja powinna mieć możliwość aktywowania komponentów w zatrzymanych komponentach aplikacji.

Jeśli w intencji nie zdefiniowano żadnej z tych flag (albo żadna z tych flag), domyślnie zachowanie to uwzględnienie filtrów zatrzymanych aplikacji na liście potencjalnych wartościach docelowych.

Zwróć uwagę, że system dodaje element FLAG_EXCLUDE_STOPPED_PACKAGES do całej transmisji Zapobiega to wysyłaniu komunikatów z usług w tle niezamierzone lub niepotrzebne uruchamianie komponentów zatrzymanych aplikacji. Usługa lub aplikacja działająca w tle może zastąpić to zachowanie, dodając parametr Flaga FLAG_INCLUDE_STOPPED_PACKAGES do przesłania które powinny umożliwiać aktywowanie zatrzymanych aplikacji.

Aplikacje są w stanie zatrzymania w chwili, gdy są instalowane po raz pierwszy, ale nie są jeszcze uruchomione i ręcznie zatrzymane przez użytkownika (w sekcji Zarządzaj aplikacji).

Powiadomienie o pierwszym uruchomieniu i uaktualnieniu aplikacji

Platforma dodaje ulepszone powiadomienia o pierwszym uruchomieniu aplikacji oraz uaktualnienia za pomocą 2 nowych działań intencji:

  • ACTION_PACKAGE_FIRST_LAUNCH – wysyłane do pakietu instalacyjnego aplikacji przy jej pierwszym uruchomieniu (czyli przy pierwszym przejściu z stanu zatrzymanego). Dane zawiera nazwę pakietu.
  • ACTION_MY_PACKAGE_REPLACED – powiadamia aplikację, która została zaktualizowana i zainstalowana nowa wersja. istniejącej wersji. Jest on wysyłany tylko do aplikacji, która została zastąpiona. Nie zawiera on żadnych dodatkowych danych. Aby je otrzymać, zadeklaruj filtr intencji dla tego działania. Za pomocą intencji możesz aktywować kod, który pomaga uzyskać po uaktualnieniu aplikacja powinna znowu działać w prawidłowym stanie.

    Ta intencja jest wysyłana bezpośrednio do aplikacji, ale tylko wtedy, gdy uaktualniono, gdy było w stanie uruchomienia (a nie w stanie zatrzymania).

Podstawowe narzędzia

  • Pamięć podręczna LRU
    • Nowa klasa w języku LruCache zapewnia Twoim aplikacjom korzyści z wydajnego buforowania. Aplikacje mogą używać klasy w celu skrócenia czasu poświęcanego na używanie klasy przetwarzania i pobierania danych z sieci przy zachowaniu rozsądnego ilość pamięci dla danych w pamięci podręcznej.LruCache oznacza pamięć podręczną który zawiera silne odwołania do ograniczonej liczby wartości. Za każdym razem, gdy wartość jest gdy uzyskano dostęp, jest on przeniesiony na początek kolejki. Po dodaniu wartości do pełnego pola wartość na końcu kolejki jest usuwana i może kwalifikować się do czyszczenia pamięci.
  • Deskryptor pliku jako int

WebKit

  • Pliki cookie schematu pliku
    • CookieManager obsługuje teraz pliki cookie, które używają Schemat URI file:. Za pomocą usługi setAcceptFileSchemeCookies() możesz: włącz/wyłącz obsługę plików cookie schematów plików przed utworzeniem instancji. z WebView lub CookieManager. W przypadku CookieManager możesz sprawdzić, czy pliki cookie schematu plików są włączone, wywołując funkcję allowFileSchemeCookies().
  • Powiadomienie o prośbie o logowanie
    • Aby obsługiwać funkcje automatycznego logowania w przeglądarce wprowadzone w Androidzie 3.0, nowa metoda onReceivedLoginRequest()powiadamia aplikację goszczącą, że żądanie automatycznego logowania użytkownika zostało przetworzone.
  • Usunięte klasy i interfejsy
    • Kilka klas i interfejsów zostało usuniętych z publicznego interfejsu API, które zostały wcześniej wycofane. Zapoznaj się z interfejsem API Raportu różnic, aby dowiedzieć się więcej.

Przeglądarka

Aplikacja Przeglądarka dodaje następujące funkcje, aby obsługiwać przeglądarki internetowe aplikacje:

  • Obsługa odtwarzania wbudowanego w tag HTML5 <video> filmu. W miarę możliwości odtwarzanie odbywa się z akceleracją sprzętową.
  • Obsługa warstw o stałej pozycji we wszystkich witrynach (mobilnych na komputerze).

Nowe stałe cech

Platforma dodaje nowe stałe funkcji sprzętowych, które deweloperzy mogą zadeklarować. w plikach manifestu aplikacji, aby informować podmioty zewnętrzne, takie jak Google Odtwarzanie wymagań aplikacji w zakresie obsługi nowych funkcji sprzętowych w tej wersji platformy. Deweloperzy deklarują te i inne stałe funkcji w elementach pliku manifestu <uses-feature>.

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

Raport o różnicach w interfejsie API

Szczegółowe informacje o wszystkich zmianach interfejsu API w Androidzie 3.1 (poziom interfejsu API 12) znajdziesz w raporcie z różnicami w interfejsie API.

Poziom interfejsu API

Android 3.1 udostępnia zaktualizowaną wersję platformy API. Interfejs API systemu Android 3.1 jest przydzielony identyfikator w postaci liczby całkowitej – 12 – czyli zapisanych w samym systemie. Ten identyfikator, nazywany „poziomem interfejsu API”, umożliwia stosowanie funkcji systemu pozwalającego poprawnie określić, czy aplikacja jest zgodna z systemu.

Aby używać w swojej aplikacji interfejsów API wprowadzonych w Androidzie 3.1, musisz skompilować aplikację z użyciem biblioteki Androida dostępnej w ramach platformy pakietu SDK Androida 3.1. W zależności od potrzeb może trzeba też dodać android:minSdkVersion="12" do elementu <uses-sdk> w nagłówku aplikacji pliku manifestu.

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