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. 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 und hNNNdp: 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 über saveFragmentInstanceState().
    • 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() und detach() -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.
  • Informationen zur Bildschirmgröße in ActivityInfo und ApplicationInfo <ph type="x-smartling-placeholder">
  • Hilfsprogramme zum Abrufen der Anzeigegröße aus WindowManager <ph type="x-smartling-placeholder">
      </ph>
    • Mit den neuen Methoden getSize() und getRectSize() können Anwendungen die Rohgröße der Anzeige abrufen.
  • 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.
  • LocalActivityManager, ActivityGroup und LocalActivityManager 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

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

Telefonie

Wichtige Dienstprogramme

  • Paketierbare Versorgungsunternehmen <ph type="x-smartling-placeholder">
  • Binder und IBinder <ph type="x-smartling-placeholder">
      </ph>
    • 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 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.

    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">

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?