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 der neuen Funktionen und Entwickler-APIs.

Für Entwickler ist die Android 3.2-Plattform als herunterladbare Komponente für das Android SDK verfügbar. Die herunterladbare Plattform umfasst eine Android-Bibliothek und ein System-Image sowie eine Reihe von Emulator-Skins mehr. Um mit der Entwicklung oder Tests für Android 3.2 zu beginnen, Verwenden Sie den Android SDK Manager, um die Plattform in Ihr SDK herunterzuladen.

Highlights der Plattform

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 optimale 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ätszoom eingeführt, mit dem Nutzer Apps mit fester Größe auf größeren Geräten anzeigen können. Der neue Modus bietet eine pixelgenaue Alternative zur Standard-UI-Dehnung für Apps, die nicht für größere Bildschirme wie Tablets entwickelt wurden. 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 Systemeinrichtung erstellt die Dateien, für Apps aus dem System-Medienspeicher zugänglich sind.

Neue Funktionen für Entwickler

  • Unterstützung der erweiterten API für die Verwaltung von Bildschirmen

    Mit Android 3.2 werden Erweiterungen der Screen Support API der Plattform eingeführt, geben Entwicklern zusätzliche Möglichkeiten zur Verwaltung von Anwendungs-UI für eine Reihe von Android-Mobilgeräte Die API enthält neue Ressourcenqualifizierer und neue Manifest-Attribute zu, mit denen Sie genauer steuern können, wie Ihre Apps in unterschiedlichen Größen dargestellt werden, anstatt auf generalisierten Größenkategorien.

    Um die bestmögliche Anzeige für Apps mit fester Größe und Apps mit eingeschränkter verschiedene Bildschirmgrößen unterstützt, bietet die Plattform auch einen neuen Zoom Kompatibilitätsmodus, der die UI auf einem kleineren Bildschirmbereich rendert und sie dann skaliert um den verfügbaren Platz auf dem Display zu füllen. 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 Screens-Support-API auf, einschließlich der allgemeines Bildschirmdichtemodell, erweitert es aber um die Möglichkeit, die Ausrichtung auf bestimmte Bildschirmbereiche anhand ihrer Abmessungen, gemessen in dichteunabhängige Pixeleinheiten (z. B. 600 dp oder 720 dp Breite) anstelle von nach der allgemeinen Bildschirmgröße (wie groß oder xlarge)

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 zeigt den verfügbaren Speicherplatz anhand von drei neuen Eigenschaften: 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 Display im Hochformat basiert „smallestWidth“ normalerweise auf der Breite, während es 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. Die 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.
  • Im Gegensatz dazu stellen Breite und Höhe eines Bildschirms den Derzeitiger horizontaler oder vertikaler Platz, der für das Anwendungslayout verfügbar ist, gemessen in „dp“ mit Ausnahme der vom System reservierten Bildschirmbereiche. Die Breite und Die Höhe eines Bildschirms ändert sich, wenn der Nutzer zwischen der Ausrichtung und dem Querformat wechselt. und Hochformat.

Mit der neuen Screens Support API können Sie die Anwendungs-UI verwalten gemäß der kleinsten Breite des aktuellen Bildschirms ein. Sie können auch die je nach Bedarf an die aktuelle Breite oder Höhe anpassen. Für diese Zwecke kann die API bietet folgende Tools:

  • Neue Ressourcenqualifizierer für das Targeting von Layouts und anderen Ressourcen auf eine minimale smallestWidth, width oder height
  • Neue Manifestattribute zur Angabe des App-Höchstwerts Bildschirmkompatibilitätsbereich

Darüber hinaus können Anwendungen weiterhin das System abfragen und Benutzeroberflächen- und wie in den vorherigen Versionen der Plattform während der Laufzeit geladen wird.

Da Sie mit der neuen API Bildschirme über „smallestWidth“ direkter als Breite und Höhe, ist es hilfreich, die typischen die Eigenschaften der verschiedenen Bildschirmtypen. In der folgenden Tabelle finden Sie einige Beispiele, die in „dp“ gemessen werden.

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

Eingeben Dichte (allgemein) Abmessungen (dp) miniestWidth (dp)
Baseline-Telefonnummer 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 Bildschirmqualifikationen und Manifest-Attributen. Ausführliche Informationen zur Verwendung des Bildschirms Support-API erhalten Sie unter Unterstützung mehrerer Bildschirme:

Unterstützung neuer Ressourcenqualifizierer für Bildschirme

Mit den neuen Ressourcenqualifizierern in Android 3.2 können Sie Ihre Layouts besser ausrichten. für verschiedene Bildschirmgrößen. Mit den Kennzeichnern können Sie Ressourcen Konfigurationen für eine bestimmte minimale kleinste Breite, aktuelle Breite oder aktuelle Höhe, gemessen in dichteunabhängigen Pixeln.

Die neuen Einschränkungen sind:

  • swNNNdp: Gibt die kleinste kleinste Breite an, auf der die zu verwendende Ressource, gemessen in „dp“ Einheiten. Wie bereits erwähnt, Die kleinste Breite des Bildschirms ist unabhängig von der Ausrichtung konstant. Beispiele: sw320dp, sw720dp, sw720dp.
  • wNNNdp und hNNNdp: Gibt das Minimum an Breite oder Höhe, für die die Ressource verwendet werden soll, in „dp“ Einheiten. Wie bereits 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. Du könntest beispielsweise Ressourcen taggen, damit sie auf Geräten verwendet werden können, die breiter als 480 sind. dp, andere breiter als 600 dp und andere breiter als 720 dp. 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 sind 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 Kennzeichner finden Sie unter Neue Kennzeichner verwenden Größenqualifizierer.

Neue Manifestattribute für die Bildschirmgrößenkompatibilität

Das Framework bietet eine neue Reihe von <supports-screens>-Manifestattributen, mit denen Sie die Unterstützung Ihrer App für verschiedene Bildschirmgrößen verwalten können. Sie können die größten und kleinsten Bildschirme angeben, auf denen Ihre App und auf dem größten Bildschirm, auf dem sie ausgeführt werden kann, ohne den neuen Bildschirm des Systems Kompatibilitätsmodus. Ähnlich wie die oben beschriebenen Ressourcenqualifizierer geben die neuen Manifestattribute den Bereich der Bildschirme an, die von der Anwendung unterstützt werden, wie durch „smallestWidth“ angegeben.

Die neuen Manifestattribute 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. Ist der aktuelle Bildschirm größer als angegebenen Wert hat, zeigt das System die Anwendung im normalen Modus an, können Nutzer optional über eine Einstellung in Systemleiste.
  • android:largestWidthLimitDp="numDp" – Dies können Sie die kleinste kleinste Breite angeben, auf der die App ausgeführt werden kann. Ist der aktuelle Bildschirm größer als der angegebene Wert, zwingt das System die App in den Bildschirmkompatibilitätsmodus, Anzeige auf dem aktuellen Bildschirm.
  • android:requiresSmallestWidthDp="numDp": Mit diesem Attribut können Sie die Mindestbreite angeben, bei der die Anwendung ausgeführt werden kann. Ist der aktuelle Bildschirm kleiner als der angegebene Wert, zeigt das System betrachtet die App als nicht mit dem Gerät kompatibel, verhindert dies jedoch nicht installiert und ausgeführt werden.

Hinweis: Bei Google Play werden Apps derzeit nicht anhand der oben genannten Attribute gefiltert. Unterstützung für Filter die in einer späteren Plattformversion hinzugefügt wird. Für Anwendungen, bei denen eine Filterung nach Bildschirmgröße erforderlich ist, können die vorhandenen <supports-screens>-Attribute verwendet werden.

Ausführliche Informationen zur Verwendung der neuen Attribute finden Sie unter Angeben von Bildschirmgrößen unterstützen.

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, für die er erforderlich ist. 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 Zoom-Kompatibilitätsmodus an.

Hinweis:Wichtige Informationen dazu, wie Sie lesen Sie den Artikel Neuer Modus für Apps auf großen Bildschirmen in der Android-App Developers-Blog.

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

Um die Anforderungen von Anwendungen zu erfüllen, die auf 720p-Fernsehern oder ähnlichen Geräten ausgeführt werden, Bildschirm mit mittlerer Dichte, bietet Android 3.2 eine neue tvdpi mit einer ungefähren DPI von 213. Anwendungen können abfragen nach neue Dichte in densityDpi und kann den neuen Qualifizierer tvdpi zum Taggen von Ressourcen für Fernsehgeräte und ähnlichen Geräten. Beispiel:

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

Im Allgemeinen sollten Anwendungen nicht mit dieser Dichte arbeiten müssen. Wenn die Ausgabe für ein 720p-Display erforderlich ist, können die UI-Elemente von der Plattform automatisch skaliert werden.

UI-Framework

  • Fragmente
    • Die neue Fragment.SavedState-Klasse enthält die Statusinformationen, die über saveFragmentInstanceState() aus einer Fragmentinstanz abgerufen wurden.
    • Neue Methode saveFragmentInstanceState() speichert den aktuellen Instanzstatus das angegebene Fragment. Der Status kann später beim Erstellen einer neuen Instanz verwendet werden des Fragments, das dem aktuellen Status entspricht.
    • Mit der neuen Methode setInitialSavedState() wird der ursprüngliche gespeicherte Status für ein Fragment beim ersten Erstellen festgelegt.
    • Die neue Callback-Methode onViewCreated() benachrichtigt das Fragment, onCreateView() wurde zurückgegeben, aber bevor ein gespeicherter Status in der Ansicht wiederhergestellt wird.
    • Die Methode isDetached() gibt an, ob das Fragment explizit von der Benutzeroberfläche getrennt wurde.
    • Mit den neuen Methoden attach() und detach() können Fragmente in der Benutzeroberfläche wieder angehängt oder getrennt werden.
    • Mit der neuen setCustomAnimations()-Überlastmethode können Sie bestimmte Animationen Ressourcen, die für Ein- und Beendigungsvorgänge ausgeführt werden, und insbesondere, wenn um den Back Stack zu knacken. Bei der bestehenden Implementierung werden für das unterschiedliche Verhalten von Fragmenten beim Drücken des Back-Stacks.
  • 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. Weitere Informationen finden Sie unter R.style für eine vollständige Liste.
  • LocalActivityManager, ActivityGroup und LocalActivityManager wurden jetzt eingestellt
    • Für neue Anwendungen sollten anstelle dieser Klassen Fragmente verwendet werden. Bis auf älteren Versionen der Plattform ausgeführt werden, können Sie den Support für Version 4 Bibliothek (Kompatibilitätsbibliothek), die im Android SDK verfügbar ist. Der v4-Support Die Bibliothek stellt eine Version der Fragment API bereit, die bis zu Android 1.6 (API-Level 4)
    • 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

  • Anwendungen, die den Medienanbieter der Plattform (MediaStore) verwenden, können Mediendaten jetzt direkt aus dem SD-Karte, 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 für den aktuellen Status der Modifikatortasten abrufen.

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 APIs der höheren Ebene unterstützt werden.

Netz

Telefonie

Hauptdienstprogramme

  • Paketierbare Versorgungsunternehmen
  • Binder und IBinder
    • Neue Methode dumpAsync() in Binder und IBinder können Anwendungen Dump in eine angegebene Datei. Dadurch wird sichergestellt, dass das Ziel asynchron ausgeführt wird.
    • Mit dem neuen IBinder-Protokoll-Transaktionscode TWEET_TRANSACTION können Anwendungen einen Tweet senden an das Zielobjekt übergeben.

Konstanten für neue Funktionen

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. Sie deklarieren diese und andere Funktionskonstanten 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 jeweiligen Anforderungen erfüllt sind.

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

    In Android 3.2 wurden neue Funktionskonstanten eingeführt, 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 dagegen eine oder beide Konstanten nicht angegeben sind, weist dies darauf hin, dass die App keine Präferenz für nicht angegebene Ausrichtungen hat und möglicherweise auf einem Gerät installiert wird, das diese nicht unterstützt.

    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 in der Manifestanfrage für eine Aktivität angegeben ist, dass sie mit dem Attribut android:screenOrientation in einer bestimmten Ausrichtung ausgeführt wird, wird damit auch angegeben, dass die Anwendung diese Ausrichtung erfordert.

  • Andere Merkmalskonstanten

Bericht zu API-Unterschieden

Eine detaillierte Ansicht aller API-Änderungen unter Android 3.2 (API) Ebene 13), siehe API Bericht zu Unterschieden

API-Level

Die Android 3.2-Plattform liefert eine aktualisierte Version die Framework-API. Der Android 3.2 API wird eine Ganzzahl-ID zugewiesen – 13 –, die im System selbst gespeichert wird. 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 unter Was ist die API-Ebene?