API-Level:13
Android 3.2 (HONEYCOMB_MR2
) ist ein inkrementeller Plattformrelease, der neue
Funktionen für Nutzer und Entwickler. In den folgenden Abschnitten erhalten Sie einen Überblick
der neuen Funktionen und Entwickler-APIs.
Für Entwickler ist die Android 3.2-Plattform als Komponente für das Android SDK herunterladen 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 Funktionen für Nutzer
- Optimierungen für eine breitere Palette von 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 wurde ein neuer Kompatibilitäts-Zoom eingeführt, mit dem Sie können sich Apps mit fester Größe auf größeren Geräten ansehen. Der neue Modus bietet eine Pixel skalierte Alternative zum Standard-Benutzeroberfläche-Stretching für Apps, die nicht die für größere Bildschirmformate konzipiert sind, z. B. auf Tablets. Der neue Modus ist über ein Menüsymbol in der Systemleiste zugänglich sind. Kompatibilitäts-Support.
- Mediensynchronisierung von SD-Karte
Auf Geräten, die eine SD-Karte unterstützen, können Nutzer Mediendateien jetzt direkt laden von der SD-Karte an Apps, die sie verwenden. Eine Systemeinrichtung erstellt die Dateien, für Apps aus dem System-Medienspeicher zugänglich sind.
Neue Funktionen für Entwickler
- Erweiterte API zur 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 der Steuerelemente, die sie bereitstellt, finden Sie in den folgenden Abschnitten.
API-Übersicht
Screens Support APIs
Mit Android 3.2 werden neue Bildschirm-Support-APIs eingeführt, die Ihnen mehr wie ihre Anwendungen 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 sich immer noch darauf verlassen, dass die Plattform eine Dichteabstraktion ermöglichen, sodass Anwendungen die Unterschiede in der tatsächlichen Pixeldichte auf dem jeweiligen Gerät kompensieren. Ich können Sie die Anwendungs-UI so gestalten, verfügbarer Speicherplatz. Die Plattform zeigt den verfügbaren Speicherplatz anhand von drei neuen Eigenschaften: smallestWidth, width und height:
- Die kleinste Breite eines Bildschirms ist die grundlegende Mindestgröße. gemessen in dichteunabhängigen Pixeleinheiten („dp“). der Bildschirmhöhe oder ist die kürzere der beiden Werte. Bei einem Bildschirm im Hochformat „smallestWidth“ basiert normalerweise auf seiner Breite, im Querformat dagegen auf ihrer Höhe. In allen Fällen wird die kleinste Breite von einer festen Eigenschaft des Bildschirm und der Wert ändert sich unabhängig von der Ausrichtung nicht. Die kleinste Breite ist wichtig für Anwendungen, da es die kürzeste mögliche Breite darstellt. in dem die Benutzeroberfläche der Anwendung gezeichnet werden muss (ohne Bildschirmbereiche). die vom System reserviert wurden.
- Im Gegensatz dazu stehen Breite und Höhe eines Bildschirms 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 miniestWidth, Breite oder Höhe, und
- 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 Beispiele, gemessen in „dp“ Einheiten.
Tabelle 1 Typische Geräte mit Dichte und die Größe in dp.
Typ | Dichte (generalisiert) | 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 × 1280 | 800 |
In den folgenden Abschnitten finden Sie weitere Informationen zu den neuen Bildschirmqualifizierern. und Manifest-Attribute. 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 Kennzeichner 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
undhNNNdp
: Gibt das Minimum an Breite oder Höhe, für die die Ressource verwendet werden soll, in „dp“ Einheiten. Als dass die Breite und Höhe eines Bildschirms relativ zur Ausrichtung des und verä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. Wann? mehrere Ressourcenkonfigurationen für einen bestimmten Bildschirm infrage kommen, wählt die Konfiguration aus, die am ehesten übereinstimmt. Für die präzise Steuerung welche Ressourcen auf einem bestimmten Bildschirm geladen werden, Qualifier verwenden oder mehrere neue oder vorhandene Qualifier kombinieren.
Basierend auf den oben aufgeführten typischen Abmessungen können Sie die neuen Qualifizierer verwenden:
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 Qualifier, sodass ihr Kombinieren Sie sie nach Bedarf, damit Ihre App auf jedem Gerät 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 Kompatibilität der Bildschirmgrößen
Das Framework bietet einen neuen Satz von <supports-screens>
-Manifestattributen, mit denen
die Unterstützung Ihrer App für
verschiedene Bildschirmgrößen verwalten.
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. Wie bei den oben beschriebenen Ressourcenqualifizierern wird auch das neue
Manifest-Attribute geben die Bandbreite der von der App unterstützten Bildschirme an,
wie von der kleinsten Breite angegeben.
Die neuen Manifestattribute für die Bildschirmunterstützung sind:
android:compatibleWidthLimitDp="numDp"
– Dies können Sie die kleinste kleinste Breite angeben, auf der die App ohne Kompatibilitätsmodus ausgeführt werden zu müssen. 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"
– Dies können Sie die kleinste kleinste Breite angeben, 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:Google Play filtert derzeit keine
Apps basierend auf den oben genannten Attributen. Unterstützung für Filter
die in einer späteren Plattformversion hinzugefügt wird. Anwendungen, die Folgendes erfordern:
zum Filtern nach Bildschirmgröße können die vorhandenen <supports-screens>
Attribute.
Vollständige Informationen zur Verwendung der neuen Attribute finden Sie unter Angeben von die unterstützte Bildschirmgröße.
Bildschirmkompatibilitätsmodus
Android 3.2 bietet einen neuen Bildschirmkompatibilitätsmodus für Apps. explizit deklariert, dass sie keine Bildschirme unterstützen, die so groß sind wie die die ausgeführt werden. Der neue Zoom ist Pixel-skaliert, stellt die Anwendung in einem kleineren Bildschirmbereich dar und skaliert die Pixel den aktuellen Bildschirm ausfüllen.
Standardmäßig bietet das System den Bildschirmkompatibilitätsmodus als Nutzeroption für Apps an. die sie erfordern. Nutzer können den Zoommodus mithilfe eines Steuerelements in der Systemleiste.
Da der neue Bildschirmkompatibilitätsmodus möglicherweise nicht für alle Nutzer Anwendungen, ermöglicht die Plattform der Anwendung, diese mithilfe des Manifests zu deaktivieren. Attribute. Wenn das System von der App deaktiviert wird, bietet es keinen Zoom Kompatibilität als Option für Nutzer zur Verfügung, wenn die App ausgeführt wird.
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 mit dieser Dichte nicht arbeiten müssen. Für Situationen bei denen eine Ausgabe für einen 720p-Bildschirm erforderlich ist, können die UI-Elemente automatisch von der Plattform.
UI-Framework
- Fragmente
<ph type="x-smartling-placeholder">
- </ph>
- Die neue
Fragment.SavedState
-Klasse enthält den Status Informationen, die von einer Fragmentinstanz übersaveFragmentInstanceState()
. - 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. - Neue Methode
setInitialSavedState()
legt den anfänglichen gespeicherten Zustand für ein Fragment bei der ersten Erstellung fest. - Die neue Callback-Methode
onViewCreated()
benachrichtigt das Fragment,onCreateView()
wurde zurückgegeben, aber bevor ein gespeicherter Status in der Ansicht wiederhergestellt wird. - Mit der Methode
isDetached()
wird festgelegt, Das Fragment wurde explizit von der UI getrennt. - Neu:
attach()
unddetach()
-Methoden ermöglichen es einer Anwendung, Fragmente über die Benutzeroberfläche neu anzuhängen oder zu trennen. - 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.
- Die neue
- Informationen zur Bildschirmgröße in ActivityInfo und ApplicationInfo
<ph type="x-smartling-placeholder">
- </ph>
ActivityInfo
fügtCONFIG_SCREEN_SIZE
hinzu undCONFIG_SMALLEST_SCREEN_SIZE
als Bitmasken inconfigChanges
Die Bits geben an, ob eine Aktivität an die Bildschirmgröße und die kleinste Bildschirmgröße angepasst werden kann.ApplicationInfo
hinzugefügtlargestWidthLimitDp
,compatibleWidthLimitDp
, undrequiresSmallestWidthDp
, aus den entsprechenden<supports-screens>
-Attributen abgeleitet ist. in der Manifest-Datei der Anwendung.
- Hilfsprogramme zum Abrufen der Anzeigegröße aus WindowManager
<ph type="x-smartling-placeholder">
- </ph>
- Mit den neuen Methoden
getSize()
undgetRectSize()
können Anwendungen die Rohgröße der Anzeige abrufen.
- Mit den neuen Methoden
- Neue öffentliche Holografie Stile
<ph type="x-smartling-placeholder">
- </ph>
- Die Plattform bietet nun eine Vielzahl
öffentlicher Hologramme Stile
für Text, Actionbar-Widgets und Tabs und mehr. Weitere Informationen finden Sie unter
R.style
für eine vollständige Liste.
- Die Plattform bietet nun eine Vielzahl
öffentlicher Hologramme Stile
für Text, Actionbar-Widgets und Tabs und mehr. Weitere Informationen finden Sie unter
LocalActivityManager
,ActivityGroup
undLocalActivityManager
wurden jetzt eingestellt <ph type="x-smartling-placeholder">- </ph>
- Neue Anwendungen sollten Fragmente anstelle dieser Klassen verwenden. 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)
- Für Apps, die für Android 3.0 (API-Level) entwickelt werden
11) oder höher werden in der Regel auf der Benutzeroberfläche mit dem neuen
ActionBar.newTab()
und zugehörige APIs zum Platzieren von Tabs in ihrem Aktionsleistenbereich.
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 mit den SD-Kartendateien interagieren, indem Sie das MTP-API verwenden.
Grafik
- Paketierbare Versorgungsunternehmen in Point und PointF
<ph type="x-smartling-placeholder">
- </ph>
Point
undPointF
Klassen enthalten jetzt dieParcelable
-Schnittstelle und die DienstprogrammmethodendescribeContents()
,readFromParcel()
undwriteToParcel()
.
IME-Framework
- Neue
getModifiers()
-Methode für den aktuellen Status der Modifikatortasten abrufen.
USB-Framework
- Neue
getRawDescriptors()
-Methode für Die USB-Deskriptoren für das Gerät werden abgerufen. Sie können die auf Deskriptoren zugreifen, die nicht direkt über den und APIs auf unterschiedlicher Ebene.
Netz
- Netzwerktypkonstanten
<ph type="x-smartling-placeholder">
- </ph>
ConnectivityManager
fügt die KonstantenTYPE_ETHERNET
undTYPE_BLUETOOTH
hinzu.
Telefonie
- Konstante für den neuen Netzwerktyp „
NETWORK_TYPE_HSPAP
“.
Wichtige Dienstprogramme
- Paketierbare Versorgungsunternehmen
<ph type="x-smartling-placeholder">
- </ph>
- Die neue Schnittstelle
Parcelable.ClassLoaderCreator
ermöglicht Die Anwendung zum Empfangen des ClassLoader, in dem das Objekt erstellt wird. - Neue
adoptFd
,dup()
undfromFd()
für die VerwaltungParcelFileDescriptor
-Objekte.
- Die neue Schnittstelle
- Binder und IBinder
<ph type="x-smartling-placeholder">
- </ph>
- Neue Methode
dumpAsync()
inBinder
undIBinder
können Anwendungen Dump in eine angegebene Datei. Dadurch wird sichergestellt, dass das Ziel asynchron ausgeführt wird. - Mit dem neuen
IBinder
-Protokoll-TransaktionscodeTWEET_TRANSACTION
können Anwendungen einen Tweet senden an das Zielobjekt übergeben.
- Neue Methode
Konstanten für neue Funktionen
Die Plattform fügt neue Konstanten für Hardwarefunktionen hinzu, die Sie deklarieren können
in ihren Anwendungsmanifesten, um externe Stellen wie Google
Spiel mit erforderlichen Hardware- und Softwarefunktionen 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.
- Featurekonstanten für Anforderungen im Quer- oder Hochformat
Android 3.2 führt neue Funktionskonstanten ein, mit denen Anwendungen angeben können, ob eine Anzeige im Querformat, im Hochformat oder in beidem erforderlich ist. Die Angabe dieser Konstanten bedeutet, dass die App nicht auf Geräten installiert werden darf, die nicht die entsprechende Ausrichtung bieten. 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.
android.hardware.screen.landscape
: Die Anwendung erfordert die Anzeige in Querformat.android.hardware.screen.portrait
: Die Anwendung erfordert die Anzeige in Hochformat.
Für eine typische Anwendung, die sowohl im Quer- als auch im Hochformat ordnungsgemäß funktioniert, müsste normalerweise keine Ausrichtungsanforderung deklariert werden. Vielmehr 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 für Geräte ohne diese Ausrichtung nicht verfügbar ist.
Wenn eine der im Manifest deklarierten Aktivitäten verlangt, dass sie in einer bestimmten Ausrichtung ausgeführt werden,
android:screenOrientation
-Attribut enthält, wird damit auch deklariert, dass die Anwendung erfordert diese Ausrichtung. - Andere Merkmalskonstanten
<ph type="x-smartling-placeholder">
- </ph>
android.hardware.faketouch.multitouch.distinct
: Die Anwendung erfordert Unterstützung für emulierte Mulitouch-Eingaben mit unterschiedlichem Tracking von zwei oder mehr Punkten.android.hardware.faketouch.multitouch.jazzhand
: Die Anwendung erfordert Unterstützung für emulierte Mulitouch-Eingaben mit unterschiedlichem Tracking von fünf oder mehr Punkten.
Bericht zu API-Unterschieden
Eine detaillierte Ansicht aller API-Änderungen unter Android 3.2 (API) Ebene 13), siehe API Bericht zu Unterschieden
API-Ebene
Die Android 3.2-Plattform liefert eine aktualisierte Version die Framework-API. Die Android 3.2 API wird eine ganzzahlige ID zugewiesen, 13 – das ist die im System selbst gespeichert sind. Diese Kennung, die „API-Ebene“ genannt wird, ermöglicht um zu ermitteln, ob eine App mit vor der Installation der Anwendung.
Um in Ihrer App APIs zu verwenden, die in Android 3.2 eingeführt wurden,
müssen Sie die Anwendung anhand der Android-Bibliothek kompilieren, die im
der SDK-Plattform Android 3.2. Je nach Ihren Anforderungen können Sie
könnten
muss auch ein android:minSdkVersion="13"
-Element
<uses-sdk>
-Element im Feld
Manifests.
Weitere Informationen finden Sie unter Was ist eine API? Stufe?