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.
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
undhNNNdp
: 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 übersaveFragmentInstanceState()
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, dassonCreateView()
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()
unddetach()
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.
- Die neue
- Informationen zur Bildschirmgröße unter ActivityInfo und ApplicationInfo
ActivityInfo
fügtCONFIG_SCREEN_SIZE
undCONFIG_SMALLEST_SCREEN_SIZE
als Bitmasken inconfigChanges
hinzu. Die Bits geben an, ob eine Activity die Bildschirmgröße und die kleinste Bildschirmgröße selbst verarbeiten kann.ApplicationInfo
fügt die FelderlargestWidthLimitDp
,compatibleWidthLimitDp
undrequiresSmallestWidthDp
hinzu, die von den entsprechenden<supports-screens>
-Attributen in der Manifestdatei der Anwendung abgeleitet werden.
- Hilfsprogramme zum Abrufen der Anzeigegröße aus WindowManager
- Mit den neuen Methoden
getSize()
undgetRectSize()
können Anwendungen die Rohgröße der Anzeige abrufen.
- Mit den neuen Methoden
- 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
.
- 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
LocalActivityManager
,ActivityGroup
undLocalActivityManager
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
- Parcelable Serviceleistungen in Point und PointF
- Die Klassen
Point
undPointF
enthalten jetzt die SchnittstelleParcelable
und die DienstprogrammmethodendescribeContents()
,readFromParcel()
undwriteToParcel()
.
- Die Klassen
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
- Netzwerktypkonstanten
ConnectivityManager
addiert die KonstantenTYPE_ETHERNET
undTYPE_BLUETOOTH
.
Telefonie
- Neue Konstante für den Netzwerktyp
NETWORK_TYPE_HSPAP
.
Kerndienstprogramme
- Fachkräfte für öffentliche Verkehrsmittel
- Die neue Schnittstelle
Parcelable.ClassLoaderCreator
ermöglicht der Anwendung, den ClassLoader zu empfangen, in dem das Objekt erstellt wird. - Neue
adoptFd
,dup()
undfromFd()
zum Verwalten vonParcelFileDescriptor
-Objekten.
- Die neue Schnittstelle
- Binder und IBinder
- Mit der neuen Methode
dumpAsync()
inBinder
undIBinder
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-TransaktionscodeTWEET_TRANSACTION
können Anwendungen einen Tweet an das Zielobjekt senden.
- Mit der neuen Methode
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.
android.hardware.screen.landscape
: Die Anwendung erfordert die Anzeige im Querformat.android.hardware.screen.portrait
: Die Anwendung erfordert die Anzeige im Hochformat.
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
android.hardware.faketouch.multitouch.distinct
: Die Anwendung erfordert Unterstützung für die emulierte Mulitouch-Eingabe mit separater Verfolgung von zwei oder mehr Punkten.android.hardware.faketouch.multitouch.jazzhand
: Die Anwendung erfordert Unterstützung für die emulierte Mulitouch-Eingabe mit einem eindeutigen Tracking von fünf oder mehr Punkten.
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?