Interfejsy API Androida 3.2

Poziom API: 13

Android 3.2 (HONEYCOMB_MR2) to przyrostowa wersja platformy, która dodaje nowe dla użytkowników i deweloperów. W sekcjach poniżej znajdziesz omówienie o nowych funkcjach i interfejsach API dla programistów.

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

Najważniejsze informacje o platformie

Nowe funkcje dla użytkowników

  • Optymalizacje pod kątem większej liczby tabletów

    Android 3.2 oferuje różne optymalizacje w systemie z myślą o wygodzie użytkowników szerokiej gamy tabletów.

  • Powiększenie zgodne z aplikacjami o stałym rozmiarze

    Android 3.2 wprowadza nowy tryb powiększenia zgodności, który umożliwia użytkownicy mogą wyświetlać aplikacje o stałym rozmiarze na większych urządzeniach. Nowy tryb zapewnia do pikseli skalowana jako alternatywa dla standardowego rozciągania interfejsu użytkownika dla aplikacji, które nie zaprojektowany z myślą o większych ekranach, np. na tabletach. Nowy tryb to jest dostępna po kliknięciu ikony menu na pasku systemowym. Dotyczy to aplikacji, które muszą obsługę zgodności.

  • Synchronizacja multimediów z karty SD

    Na urządzeniach obsługujących kartę SD użytkownicy mogą teraz ładować pliki multimedialne z karty SD do aplikacji, które z nich korzystają. Obiekt systemu sprawia, że pliki dostępne dla aplikacji z systemowego sklepu multimedialnego.

Nowe funkcje dla programistów

  • Rozszerzony interfejs API do zarządzania obsługą ekranów

    Android 3.2 wprowadza rozszerzenia do interfejsu API do obsługi ekranu, dają programistom dodatkowe sposoby zarządzania interfejsem użytkownika aplikacji Urządzenia z systemem Android. Interfejs API zawiera nowe kwalifikatory zasobów i nowe w pliku manifestu, które dają dokładniejszą kontrolę nad aplikacje są wyświetlane w różnych rozmiarach, zamiast polegać na uogólnieniu kategorii rozmiarów.

    Aby zapewnić najlepszą jakość wyświetlania w przypadku aplikacji o stałym rozmiarze i z ograniczeniami obsługuje różne rozmiary ekranów, a platforma udostępnia też nowe powiększenie. tryb zgodności, który najpierw renderuje interfejs na mniejszym ekranie, a potem go skaluje. do wypełnienia całego ekranu. Więcej informacji na temat API do obsługi ekranu i dostępne w nim opcje znajdziesz w sekcjach poniżej.

Omówienie interfejsu API

Interfejsy API związane z obsługą ekranów

W Androidzie 3.2 pojawiły się nowe ekrany, które obsługują interfejsy API, kontrolować, jak ich aplikacje są wyświetlane na ekranach o różnych rozmiarach. Opiera się on na istniejącym interfejsie API obsługującym ekrany, w tym uogólniony model gęstości ekranu, ale rozszerza go o możliwość precyzyjnego kierować reklamy na określone zakresy ekranów według ich wymiarów, mierzonych w niezależne od gęstości jednostki pikseli (np. 600 dp lub 720 dp), a nie według ich uogólnionych rozmiarów ekranów (np. duży lub bardzo duży).

Projektując interfejs aplikacji, nadal możesz polegać na platformie zapewnia abstrakcję gęstości, co oznacza, że aplikacje nie muszą kompensują różnice w rzeczywistej gęstości pikseli na różnych urządzeniach. Ty Potrafi zaprojektować interfejs aplikacji odpowiednio do dostępnych miejsc. Platforma wyraża ilość dostępnego miejsca za pomocą 3 nowych cechy: smallestWidth, width i height.

  • smallestSzerokość to parametr minimalny dla rozmiaru ekranu, mierzone w jednostkach pikseli niezależnych od gęstości („dp”). Wysokość ekranu lub jest mniejsza. W przypadku ekranu w orientacji pionowej W orientacji poziomej jest określana na podstawie szerokości, na jego wysokości. We wszystkich przypadkach najmniejsza szerokość jest określana ze stałej cechy parametru ekranu, a wartość nie zmienia się bez względu na orientację. Najmniejsza szerokość jest ważny w zastosowaniach, ponieważ reprezentuje najmniejszą możliwą szerokość w którym należy narysować interfejs aplikacji (bez obszarów ekranu). zarezerwowane przez system.
  • Szerokość i wysokość ekranu przedstawiają natomiast bieżąca przestrzeń pozioma lub pionowa dostępna dla układu aplikacji, mierzona w „dp” jednostek reklamowych, z wyłączeniem obszarów ekranu zarezerwowanych przez system. Szerokość wysokość ekranu zmienia się, gdy użytkownik przełączy orientację poziomą i pionowej.

Interfejs API został zaprojektowany pod kątem obsługi nowych ekranów, aby umożliwić Ci zarządzanie interfejsem aplikacji zgodnie z najmniejszą szerokością bieżącego ekranu. Możesz też zarządzać UI dostosowywany do bieżącej szerokości lub wysokości, w razie potrzeby. W tych celach interfejs API udostępnia następujące narzędzia:

  • Nowe kwalifikatory zasobów do kierowania na układy i inne zasoby minimalna minimalna szerokość, szerokość lub wysokość oraz
  • Nowe atrybuty pliku manifestu, które służą do określania maksymalnej wartości aplikacji zakres zgodności z ekranem

Ponadto aplikacje mogą nadal wysyłać zapytania do systemu i zarządzać interfejsem użytkownika oraz gdy zasoby są wczytywane w czasie działania, tak jak w poprzednich wersjach platformy.

Nowy interfejs API pozwala bardziej bezpośrednio kierować reklamy na ekrany o wymiarach najmniejszej szerokości, szerokości i wysokości, dobrze jest poznać typowe różne rodzaje ekranów. W tabeli poniżej znajdziesz niektóre przykładów mierzonych w „dp” jednostek reklamowych.

Tabela 1. Typowe urządzenia o gęstości i rozmiar w dp.

Typ Gęstość (ogólna) Wymiary (dp) najmniejszej szerokości (dp)
Telefon podstawowy mdpi 320 × 480 320
Mały tablet/duży telefon mdpi 480 × 800 480
Tablet 7-calowy mdpi 600x1024 600
Tablet 10-calowy mdpi 800x1280 800

W sekcjach poniżej znajdziesz więcej informacji o nowych kwalifikatorach ekranu. i atrybuty w pliku manifestu. Pełne informacje o korzystaniu z ekranu support API, patrz Obsługa wielu opcji Ekrany.

Nowe kwalifikatory zasobów do obsługi ekranów

Nowe kwalifikatory zasobów w Androidzie 3.2 umożliwiają lepsze kierowanie na układy dla różnych rozmiarów ekranów. Korzystając z kwalifikatorów, możesz utworzyć zasób konfiguracje zaprojektowane z myślą o konkretnej minimalnej szerokości, najmniejszej szerokości lub bieżącej szerokości wysokość mierzona w pikselach niezależnych od gęstości.

Nowe kwalifikatory:

  • swNNNdp – określa minimalną najmniejszą najmniejszą szerokość, na której zasób, którego należy użyć, mierzony w „dp” jednostek reklamowych. Jak wspomniano powyżej, najmniejsza szerokość ekranu jest stała, niezależnie od orientacji. Przykłady: sw320dp, sw720dp, sw720dp.
  • wNNNdp i hNNNdp – określa wartość minimalną, szerokość lub wysokość, na której powinien być używany zasób, mierzona w „dp”; jednostek reklamowych. Jako jak wspomnieliśmy powyżej, szerokość i wysokość ekranu zależą od orientacji i zmieniać ją wraz ze zmianą orientacji. Przykłady: w320dp, w720dp, h1024dp.

W razie potrzeby możesz też utworzyć wiele nakładających się konfiguracji zasobów. Możesz na przykład oznaczyć tagiem niektóre zasoby na ekranach szerszych niż 480 pikseli. dp, inne powyżej 600 dp, a inne powyżej 720 dp. Kiedy dla danego ekranu kwalifikuje się wiele konfiguracji zasobów, wybiera konfigurację, która jest najbardziej dopasowana. Precyzyjna kontrola które zasoby są ładowane na danym ekranie, możesz oznaczyć zasoby tagiem kwalifikatora ani łączyć kilku nowych lub istniejących kwalifikatorów.

Oto kilka przykładów na podstawie typowych wymiarów wymienionych powyżej, można wykorzystać nowe kwalifikatory:

res/layout/main_activity.xml   # For phones
res/layout-sw600dp/main_activity.xml   # For 7” tablets
res/layout-sw720dp/main_activity.xml   # For 10” tablets
res/layout-w600dp/main_activity.xml   # Multi-pane when enough width
res/layout-sw600dp-w720dp/main_activity.xml   # For large width

Starsze wersje platformy ignorują nowe kwalifikatory, dzięki czemu możesz aby aplikacja dobrze się wyświetlała na każdym urządzeniu. Tutaj Oto kilka przykładów:

res/layout/main_activity.xml   # For phones
res/layout-xlarge/main_activity.xml   # For pre-3.2 tablets
res/layout-sw600dp/main_activity.xml   # For 3.2 and up tablets

Szczegółowe informacje na temat korzystania z nowych kwalifikatorów znajdziesz w sekcji Korzystanie z nowych kwalifikatory rozmiaru.

Nowe atrybuty w pliku manifestu zgodności z rozmiarem ekranu

Platforma udostępnia nowy zestaw atrybutów pliku manifestu <supports-screens>, które pozwalają i zarządzasz obsługą różnych rozmiarów ekranu w aplikacji. W szczególności możesz określić największy i najmniejszy ekran, na którym aplikacja z największym ekranem, na którym działa bez konieczności korzystania z nowego ekranu trybu zgodności. Podobnie jak w przypadku opisanych powyżej kwalifikatorów zasobów, nowa funkcja atrybuty manifestu określają zakres ekranów, które obsługuje aplikacja, zgodnie z wartością najmniejszej szerokości.

Nowe atrybuty w pliku manifestu do obsługi ekranów to:

  • android:compatibleWidthLimitDp="numDp" – to pozwala określić maksymalną najmniejszą najmniejszą szerokość, dla której aplikacja które mogą działać bez trybu zgodności. Jeśli bieżący ekran jest większy niż system wyświetla aplikację w trybie normalnym, ale pozwala użytkownikowi opcjonalnie przełączyć się na tryb zgodności na pasku systemu.
  • android:largestWidthLimitDp="numDp" – to pozwala określić maksymalną najmniejszą najmniejszą szerokość, dla której aplikacja z myślą o działaniu. Jeśli obecny ekran jest większy niż określona wartość, system wymusza przejście aplikacji w tryb zgodności z ekranem, aby zapewnić wyświetlane na bieżącym ekranie.
  • android:requiresSmallestWidthDp="numDp" – to pozwala określić minimalną najmniejszą najmniejszą szerokość, dla której aplikacja może działać. Jeśli bieżący ekran jest mniejszy niż określona wartość, system uznaje aplikację za niekompatybilną z urządzeniem, ale nie zapobiega jej przed instalacją i uruchomieniem.

Uwaga: Google Play nie filtruje obecnie aplikacji na podstawie dowolnego z powyższych atrybutów. Obsługą filtrowania będzie dodane w jednej z kolejnych wersji platformy. Aplikacje, które wymagają filtrowanie na podstawie rozmiaru ekranu może korzystać z istniejących funkcji <supports-screens> .

Pełne informacje na temat korzystania z nowych atrybutów znajdziesz w sekcji Deklarowanie obsługi rozmiaru ekranu.

Tryb zgodności z ekranem

Android 3.2 oferuje nowy tryb zgodności z ekranem dla aplikacji wyraźnie zadeklarować, że nie obsługuje ekranów tak dużych jak ich działania. To nowe powiększenie jest jak piksel, renderuje aplikację na mniejszym ekranie, a potem skaluje piksele, wypełni bieżący ekran.

Domyślnie system oferuje użytkownikom tryb zgodności z ekranem. które tego wymagają. Użytkownicy mogą włączać i wyłączać tryb powiększenia za pomocą dostępnego elementu sterującego na pasku systemowym.

Ponieważ nowy tryb zgodności z ekranami może nie być odpowiedni dla wszystkich aplikacji, platforma umożliwia aplikacji jej wyłączenie przy użyciu pliku manifestu . Jeśli wyłączysz tę funkcję przez aplikację, system nie będzie obsługiwać powiększenia. zgodność jako opcję dla użytkowników, gdy aplikacja jest uruchomiona.

Uwaga: ważne informacje o tym, jak aby dowiedzieć się, jak sterować trybem zgodności w swoich aplikacjach, przeczytaj artykuł Nowy tryb aplikacji na dużych ekranach na urządzeniu z Androidem. Blog dla deweloperów.

Nowa gęstość ekranu dla telewizorów 720p i podobnych urządzeń

Aby zaspokoić potrzeby aplikacji działających na telewizorach 720p lub podobnych, do ekranów o umiarkowanej gęstości, Android 3.2 wprowadza nową ogólną gęstość. tvdpi, przybliżoną rozdzielczość 213 dpi. Aplikacje, o które mogą wysyłać zapytania nową gęstość w densityDpi i może używać nowy kwalifikator tvdpi służący do oznaczania zasobów telewizyjnych i na podobnych urządzeniach. Na przykład:

res/drawable-tvdpi/my_icon.png   # Bitmap for tv density

Zwykle aplikacje nie muszą obsługiwać takiej gęstości. Sytuacje gdzie w przypadku ekranu o rozdzielczości 720p wymagane są dane wyjściowe, elementy interfejsu można skalować. automatycznie przez platformę.

Platforma interfejsu

  • Fragmenty
    • Nowa klasa Fragment.SavedState zawiera stan informacje pobrane z instancji fragmentu przez saveFragmentInstanceState()
    • Nowa metoda saveFragmentInstanceState() zapisuje bieżący stan instancji danego fragmentu. Stanu można użyć później podczas tworzenia nowej instancji fragmentu, który pasuje do bieżącego stanu.
    • Nowa metoda setInitialSavedState() ustawia początkowy stan zapisanego stanu fragmentu przy pierwszym utworzeniu.
    • Nowa metoda wywołania zwrotnego onViewCreated() powiadamia fragment, który onCreateView() ale przed przywróceniem jakiegokolwiek zapisanego stanu do widoku.
    • Metoda isDetached() określa, czy fragment został jawnie odłączony od interfejsu użytkownika.
    • Nowy: attach() i detach() pozwalają aplikacji ponownie dołączać lub odłączać fragmenty w interfejsie użytkownika.
    • Nowa metoda przeciążenia setCustomAnimations() umożliwia ustawienie konkretnej animacji na potrzeby operacji wejścia/wyjścia, a zwłaszcza wtedy, i jeszcze bardziej rozwiniemy skrzydła. Obecna implementacja nie uwzględnia dla różnych sposobów zachowania fragmentów przy wydzielaniu tylnego stosu.
  • Informacje o rozmiarze ekranu w ActivityInfo i ApplicationInfo
  • Pomoc dotycząca pobierania rozmiaru interfejsu WindowManager
    • Nowe metody getSize() i getRectSize() pozwalają aplikacjom na pobieranie nieprzetworzonego rozmiaru wyświetlacza.
  • Nowy publiczny „holograficzny” style
    • Platforma ujawnia teraz wiele publicznych „holograficznych” style do tekstu, a także widżetów i kart na pasku działań. Zobacz R.style, aby zobaczyć pełną listę.
  • LocalActivityManager, ActivityGroup i Interfejs LocalActivityManager został wycofany
      .
    • Nowe aplikacje powinny używać fragmentów zamiast tych klas. Do na starszych wersjach platformy, możesz skorzystać z pomocy Biblioteka (biblioteka zgodności) dostępna w pakiecie SDK Androida. Pomoc do wersji 4 Biblioteka udostępnia wersję interfejsu Fragment API zgodną ze standardem Android 1.6 (poziom API 4).
    • Dla aplikacji działających na Androidzie 3.0 (poziom interfejsu API) 11) lub wyższej, karty są zwykle przedstawiane w interfejsie za pomocą ActionBar.newTab() i powiązane interfejsy API który pozwala umieścić karty w obszarze paska działań.

Struktura mediów

  • Aplikacje korzystające z dostawcy multimediów platformy (MediaStore) mogą teraz odczytywać dane multimedialne bezpośrednio z wyjmowaną kartę SD, jeśli urządzenie ją obsługuje. Aplikacje mogą również i bezpośredniej interakcji z plikami na karcie SD za pomocą interfejsu API MTP.

Grafika

platforma IME

  • Nowa metoda getModifiers() dla pobranie bieżącego stanu klawiszy modyfikujących.

Platforma USB

  • Nowa metoda getRawDescriptors() dla pobierania nieprzetworzonych deskryptorów USB dla urządzenia. Za pomocą metody dostępu do deskryptorów, które nie są obsługiwane bezpośrednio przez interfejsów API.

Sieć

Telefonia

Podstawowe narzędzia

Nowe stałe cech

Platforma dodaje nowe stałe funkcji sprzętowych, które możesz zadeklarować. w plikach manifestu aplikacji, aby informować podmioty zewnętrzne, takie jak Google Podawanie niezbędnych funkcji sprzętu i oprogramowania. Deklarujesz te i inne stałe cechy w elementach manifestu <uses-feature>.

Google Play filtruje aplikacje według atrybutów <uses-feature>, aby mieć pewność, że są one dostępne tylko na urządzeniach, które spełniają ich wymagania.

  • Stałe cech dla wymagań orientacji poziomej lub pionowej

    Android 3.2 wprowadza nowe stałe funkcje, które pozwalają aplikacjom określić, czy wymagają wyświetlacza w orientacji poziomej, pionowej czy w obu tych sieciach. Zadeklarowanie tych stałych oznacza, że aplikacji nie można zainstalować na urządzeniu, które nie obsługuje powiązanej orientacji. Jeśli natomiast nie zostanie zadeklarowana co najmniej jedna ze stałych, oznacza to, że aplikacja nie preferuje niezadeklarowanych orientacji i można ją zainstalować na urządzeniu, które ich nie oferuje.

    Typowa aplikacja, która działa poprawnie zarówno w orientacji poziomej, jak i pionowej, zwykle nie wymaga deklaracji wymagań dotyczących orientacji. Aplikacja zaprojektowana głównie pod kątem jednej orientacji (np. aplikacja na telewizory) może zadeklarować jedną ze stałych, by zapewnić, że nie będzie dostępna na urządzeniach, które nie mają takiej orientacji.

    Jeśli jakiekolwiek działania zadeklarowane w żądaniu pliku manifestu są uruchamiane w określonej orientacji, za pomocą atrybutu android:screenOrientation, oznacza to również deklarowanie, że aplikacja wymaga takiej orientacji.

  • Inne stałe cech

Raport o różnicach w interfejsie API

Szczegółowy widok wszystkich zmian interfejsu API w Androidzie 3.2 Poziom 13), patrz interfejs API Raportu różnic.

Poziom API

Android 3.2 udostępnia zaktualizowaną wersję platformy API. Interfejs API systemu Android 3.2 jest przydzielony identyfikator w postaci liczby całkowitej – 13 – 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 skorzystać z interfejsów API wprowadzonych w Androidzie 3.2 w aplikacji, musisz skompilować aplikację zgodnie z biblioteką Androida w bibliotece z platformy Android 3.2 SDK. W zależności od potrzeb może trzeba też dodać android:minSdkVersion="13" do elementu <uses-sdk> w nagłówku aplikacji pliku manifestu.

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