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 bietet. In den folgenden Abschnitten erhalten Sie einen Überblick über die neuen Funktionen und Entwickler-APIs.

Für Entwickler ist die Android 3.2-Plattform als Komponente zum Herunterladen für das Android SDK verfügbar. Die herunterladbare Plattform umfasst eine Android-Bibliothek und ein System-Image sowie eine Reihe von Emulator-Skins und mehr. Wenn Sie mit der Entwicklung oder dem Testen für Android 3.2 beginnen möchten, laden Sie die Plattform mit dem Android SDK Manager in Ihr SDK herunter.

Plattform-Highlights

Neue Nutzerfunktionen

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

    Android 3.2 enthält eine Vielzahl von Optimierungen im gesamten System, um eine hervorragende Nutzererfahrung auf einer breiteren Palette von Tablet-Geräten zu ermöglichen.

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

    Mit Android 3.2 wird ein neuer Kompatibilitätszoom eingeführt, mit dem Nutzer Apps mit fester Größe auf größeren Geräten anzeigen können. Der neue Modus bietet eine Pixel-skalierte Alternative zum standardmäßigen UI-Stretching für Apps, die nicht für die Ausführung auf größeren Bildschirmen entwickelt wurden, z. B. auf Tablets. Der neue Modus ist für Nutzer über ein Menüsymbol in der Systemleiste zugänglich. Er ist für Apps gedacht, die Kompatibilitätsunterstützung benötigen.

  • Mediensynchronisierung über SD-Karte

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

Neue Entwicklerfunktionen

  • Erweiterte API zur Verwaltung von Bildschirmen

    Mit Android 3.2 werden Erweiterungen für die Bildschirmunterstützungs-API der Plattform eingeführt, um Entwicklern zusätzliche Möglichkeiten zur Verwaltung der App-Benutzeroberfläche auf allen Android-Geräten zu bieten. Die API enthält neue Ressourcenqualifizierer und neue 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.

    Um für Apps mit fester Größe und Apps mit eingeschränkter Unterstützung für verschiedene Bildschirmgrößen die bestmögliche Darstellung zu ermöglichen, bietet die Plattform auch einen neuen Zoom-Kompatibilitätsmodus, bei dem die Benutzeroberfläche auf einem kleineren Bildschirmbereich gerendert und dann so skaliert wird, dass sie den gesamten verfügbaren Displaybereich ausfüllt. Weitere Informationen zur Screen Support API und den zugehörigen Steuerelementen finden Sie in den folgenden Abschnitten.

API-Übersicht

Screens Support APIs

Android 3.2 bietet neue APIs zur Unterstützung von Bildschirmen, mit denen Sie mehr Kontrolle darüber haben, wie Ihre Apps auf verschiedenen Bildschirmgrößen angezeigt werden. Die API baut auf der vorhandenen API zur Bildschirmunterstützung auf, einschließlich des allgemeinen Bildschirmdichtemodells der Plattform. Sie wird jedoch um die Möglichkeit erweitert, genau auf bestimmte Bildschirmbereiche nach ihren Abmessungen (gemessen in dichteunabhängigen Pixeleinheiten wie 600 dp oder 720 dp Breite) und nicht nach ihren allgemeinen Bildschirmgrößen (z. B. „large“ oder „xlarge“) auszurichten.

Beim Entwerfen der Benutzeroberfläche einer Anwendung können Sie weiterhin darauf vertrauen, dass die Plattform eine Density Abstraction bietet. Das bedeutet, dass Anwendungen die Unterschiede in der tatsächlichen Pixeldichte zwischen Geräten nicht ausgleichen müssen. Sie können die Benutzeroberfläche der Anwendung entsprechend dem verfügbaren horizontalen oder vertikalen Platz gestalten. Die Plattform gibt den verfügbaren Platz mit drei neuen Eigenschaften an: smallestWidth, width und height.

  • Die smallestWidth eines Displays ist seine grundlegende Mindestgröße, gemessen in dichteunabhängigen Pixeln („dp“). Die kürzere der beiden Bildschirmhöhen oder -breiten. Bei einem Bildschirm im Hochformat basiert die kleinste Breite normalerweise auf der Breite, während sie im Querformat auf der Höhe basiert. In allen Fällen wird „smallestWidth“ aus einer festen Eigenschaft des Displays abgeleitet und der Wert ändert sich unabhängig von der Ausrichtung nicht. „smallestWidth“ ist für Anwendungen wichtig, da sie die kürzeste Breite darstellt, in der die Benutzeroberfläche der Anwendung dargestellt werden muss, ohne die vom System reservierten Bildschirmbereiche.
  • Die Breite und Höhe eines Bildschirms geben dagegen den aktuellen horizontalen oder vertikalen Bereich an, der für das App-Layout verfügbar ist. Dieser wird in „dp“ gemessen und schließt nicht die vom System reservierten Bildschirmbereiche ein. Breite und Höhe eines Bildschirms ändern sich, wenn der Nutzer die Ausrichtung zwischen Quer- und Hochformat wechselt.

Mit der neuen API zur Bildschirmunterstützung können Sie die Benutzeroberfläche der Anwendung entsprechend der smallestWidth des aktuellen Bildschirms verwalten. Sie können die Benutzeroberfläche auch entsprechend 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 auf eine minimale smallestWidth, width oder height
  • Neue Manifestattribute, mit denen der maximale Bildschirmkompatibilitätsbereich der App angegeben werden kann

Darüber hinaus können Anwendungen weiterhin das System abfragen und das Laden von UI und Ressourcen zur Laufzeit verwalten, wie in den vorherigen Versionen der Plattform.

Da Sie mit der neuen API über „smallestWidth“, „width“ und „height“ direkter auf Bildschirme abzielen können, ist es hilfreich, die typischen Merkmale der verschiedenen Bildschirmtypen zu kennen. In der folgenden Tabelle finden Sie einige Beispiele, die in „dp“ gemessen werden.

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

Eingeben Dichte (allgemein) Abmessungen (dp) smallestWidth (dp)
Baseline-Telefon mdpi 320 × 480 320
Kleines Tablet/großes Smartphone mdpi 480 × 800 480
7"-Tablet mdpi 600 × 1024 600
10"-Tablet mdpi 800 x 1280 800

In den folgenden Abschnitten finden Sie weitere Informationen zu den neuen Bildschirmqualifizierern und Manifestattributen. Ausführliche Informationen zur Verwendung der API zur Bildschirmunterstützung finden Sie unter Mehrere Bildschirme unterstützen.

Neue Ressourcenqualifikationen für die Unterstützung von Bildschirmen

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

Die neuen Einschränkungen sind:

  • swNNNdp: Gibt die minimale smallestWidth an, bei der 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 Mindestbreite oder -höhe an, in der die Ressource verwendet werden soll, gemessen in "dp"-Einheiten. Wie bereits erwähnt, sind Breite und Höhe eines Bildschirms relativ zur Bildschirmausrichtung und ändern sich, wenn sich die Ausrichtung ändert. Beispiele: w320dp, w720dp, h1024dp.

Bei Bedarf können Sie auch mehrere sich überschneidende Ressourcenkonfigurationen erstellen. Sie können beispielsweise einige Ressourcen für die Verwendung auf allen Bildschirmen mit einer Breite von mehr als 480 dp, andere für Bildschirme mit einer Breite von mehr als 600 dp und andere für Bildschirme mit einer Breite von mehr als 720 dp taggen. Wenn für einen bestimmten Bildschirm mehrere Ressourcenkonfigurationen infrage kommen, wählt das System die Konfiguration aus, die am besten passt. Wenn Sie genau festlegen möchten, welche Ressourcen auf einem bestimmten Bildschirm geladen werden, können Sie Ressourcen mit einem Qualifier taggen oder mehrere neue oder vorhandene Qualifier kombinieren.

Hier sind einige Beispiele dafür, wie Sie die neuen Einschränkungen auf Grundlage der oben aufgeführten typischen Dimensionen verwenden können:

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

In älteren Versionen der Plattform werden die neuen Qualifier ignoriert. Sie können sie also nach Bedarf kombinieren, damit Ihre App auf allen Geräten 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 Qualifikatoren finden Sie unter Neue Qualifikatoren für die Größe verwenden.

Neue Manifest-Attribute für die Bildschirmgrößenkompatibilität

Das Framework bietet neue <supports-screens>-Manifestattribute, mit denen du die Unterstützung deiner App für verschiedene Bildschirmgrößen verwalten kannst. Sie können insbesondere den größten und kleinsten Bildschirm angeben, auf dem Ihre App ausgeführt werden soll, sowie den größten Bildschirm, auf dem sie ohne den neuen Bildschirmkompatibilitätsmodus des Systems ausgeführt werden soll. Wie bei den oben beschriebenen Ressourcenqualifizierern geben die neuen Manifestattribute den Bereich der von der Anwendung unterstützten Bildschirme an, der mit der kleinsten Breite angegeben wird.

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

  • android:compatibleWidthLimitDp="numDp": Mit diesem Attribut können Sie die maximale smallestWidth angeben, bei der die Anwendung ohne Kompatibilitätsmodus ausgeführt werden kann. Wenn das aktuelle Display größer als der angegebene Wert ist, zeigt das System die Anwendung im Normalmodus an, ermöglicht dem Nutzer aber optional den Wechsel in den Kompatibilitätsmodus über eine Einstellung in der Systemleiste.
  • android:largestWidthLimitDp="numDp": Mit diesem Attribut können Sie die maximale smallestWidth angeben, bei der die Anwendung ausgeführt werden soll. Wenn der aktuelle Bildschirm größer als der angegebene Wert ist, erzwingt das System die Anwendung in den Bildschirmkompatibilitätsmodus, um eine optimale Anzeige auf dem aktuellen Bildschirm zu gewährleisten.
  • android:requiresSmallestWidthDp="numDp": Mit diesem Attribut können Sie die Mindestbreite angeben, bei der die Anwendung ausgeführt werden kann. Wenn der aktuelle Bildschirm kleiner als der angegebene Wert ist, betrachtet das System die Anwendung als mit dem Gerät inkompatibel, verhindert aber nicht, dass sie installiert und ausgeführt wird.

Hinweis:Bei Google Play werden Apps derzeit nicht anhand der oben genannten Attribute gefiltert. Die Filterung wird in einer späteren Plattformversion hinzugefügt. Für Anwendungen, die nach der Bildschirmgröße gefiltert werden müssen, können die vorhandenen <supports-screens>-Attribute verwendet werden.

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

Bildschirmkompatibilitätsmodus

Android 3.2 bietet einen neuen Bildschirmkompatibilitätsmodus für Apps, die explizit angeben, dass sie keine Bildschirme so groß wie das unterstützen, auf dem sie ausgeführt werden. Dieser neue „Zoom“-Modus ist pixelbasiert. Die Anwendung wird in einem kleineren Bildschirmbereich gerendert und dann werden die Pixel so skaliert, dass sie den aktuellen Bildschirm füllen.

Standardmäßig bietet das System den Bildschirmkompatibilitätsmodus als Nutzeroption für Apps an, die ihn erfordern. Nutzer können den Zoommodus über ein Steuerelement in der Systemleiste aktivieren und deaktivieren.

Da der neue Bildschirmkompatibilitätsmodus möglicherweise nicht für alle Apps geeignet ist, können Entwickler ihn über Manifestattribute deaktivieren. Wenn die Funktion von der App deaktiviert wird, bietet das System Nutzern, während die App ausgeführt wird, keine Option für den Kompatibilitätsmodus „Zoom“ an.

Hinweis:Wichtige Informationen dazu, wie Sie den Kompatibilitätsmodus in Ihren Anwendungen steuern, finden Sie im Artikel Neuer Modus für Apps auf großen Bildschirmen im Android Developers Blog.

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

Um den Anforderungen von Anwendungen gerecht zu werden, die auf 720p-Fernsehern oder ähnlichen Geräten mit Bildschirmen mittlerer Dichte ausgeführt werden, wird in Android 3.2 eine neue allgemeine Dichte, tvdpi, mit einer ungefähren Auflösung von 213 dpi eingeführt. Apps können in densityDpi nach der neuen Dichte fragen und mit dem neuen tvdpi-Qualifikator Ressourcen für Fernseher und ähnliche Geräte taggen. Beispiel:

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

Im Allgemeinen sollten Anwendungen nicht mit dieser Dichte arbeiten müssen. In Situationen, in denen die Ausgabe für einen 720p-Bildschirm erforderlich ist, 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 wurden.
    • 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 Erstellung fest.
    • Die neue onViewCreated()-Rückrufmethode benachrichtigt das Fragment, dass onCreateView() zurückgekehrt ist, aber bevor ein gespeicherter Status in der Ansicht wiederhergestellt wurde.
    • Die Methode isDetached() gibt an, ob das Fragment explizit von der Benutzeroberfläche getrennt wurde.
    • Mit den neuen Methoden attach() und detach() kann eine Anwendung Fragmente über die Benutzeroberfläche neu anhängen oder trennen.
    • Mit einer neuen Überladungsmethode für setCustomAnimations() können Sie bestimmte Animationsressourcen für Eintritts-/Austrittsvorgänge festlegen, insbesondere beim Aufheben des Rückstapels. Die aktuelle Implementierung berücksichtigt nicht das unterschiedliche Verhalten von Fragmenten beim Entfernen des Rückstapels.
  • Informationen zur Bildschirmgröße in ActivityInfo und ApplicationInfo
  • Hilfsfunktionen zum Abrufen der Displaygröße von WindowManager
  • Neue öffentliche „holografische“ Stile
    • Die Plattform bietet jetzt eine Vielzahl öffentlicher „holografischer“ Stile für Text, Actionbar-Widgets und Tabs. Eine vollständige Liste findest du unter R.style.
  • LocalActivityManager, ActivityGroup und LocalActivityManager werden eingestellt
    • Für neue Anwendungen sollten anstelle dieser Klassen Fragmente verwendet werden. Wenn Sie die App weiterhin auf älteren Versionen der Plattform ausführen möchten, können Sie die Support-Bibliothek (Kompatibilitätsbibliothek) v4 verwenden, die im Android SDK verfügbar ist. Die Support Library v4 bietet eine Version der Fragment API, die bis Android 1.6 (API-Ebene 4) kompatibel ist.
    • Bei Apps, die für Android 3.0 (API-Level 11) oder höher entwickelt werden, werden Tabs in der Benutzeroberfläche in der Regel mithilfe der neuen ActionBar.newTab() und der zugehörigen APIs für das Platzieren von Tabs im Bereich der Aktionsleiste dargestellt.

Medien-Framework

  • Apps, die den Medienanbieter der Plattform (MediaStore) verwenden, können jetzt Mediendaten direkt von der herausnehmbaren SD-Karte lesen, sofern dies vom Gerät unterstützt wird. Anwendungen können auch direkt über die MTP API 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-Beschreibungen für das Gerät. Sie können die Methode verwenden, um auf Deskriptoren zuzugreifen, die nicht direkt über die übergeordneten APIs unterstützt werden.

Netz

Telefonie

Wichtige Dienstprogramme

  • Paketierbare Versorgungsunternehmen
  • 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-Protokolltransaktionscode TWEET_TRANSACTION können Anwendungen einen Tweet an das Zielobjekt senden.

Neue Funktionskonstanten

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

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

  • Funktionskonstanten für Anforderungen an das Quer- oder Hochformat

    Android 3.2 führt neue Funktionskonstanten ein, mit denen Apps angeben können, ob eine Anzeige im Querformat, im Hochformat oder in beidem erforderlich ist. Wenn Sie diese Konstanten deklarieren, wird damit angegeben, dass die Anwendung nicht auf einem Gerät installiert werden darf, das die entsprechende Ausrichtung nicht bietet. Wenn eine oder beide Konstanten nicht deklariert sind, hat die Anwendung keine Präferenz für die nicht deklarierten Ausrichtungen und kann auf einem Gerät installiert werden, das diese nicht bietet.

    Für eine typische Anwendung, die sowohl im Quer- als auch im Hochformat ordnungsgemäß funktioniert, muss normalerweise keine Ausrichtungsanforderung deklariert werden. Vielmehr kann eine Anwendung, die hauptsächlich für eine bestimmte Ausrichtung entwickelt wurde, z. B. eine App für einen Fernseher, eine der Konstanten deklarieren, um sicherzustellen, dass sie für Geräte, die diese Ausrichtung nicht bieten, nicht verfügbar ist.

    Wenn für eine der im Manifest deklarierten Aktivitäten die Ausführung in einer bestimmten Ausrichtung mithilfe des Attributs android:screenOrientation angefordert wird, wird dadurch auch deklariert, dass die App diese Ausrichtung erfordert.

  • Weitere Merkmalskonstanten

Bericht zu API-Unterschieden

Eine detaillierte Übersicht über alle API-Änderungen in Android 3.2 (API-Level 13) finden Sie im Bericht zu API-Unterschieden.

API-Ebene

Die Android 3.2-Plattform bietet eine aktualisierte Version der Framework API. Der Android 3.2 API wird eine ganzzahlige Kennung (13) zugewiesen, die im System selbst gespeichert ist. Anhand dieser Kennung, der sogenannten API-Ebene, kann das System vor der Installation einer Anwendung korrekt feststellen, ob sie mit dem System kompatibel ist.

Wenn Sie in Ihrer Anwendung APIs verwenden möchten, die in Android 3.2 eingeführt wurden, müssen Sie die Anwendung mit der Android-Bibliothek kompilieren, die in der Android 3.2 SDK-Plattform bereitgestellt wird. Je nach Bedarf müssen Sie dem <uses-sdk>-Element im Manifest der Anwendung möglicherweise auch ein android:minSdkVersion="13"-Attribut hinzufügen.

Weitere Informationen finden Sie im Hilfeartikel Was ist die API-Ebene?