APIs unter Android 3.2

API-Level: 13

Android 3.2 (HONEYCOMB_MR2) ist ein inkrementeller Plattformrelease, der neue Funktionen für Nutzer und Entwickler hinzufügt. Die folgenden Abschnitte bieten einen Überblick über die neuen Funktionen und Entwickler-APIs.

Für Entwickler steht die Plattform Android 3.2 als herunterladbare Komponente für das Android SDK zur Verfügung. Die herunterladbare Plattform umfasst eine Android-Bibliothek, ein System-Image, eine Reihe von Emulator-Skins und mehr. Wenn du mit der Entwicklung oder Tests für Android 3.2 beginnen möchtest, lade die Plattform mit dem Android SDK Manager in dein SDK herunter.

Plattform-Highlights

Neue Nutzerfunktionen

  • Optimierungen für eine größere Auswahl an Tablets

    Android 3.2 umfasst eine Reihe von Optimierungen für das gesamte System, um eine positive Nutzererfahrung auf einer breiteren Palette von Tablet-Geräten zu gewährleisten.

  • Kompatibilitätszoom für Apps mit fester Größe

    Mit Android 3.2 wird ein neuer Kompatibilitätszoommodus eingeführt, mit dem Nutzer Apps mit fester Größe auf größeren Geräten ansehen können. Der neue Modus bietet eine auf Pixel skalierte Alternative zur Standard-UI-Dehnung für Apps, die nicht für größere Bildschirme entwickelt wurden, z. B. auf Tablets. Nutzer können bei Anwendungen, die Kompatibilitätsunterstützung benötigen, über ein Menüsymbol in der Systemleiste auf den neuen Modus zugreifen.

  • Mediensynchronisierung von SD-Karte

    Auf Geräten, die SD-Karten unterstützen, können Nutzer Mediendateien jetzt direkt von der SD-Karte in Apps laden, die sie verwenden. Eine Systemeinrichtung macht die Dateien für Anwendungen aus dem Systemmedienspeicher zugänglich.

Neue Funktionen für Entwickler

  • Erweiterte API für die Verwaltung von Bildschirmunterstützung

    Mit Android 3.2 werden Erweiterungen für die Screen Support API der Plattform eingeführt, um Entwicklern zusätzliche Möglichkeiten zur Verwaltung der Anwendungs-UI auf verschiedenen Android-Mobilgeräten zu bieten. Die API enthält neue Ressourcenqualifizierer und Manifestattribute, mit denen Sie genauer steuern können, wie Ihre Apps in verschiedenen Größen angezeigt werden, anstatt sich auf allgemeine Größenkategorien zu verlassen.

    Damit Apps mit fester Größe und Apps mit begrenzter Unterstützung für verschiedene Bildschirmgrößen optimal dargestellt werden, bietet die Plattform auch einen neuen Kompatibilitätsmodus für Zoomen, bei dem die UI auf einem kleineren Bildschirmbereich gerendert und dann so skaliert wird, dass sie den verfügbaren Platz auf dem Display ausfüllt. Weitere Informationen zur Screen Support API und den bereitgestellten Steuerelementen finden Sie in den folgenden Abschnitten.

API-Übersicht

APIs zur Unterstützung von Bildschirmen

Mit Android 3.2 werden neue Bildschirme unterstützt, die APIs unterstützen, mit denen Sie mehr Kontrolle darüber haben, wie ihre Anwendungen auf verschiedenen Bildschirmgrößen angezeigt werden. Die API baut auf der vorhandenen API zur Bildschirmunterstützung auf, einschließlich des generalisierten Bildschirmdichtemodells, erweitert sie aber um die Möglichkeit, bestimmte Bildschirmbereiche anhand ihrer Abmessungen präzise auszurichten. Diese werden in dichteunabhängigen Pixeleinheiten (z. B. 600 dp oder 720 dp breit) und nicht anhand ihrer allgemeinen Bildschirmgrößen (z. B. groß oder xgroß) gemessen.

Beim Entwerfen der Benutzeroberfläche einer App können Sie sich immer noch darauf verlassen, dass die Plattform eine Dichteabstraktion bereitstellt. Das bedeutet, dass Anwendungen die Unterschiede in der tatsächlichen Pixeldichte auf den verschiedenen Geräten nicht ausgleichen müssen. Sie können die App-UI so gestalten, dass der verfügbare horizontale oder vertikale Platz ausreicht. Die Plattform gibt die Größe des verfügbaren Platzes mit drei neuen Eigenschaften an: smallestWidth, width und height.

  • Die smallestWidth eines Bildschirms ist die grundlegende Mindestgröße, die in dichteunabhängigen Pixel-Einheiten („dp“) gemessen wird. Von der Höhe oder Breite des Bildschirms ist die kürzere der beiden. Bei einem Bildschirm im Hochformat basiert der Wert "smallestWidth" normalerweise auf seiner Breite, während er im Querformat auf seiner Höhe basiert. In allen Fällen wird „smallestWidth“ aus einer festen Eigenschaft des Bildschirms abgeleitet und der Wert ändert sich unabhängig von der Ausrichtung nicht. Die kleinste Breite ist für Anwendungen wichtig, da sie die kürzeste mögliche Breite darstellt, in der die Anwendungs-UI gezeichnet werden muss, wobei die vom System reservierten Bildschirmbereiche nicht berücksichtigt werden.
  • Im Gegensatz dazu stellen die Breite und Höhe eines Bildschirms den aktuellen horizontalen oder vertikalen Platz dar, der für das Anwendungslayout zur Verfügung steht. Er wird in "dp"-Einheiten gemessen, wobei die vom System reservierten Bildschirmbereiche nicht berücksichtigt werden. Breite und Höhe eines Bildschirms ändern sich, wenn der Nutzer zwischen Quer- und Hochformat wechselt.

Die neue API unterstützt die Anwendungs-UI gemäß der kleinsten Breite des aktuellen Bildschirms. Sie können die Benutzeroberfläche bei Bedarf auch anhand der aktuellen Breite oder Höhe verwalten. Für diese Zwecke bietet die API folgende Tools:

  • Neue Ressourcenqualifizierer für das Targeting von Layouts und anderen Ressourcen bis zu einer minimale Breite, Breite oder Höhe sowie
  • Neue Manifestattribute zum Angeben des maximalen Bildschirmkompatibilitätsbereichs der App

Außerdem können Anwendungen wie in den vorherigen Versionen der Plattform weiterhin das System abfragen und das Laden von UI- und Ressourcen während der Laufzeit verwalten.

Mit der neuen API können Sie Bildschirme direkter auf die Parameter „smallestWidth“, „width“ und „height“ ausrichten. Daher ist es hilfreich, die typischen Eigenschaften der verschiedenen Bildschirmtypen zu kennen. Die folgende Tabelle enthält einige Beispiele, gemessen in „dp“-Einheiten.

Tabelle 1 Typische Geräte mit Dichte und Größe in dp.

Typ Dichte (generalisiert) Abmessungen (dp) kleinster_Breite (dp)
Baseline-Smartphone MDPI 320 × 480 320
Kleines Tablet/großes Smartphone MDPI 480x800 480
7"-Tablet MDPI 600 × 1024 600
10"-Tablet MDPI 800 × 1280 800

In den folgenden Abschnitten finden Sie weitere Informationen zu den neuen Bildschirmqualifizierern und Manifestattributen. Ausführliche Informationen zur Verwendung der Screen Support API findest du unter Unterstützung mehrerer Bildschirme.

Neue Ressourcenkennzeichner für die Bildschirmunterstützung

Mit den neuen Ressourcenqualifizierern in Android 3.2 können Sie Ihre Layouts besser auf bestimmte Bildschirmgrößen ausrichten. Mit den Qualifizierern können Sie Ressourcenkonfigurationen erstellen, die für eine bestimmte minimale kleinste Breite, aktuelle Breite oder aktuelle Höhe definiert sind, gemessen in dichteunabhängigen Pixeln.

Neue Qualifier:

  • swNNNdp: gibt die kleinste kleinste Breite an, für die die Ressource verwendet werden soll, gemessen in dp-Einheiten. Wie bereits erwähnt, ist die „smallestWidth“ eines Bildschirms unabhängig von der Ausrichtung konstant. Beispiele: sw320dp, sw720dp, sw720dp.
  • wNNNdp und hNNNdp: Gibt die minimale Breite oder Höhe an, auf der die Ressource verwendet werden soll, gemessen in "dp"-Einheiten. Wie oben erwähnt, sind Breite und Höhe eines Bildschirms relativ zur Ausrichtung des Bildschirms und ändern sich, wenn sich die Ausrichtung ändert. Beispiele: w320dp, w720dp, h1024dp.

Sie können bei Bedarf auch mehrere sich überschneidende Ressourcenkonfigurationen erstellen. Beispielsweise können Sie einige Ressourcen für die Verwendung auf jedem Bildschirm mit mehr als 480 dp, andere für mehr als 600 dp und andere für mehr als 720 dp taggen. Wenn mehrere Ressourcenkonfigurationen für einen bestimmten Bildschirm qualifiziert sind, wählt das System die Konfiguration mit der größten Übereinstimmung aus. Für eine präzise Kontrolle darüber, welche Ressourcen auf einem bestimmten Bildschirm geladen werden, können Sie Ressourcen mit einem Qualifier taggen oder mehrere neue oder vorhandene Qualifier kombinieren.

Im Folgenden finden Sie einige Beispiele für die Verwendung der neuen Qualifier (basierend auf den zuvor aufgeführten typischen Dimensionen):

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

Ältere Versionen der Plattform ignorieren die neuen Kennzeichner, sodass Sie sie nach Bedarf mischen können, um sicherzustellen, dass Ihre App auf jedem Gerät gut aussieht. Hier einige Beispiele:

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

Ausführliche Informationen zur Verwendung der neuen Qualifier finden Sie unter Neue Größenqualifizierer verwenden.

Neue Manifest-Attribute für Kompatibilität mit Bildschirmgrößen

Das Framework bietet eine neue Gruppe von <supports-screens>-Manifestattributen, mit denen Sie die Unterstützung Ihrer App für unterschiedliche Bildschirmgrößen verwalten können. Insbesondere können Sie die größten und kleinsten Bildschirme angeben, auf denen Ihre App ausgeführt werden soll, sowie den größten Bildschirm, auf dem sie konzipiert wurde, ohne dass der neue Bildschirmkompatibilitätsmodus des Systems erforderlich ist. Wie bei den oben beschriebenen Ressourcenqualifizierern geben die neuen Manifestattribute den Bereich der von der App unterstützten Bildschirme an, wie in „smallestWidth“ angegeben.

Die neuen Manifest-Attribute für die Bildschirmunterstützung sind:

  • android:compatibleWidthLimitDp="numDp": Mit diesem Attribut können Sie die maximale kleinste Breite angeben, auf der die Anwendung ohne Kompatibilitätsmodus ausgeführt werden kann. Wenn der aktuelle Bildschirm größer als der angegebene Wert ist, zeigt das System die Anwendung im normalen Modus an. Der Nutzer kann jedoch über eine Einstellung in der Systemleiste optional in den Kompatibilitätsmodus wechseln.
  • android:largestWidthLimitDp="numDp": Mit diesem Attribut können Sie die maximale kleinste Breite angeben, auf der die Anwendung ausgeführt werden soll. Wenn der aktuelle Bildschirm größer als der angegebene Wert ist, wird die App in den Bildschirmkompatibilitätsmodus versetzt, um die bestmögliche Darstellung auf dem aktuellen Bildschirm zu gewährleisten.
  • android:requiresSmallestWidthDp="numDp": Mit diesem Attribut können Sie die kleinste Breite angeben, auf der die Anwendung ausgeführt werden kann. Wenn der aktuelle Bildschirm kleiner als der angegebene Wert ist, betrachtet das System die Anwendung als nicht kompatibel mit dem Gerät, verhindert aber nicht, dass sie installiert und ausgeführt wird.

Hinweis:Apps werden in Google Play derzeit nicht anhand eines der oben genannten Attribute gefiltert. Die Unterstützung für das Filtern wird in einer späteren Plattformversion hinzugefügt. Anwendungen, die basierend auf der Bildschirmgröße gefiltert werden müssen, können die vorhandenen <supports-screens>-Attribute verwenden.

Ausführliche Informationen zur Verwendung der neuen Attribute finden Sie unter Unterstützung für die Bildschirmgröße angeben.

Bildschirmkompatibilitätsmodus

Android 3.2 bietet einen neuen Bildschirmkompatibilitätsmodus für Anwendungen, die explizit erklären, dass sie keine Bildschirme unterstützen, die so groß sind wie der, auf dem sie ausgeführt werden. Bei diesem neuen Zoommodus wird die App in einem kleineren Bildschirmbereich gerendert. Anschließend werden die Pixel so skaliert, dass sie den aktuellen Bildschirm ausfüllen.

Das System bietet standardmäßig den Bildschirmkompatibilitätsmodus als Nutzeroption für Anwendungen an, die ihn benötigen. Nutzer können den Zoommodus über ein Steuerelement in der Systemleiste aktivieren oder deaktivieren.

Da der neue Bildschirmkompatibilitätsmodus möglicherweise nicht für alle Anwendungen geeignet ist, ermöglicht die Plattform der Anwendung, ihn mithilfe von Manifestattributen zu deaktivieren. Wenn die Funktion von der App deaktiviert ist, bietet das System Nutzern keinen Zoom-Kompatibilitätsmodus als Option, wenn die App ausgeführt wird.

Hinweis:Wichtige Informationen zum Festlegen des Kompatibilitätsmodus in Apps findest du im Artikel Neuer Modus für Apps auf großen Bildschirmen im Blog für Android-Entwickler.

Neue Bildschirmdichte für 720p-Fernseher und ähnliche Geräte

Android 3.2 führt eine neue allgemeine Dichte von tvdpi mit einem ungefähren dpi-Wert von 213 ein, um die Anforderungen von Anwendungen zu erfüllen, die auf 720p-Fernsehern oder ähnlichen Anwendungen mit durchschnittlicher Dichte ausgeführt werden. Die Anwendungen können die neue Dichte in densityDpi abfragen und den neuen Qualifizierer tvdpi verwenden, um Ressourcen für Fernsehgeräte und ähnliche Geräte zu taggen. Beispiele:

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

Im Allgemeinen sollten Anwendungen mit dieser Dichte normalerweise nicht funktionieren. Wenn eine Ausgabe für einen 720p-Bildschirm benötigt wird, können die UI-Elemente automatisch von der Plattform skaliert werden.

UI-Framework

  • Fragmente
    • Die neue Fragment.SavedState-Klasse enthält die Statusinformationen, die über saveFragmentInstanceState() aus einer Fragmentinstanz abgerufen werden.
    • Die neue Methode saveFragmentInstanceState() speichert den aktuellen Instanzstatus des angegebenen Fragments. Der Status kann später beim Erstellen einer neuen Instanz des Fragments verwendet werden, die dem aktuellen Status entspricht.
    • Die neue Methode setInitialSavedState() legt den anfänglichen gespeicherten Status für ein Fragment bei der ersten Erstellung fest.
    • Die neue Callback-Methode onViewCreated() benachrichtigt das Fragment, dass onCreateView() zurückgegeben wurde, aber bevor ein gespeicherter Status in der Ansicht wiederhergestellt wurde.
    • Die Methode isDetached() bestimmt, ob das Fragment explizit von der UI getrennt wurde.
    • Mit den neuen Methoden attach() und detach() kann eine Anwendung Fragmente in der UI neu anhängen oder trennen.
    • Mit der neuen setCustomAnimations()-Überlastmethode können Sie bestimmte Animationsressourcen festlegen, die bei Eingabe-/Exit-Vorgängen und insbesondere beim Aufrufen des Back-Stacks ausgeführt werden sollen. Die bestehende Implementierung berücksichtigt nicht das unterschiedliche Verhalten von Fragmenten beim Pop-up des Back-Stacks.
  • Informationen zur Bildschirmgröße unter ActivityInfo und ApplicationInfo
  • Hilfsprogramme zum Abrufen der Anzeigegröße aus WindowManager
  • Neue öffentliche „holografische“ Stile
    • Auf der Plattform stehen jetzt eine Vielzahl öffentlicher „holographischer“ Stile für Text, Widgets für Aktionsleisten, Tabs und mehr zur Verfügung. Eine vollständige Liste finden Sie unter R.style.
  • LocalActivityManager, ActivityGroup und LocalActivityManager wurden eingestellt
    • Neue Anwendungen sollten anstelle dieser Klassen Fragmente verwenden. Wenn Sie weiterhin mit älteren Versionen der Plattform arbeiten möchten, können Sie die v4 Support Library (Kompatibilitätsbibliothek) verwenden, die im Android SDK verfügbar ist. Die Supportbibliothek für Version 4 enthält eine Version der Fragment API, die bis hinunter zu Android 1.6 (API-Level 4) kompatibel ist.
    • Bei Apps, die für Android 3.0 (API-Level 11) oder höher entwickelt werden, werden Tabs in der Regel mit dem neuen ActionBar.newTab() und zugehörigen APIs in der Benutzeroberfläche angezeigt, um Tabs im Aktionsleistenbereich zu platzieren.

Medienrahmen

  • Apps, die den Medienanbieter der Plattform (MediaStore) verwenden, können Mediendaten jetzt direkt von der austauschbaren SD-Karte lesen, sofern dies vom Gerät unterstützt wird. Anwendungen können über die MTP API auch direkt mit den SD-Kartendateien interagieren.

Grafik

IME-Framework

  • Neue getModifiers()-Methode zum Abrufen des aktuellen Status der Modifikatortasten.

USB-Framework

  • Neue getRawDescriptors()-Methode zum Abrufen der Roh-USB-Deskriptoren für das Gerät. Sie können diese Methode verwenden, um auf Deskriptoren zuzugreifen, die nicht direkt über die übergeordneten APIs unterstützt werden.

Netz

Telefonie

Kerndienstprogramme

  • Fachkräfte für öffentliche Verkehrsmittel
  • Binder und IBinder
    • Mit der neuen Methode dumpAsync() in Binder und IBinder können Anwendungen Daten in eine angegebene Datei übertragen und so dafür sorgen, dass das Ziel asynchron ausgeführt wird.
    • Mit dem neuen IBinder-Protokoll-Transaktionscode TWEET_TRANSACTION können Anwendungen einen Tweet an das Zielobjekt senden.

Neue Featurekonstanten

Die Plattform fügt neue Konstanten für Hardwarefunktionen hinzu, die Sie in ihren Anwendungsmanifesten deklarieren können, um externe Entitäten wie Google Play über die erforderlichen Hardware- und Softwarefunktionen zu informieren. Diese und andere Featurekonstanten werden in <uses-feature>-Manifestelementen deklariert.

Google Play filtert Apps anhand ihrer <uses-feature>-Attribute, damit sie nur auf Geräten verfügbar sind, auf denen ihre Anforderungen erfüllt sind.

  • Funktionskonstanten für Anforderungen im Quer- oder Hochformat

    In Android 3.2 werden neue Funktionskonstanten eingeführt, mit denen Anwendungen festlegen können, ob sie im Querformat, im Hochformat oder in beidem angezeigt werden müssen. Die Deklarierung dieser Konstanten bedeutet, dass die App nicht auf einem Gerät installiert werden darf, das nicht die entsprechende Ausrichtung bietet. Wenn dagegen eine oder beide Konstanten nicht deklariert sind, weist dies darauf hin, dass die Anwendung keine Präferenz für die nicht angegebenen Ausrichtungen hat und möglicherweise auf einem Gerät installiert wird, das diese Konstanten nicht unterstützt.

    Für eine typische Anwendung, die sowohl im Quer- als auch im Hochformat ordnungsgemäß funktioniert, muss normalerweise keine Ausrichtungsanforderung angegeben werden. Stattdessen könnte eine App, die primär für eine Ausrichtung entwickelt wurde, z. B. eine App für einen Fernseher, eine der Konstanten angeben, um sicherzustellen, dass sie nicht für Geräte ohne diese Ausrichtung verfügbar ist.

    Wenn in der Manifestanfrage mithilfe des Attributs android:screenOrientation Aktivitäten in einer bestimmten Ausrichtung ausgeführt werden, wird dadurch ebenfalls deklariert, dass die App diese Ausrichtung erfordert.

  • Weitere Featurekonstanten

Bericht zu API-Unterschieden

Eine detaillierte Ansicht aller API-Änderungen in Android 3.2 (API-Level 13) findest du im API-Unterschiedsbericht.

API-Ebene

Die Plattform Android 3.2 stellt eine aktualisierte Version der Framework API bereit. Der Android 3.2 API wird eine Ganzzahl-ID (13) zugewiesen, die im System selbst gespeichert ist. Mit dieser Kennung (API-Ebene) kann das System vor der Installation korrekt feststellen, ob eine App mit dem System kompatibel ist.

Um in Android 3.2 eingeführte APIs in Ihrer App zu verwenden, müssen Sie die App mithilfe der Android-Bibliothek kompilieren, die auf der Android 3.2 SDK-Plattform bereitgestellt wird. Je nach deinen Anforderungen musst du dem <uses-sdk>-Element im Manifest der Anwendung möglicherweise auch ein android:minSdkVersion="13"-Attribut hinzufügen.

Weitere Informationen finden Sie unter Was ist das API-Level?