API-Level: 14
Android 4.0 (ICE_CREAM_SANDWICH
) ist ein wichtiges Plattformrelease, mit dem Nutzern und App-Entwicklern eine Vielzahl neuer Funktionen hinzugefügt wird. Neben den unten beschriebenen neuen Funktionen und APIs ist Android 4.0 eine wichtige Plattformversion, da das umfangreiche Set an APIs und holografischen Designs von Android 3.x auch für kleinere Bildschirme verfügbar ist. Als App-Entwickler haben Sie nun eine einzige Plattform und ein einheitliches API-Framework, mit dem Sie Ihre App mit einem einzigen APK entwickeln und veröffentlichen können. Dies bietet eine optimierte Nutzererfahrung für Mobilgeräte, Tablets und andere Geräte, wenn dieselbe Version von Android, Android 4.0 (API-Level 14) oder höher, ausgeführt wird.
Für Entwickler steht die Plattform Android 4.0 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 Sie mit der Entwicklung oder dem Testen für Android 4.0 beginnen möchten, laden Sie die Plattform mit dem Android SDK Manager in Ihr SDK herunter.
API-Übersicht
Die folgenden Abschnitte bieten einen technischen Überblick über die neuen APIs in Android 4.0.
Anbieter von Social-Media-APIs im Kontakte-Anbieter
Die vom ContactsContract
-Anbieter definierten Kontakt-APIs wurden um neue sozialorientierte Funktionen erweitert, z. B. ein persönliches Profil für den Geräteeigentümer und die Möglichkeit für Nutzer, einzelne Kontakte in soziale Netzwerke einzuladen, die auf dem Gerät installiert sind.
Nutzerprofil
Android enthält jetzt ein persönliches Profil, das den Geräteeigentümer darstellt, wie in der Tabelle ContactsContract.Profile
definiert. Soziale Apps, die eine Nutzeridentität haben, können die Profildaten des Nutzers ergänzen, indem sie einen neuen ContactsContract.RawContacts
-Eintrag in der ContactsContract.Profile
erstellen. Rohkontakte, die den Gerätenutzer darstellen, gehören also nicht in die traditionelle Tabelle mit Rohkontakten, die durch den URI ContactsContract.RawContacts
definiert ist. Stattdessen müssen Sie einen Rohkontakt in die Tabelle unter CONTENT_RAW_CONTACTS_URI
aufnehmen. Rohkontakte aus dieser Tabelle werden dann in dem für den Nutzer sichtbaren Profil „Ich“ zusammengefasst.
Zum Hinzufügen eines neuen Rohkontakts für das Profil ist die Berechtigung „android.Manifest.permission#WRITE_PROFILE“ erforderlich. Um aus der Profiltabelle zu lesen, müssen Sie ebenfalls die Berechtigung „android.Manifest.permission#READ_PROFILE“ anfordern. Die meisten Anwendungen sollten das Nutzerprofil jedoch nicht lesen müssen, selbst wenn sie dem Profil Daten beisteuern. Das Lesen des Nutzerprofils ist eine vertrauliche Berechtigung und Sie sollten davon ausgehen, dass Nutzer Anwendungen skeptisch gegenüberstehen, die sie anfordern.
Einladungs-Intent
Mit der Intent-Aktion INVITE_CONTACT
kann eine App eine Aktion aufrufen, die angibt, dass der Nutzer einem sozialen Netzwerk einen Kontakt hinzufügen möchte. Die App, die die App empfängt, verwendet sie, um den angegebenen Kontakt zu diesem sozialen Netzwerk einzuladen. Die meisten Apps werden sich am Empfang dieses Vorgangs befinden. Die integrierte Personen-App ruft beispielsweise den Einladungs-Intent auf, wenn der Nutzer „Verbindung hinzufügen“ für eine bestimmte soziale App auswählt, die in den Kontaktdaten einer Person aufgeführt ist.
Damit Ihre App in der Liste „Verbindung hinzufügen“ angezeigt wird, muss sie einen Synchronisierungsadapter zum Synchronisieren von Kontaktdaten aus Ihrem sozialen Netzwerk bereitstellen. Anschließend müssen Sie dem System mitteilen, dass Ihre App auf den Intent INVITE_CONTACT
reagiert. Fügen Sie dazu das Attribut inviteContactActivity
zur Konfigurationsdatei der Synchronisierung Ihrer App hinzu und geben Sie einen voll qualifizierten Namen der Aktivität an, die das System starten soll, wenn der Einladungs-Intent gesendet wird.
Die Aktivität, die startet, kann dann den URI für den betreffenden Kontakt aus den Daten des Intents abrufen und die erforderlichen Schritte ausführen, um diesen Kontakt in das Netzwerk einzuladen oder die Person den Verbindungen des Nutzers hinzuzufügen.
Große Fotos
Android unterstützt jetzt hochauflösende Fotos für Kontakte. Wenn Sie nun ein Foto in einen Kontaktdatensatz übertragen, verarbeitet das System es wie zuvor in eine Miniaturansicht von 96 x 96 und ein "Anzeigefoto" mit einer Größe von 256 x 256, das in einem neuen dateibasierten Fotospeicher gespeichert wird. Die genauen Abmessungen, die das System auswählt, können in Zukunft variieren. Sie können einem Kontakt ein großes Foto hinzufügen. Dazu fügen Sie ein großes Foto in die normale PHOTO
-Spalte einer Datenzeile ein, das das System dann in die entsprechende Miniaturansicht verarbeitet und Fotodatensätze anzeigt.
Feedback zur Nutzung des Kontakts
Mit den neuen ContactsContract.DataUsageFeedback
APIs kannst du verfolgen, wie oft der Nutzer bestimmte Methoden zur Kontaktaufnahme mit Personen verwendet, z. B. wie oft der Nutzer die einzelnen Telefonnummern oder E-Mail-Adressen verwendet. Diese Informationen verbessern das Ranking der einzelnen Kontaktmethoden der einzelnen Personen und bieten bessere Vorschläge für die Kontaktaufnahme mit den einzelnen Personen.
Kalenderanbieter
Mit den neuen Kalender-APIs können Sie Kalender, Termine, Teilnehmer, Erinnerungen und Benachrichtigungen, die beim Kalenderanbieter gespeichert sind, lesen, hinzufügen, ändern und löschen.
Diese APIs können für eine Vielzahl von Apps und Widgets verwendet werden, um Kalendertermine zu lesen und zu ändern. Einige der interessantesten Anwendungsfälle sind jedoch Synchronisierungsadapter, die den Kalender des Nutzers von anderen Kalenderdiensten mit dem Kalenderanbieter synchronisieren, um einen einheitlichen Standort für alle Termine des Nutzers zu bieten. Google Kalender-Termine werden beispielsweise über den Adapter für die Google Kalender-Synchronisierung mit dem Kalenderanbieter synchronisiert, sodass diese Termine mit der integrierten Kalender-App von Android angezeigt werden können.
Das Datenmodell für Kalender und terminbezogene Informationen im Kalenderanbieter wird durch CalendarContract
definiert. Alle Kalenderdaten des Nutzers werden in einer Reihe von Tabellen gespeichert, die von verschiedenen abgeleiteten Klassen von CalendarContract
definiert werden:
- Die Tabelle
CalendarContract.Calendars
enthält die kalenderspezifischen Informationen. Jede Zeile in dieser Tabelle enthält die Details für einen einzelnen Kalender, z. B. Name, Farbe, Synchronisierungsinformationen usw. - Die Tabelle
CalendarContract.Events
enthält ereignisspezifische Informationen. Jede Zeile in dieser Tabelle enthält die Informationen für eine einzelne Veranstaltung, z. B. Titel, Ort, Beginn und Ende der Veranstaltung. Das Ereignis kann einmalig oder mehrmals auftreten. Teilnehmer, Erinnerungen und erweiterte Eigenschaften werden in separaten Tabellen gespeichert und verwenden_ID
des Termins, um sie mit dem Termin zu verknüpfen. - Die Tabelle
CalendarContract.Instances
enthält die Start- und Endzeit für das Auftreten eines Ereignisses. Jede Zeile in dieser Tabelle steht für ein einzelnes Vorkommen. Bei einmaligen Ereignissen werden die Instanzen 1:1-Ereignissen zugeordnet. Bei wiederkehrenden Ereignissen werden automatisch mehrere Zeilen generiert, die dem mehrfachen Vorkommen des Ereignisses entsprechen. - Die Tabelle
CalendarContract.Attendees
enthält die Informationen zu den Teilnehmern oder Gästen des Termins. Jede Zeile steht für einen einzelnen Gast eines Termins. Es gibt den Typ des Gasts und die Antwort der Person auf den Termin an. - Die Tabelle
CalendarContract.Reminders
enthält die Benachrichtigungsdaten. Jede Zeile steht für eine einzelne Benachrichtigung für ein Ereignis. Ein Termin kann mehrere Erinnerungen haben. Die Anzahl der Erinnerungen pro Termin wird inMAX_REMINDERS
angegeben. Sie wird vom Synchronisierungsadapter festgelegt, der für den jeweiligen Kalender verantwortlich ist. Erinnerungen werden in Minuten angegeben, bevor der Termin geplant wird, und legen eine Alarmmethode fest, z. B. eine Benachrichtigung, eine E-Mail oder eine SMS zur Erinnerung. - Die Tabelle
CalendarContract.ExtendedProperties
enthält intransparente Datenfelder, die vom Synchronisierungsadapter verwendet werden. Der Anbieter unternimmt mit den Elementen in dieser Tabelle keine Maßnahmen, außer sie werden zusammen mit den zugehörigen Ereignissen gelöscht.
Damit Sie mit dem Kalenderanbieter auf die Kalenderdaten eines Nutzers zugreifen können, muss Ihre Anwendung die Berechtigung READ_CALENDAR
(für den Lesezugriff) und WRITE_CALENDAR
(für den Schreibzugriff) anfordern.
Ereignis-Intent
Wenn Sie dem Kalender des Nutzers lediglich einen Termin hinzufügen möchten, können Sie den Intent ACTION_INSERT
mit den von Events.CONTENT_URI
definierten Daten verwenden, um in der Kalender App eine Aktivität zu starten, durch die neue Termine erstellt werden. Für die Verwendung des Intents ist keine Berechtigung erforderlich und Sie können Ereignisdetails mit den folgenden Extras angeben:
Events.TITLE
: Name des Ereignisses.CalendarContract.EXTRA_EVENT_BEGIN_TIME
: Ereignisbeginn in Millisekunden seit der EpocheCalendarContract.EXTRA_EVENT_END_TIME
: Ereignisende in Millisekunden seit EpocheEvents.EVENT_LOCATION
: Ort des EreignissesEvents.DESCRIPTION
: EreignisbeschreibungIntent.EXTRA_EMAIL
: E-Mail-Adressen der einzuladenden PersonenEvents.RRULE
: Die Wiederholungsregel für den Termin.Events.ACCESS_LEVEL
: gibt an, ob der Termin privat oder öffentlich istEvents.AVAILABILITY
: Gibt an, ob der Zeitraum dieses Ereignisses zulässt, dass gleichzeitig andere Ereignisse geplant werden.
Anbieter der Mailbox
Mit dem neuen Mailboxanbieter können Anwendungen dem Gerät Mailboxnachrichten hinzufügen, um alle Mailboxnachrichten des Nutzers in einer einzigen visuellen Darstellung zu präsentieren. Es ist beispielsweise möglich, dass ein Nutzer mehrere Mailboxquellen hat, z. B. eine vom Mobilfunkanbieter des Telefons und andere von VoIP oder anderen alternativen Sprachdiensten. Diese Apps können die Voicemail Provider-APIs verwenden, um ihre Mailboxnachrichten dem Gerät hinzuzufügen. Die integrierte Telefonanwendung präsentiert dem Nutzer dann alle Mailboxnachrichten in einer einheitlichen Präsentation. Obwohl die Telefonanwendung des Systems die einzige Anwendung ist, die alle Mailboxnachrichten lesen kann, kann jede Anwendung, die Mailboxnachrichten bereitstellt, die dem System hinzugefügten Mailboxnachrichten lesen (aber keine Mailboxnachrichten von anderen Diensten lesen).
Da die APIs derzeit nicht zulassen, dass Drittanbieter-Apps alle Mailboxnachrichten des Systems lesen, sollten die einzigen Drittanbieter-Apps, die Mailboxnachrichten zur Zustellung an den Nutzer haben, die Mailbox APIs verwenden.
Die Klasse VoicemailContract
definiert den Contentanbieter für den Mailbox Provder. Die Unterklassen VoicemailContract.Voicemails
und VoicemailContract.Status
stellen Tabellen bereit, in die Apps Mailboxdaten zum Speichern auf dem Gerät einfügen können. Ein Beispiel für eine Mailboxanbieter-App findest du in der Demo zum Mailboxanbieter.
Multimedia
Unter Android 4.0 werden mehrere neue APIs für Anwendungen hinzugefügt, die mit Medien wie Fotos, Videos und Musik interagieren.
Medieneffekte
Mit einem neuen Framework für Medieneffekte können Sie eine Vielzahl von visuellen Effekten auf Bilder und Videos anwenden. Mit Bildeffekten können Sie beispielsweise ganz einfach rote Augen korrigieren, ein Bild in Graustufen umwandeln, die Helligkeit anpassen, die Sättigung anpassen, ein Bild drehen, einen Fischaugeneffekt anwenden und vieles mehr. Das System führt die gesamte Verarbeitung auf der GPU aus, um maximale Leistung zu erzielen.
Für maximale Leistung werden Effekte direkt auf OpenGL-Texturen angewendet. Daher muss Ihre Anwendung über einen gültigen OpenGL-Kontext verfügen, bevor die Effekt-APIs verwendet werden können. Die Texturen, auf die Sie Effekte anwenden, können von Bitmaps, Videos oder sogar von der Kamera stammen. Texturen müssen jedoch bestimmte Einschränkungen erfüllen:
- Sie müssen an ein
GL_TEXTURE_2D
-Texturbild gebunden sein. - Sie müssen mindestens eine Mipmap-Ebene enthalten.
Ein Effect
-Objekt definiert einen einzelnen Medieneffekt, den Sie auf einen Bildframe anwenden können. Der grundlegende Workflow zum Erstellen eines Effect
sieht so aus:
- Rufe
EffectContext.createWithCurrentGlContext()
aus deinem OpenGL ES 2.0-Kontext auf. - Verwenden Sie das zurückgegebene
EffectContext
, umEffectContext.getFactory()
aufzurufen, das eine Instanz vonEffectFactory
zurückgibt. - Rufen Sie
createEffect()
auf und übergeben Sie einen Effektnamen aus @link android.media.effect.EffectFactory}, z. B.EFFECT_FISHEYE
oderEFFECT_VIGNETTE
.
Sie können die Parameter eines Effekts anpassen, indem Sie setParameter()
aufrufen und einen Parameternamen und einen Parameterwert übergeben. Für jede Art von Effekt sind verschiedene Parameter zulässig, die mit dem Namen des Effekts angegeben sind. EFFECT_FISHEYE
hat beispielsweise einen Parameter für den scale
der Verzerrung.
Wenn Sie einen Effekt auf eine Textur anwenden möchten, rufen Sie apply()
für Effect
auf und übergeben Sie die Eingabetextur, deren Breite und Höhe sowie die Ausgabetextur. Die Eingabetextur muss an ein GL_TEXTURE_2D
-Texturbild gebunden sein. Dies geschieht normalerweise durch Aufrufen der Funktion glTexImage2D()
. Sie können mehrere Mipmap-Ebenen angeben. Wenn die Ausgabetextur nicht an ein Texturbild gebunden wurde, wird sie automatisch durch den Effekt als GL_TEXTURE_2D
und mit einer Mipmap-Ebene (0) gebunden, die dieselbe Größe wie die Eingabe haben.
Alle in EffectFactory
aufgeführten Effekte werden garantiert unterstützt.
Einige zusätzliche Effekte, die von externen Bibliotheken verfügbar sind, werden jedoch nicht von allen Geräten unterstützt. Daher müssen Sie zuerst prüfen, ob der gewünschte Effekt aus der externen Bibliothek durch Aufrufen von isEffectSupported()
unterstützt wird.
Fernbedienungs-Client
Mit der neuen RemoteControlClient
können Mediaplayer die Wiedergabesteuerung über Fernbedienungsclients wie den Sperrbildschirm des Geräts aktivieren. Mediaplayer können auch Informationen über die aktuell wiedergegebenen Medien zur Anzeige auf der Fernbedienung bereitstellen, z. B. Titelinformationen und Albumcover.
Instanziieren Sie ein RemoteControlClient
mit seinem Konstruktor und übergeben Sie ein PendingIntent
, das ACTION_MEDIA_BUTTON
überträgt, um Remote Control-Clients für Ihren Mediaplayer zu aktivieren. Der Intent muss auch die explizite BroadcastReceiver
-Komponente in Ihrer App deklarieren, die das ACTION_MEDIA_BUTTON
-Ereignis verarbeitet.
Um zu deklarieren, welche Eingaben der Mediensteuerung dein Player verarbeiten kann, musst du setTransportControlFlags()
im RemoteControlClient
aufrufen und eine Reihe von FLAG_KEY_MEDIA_*
-Flags übergeben, z. B. FLAG_KEY_MEDIA_PREVIOUS
und FLAG_KEY_MEDIA_NEXT
.
Anschließend müssen Sie Ihr RemoteControlClient
registrieren, indem Sie es an MediaManager.registerRemoteControlClient()
übergeben.
Nach der Registrierung empfängt der Broadcast-Empfänger, den Sie bei der Instanziierung von RemoteControlClient
angegeben haben, ACTION_MEDIA_BUTTON
-Ereignisse, wenn auf einer Fernbedienung eine Taste gedrückt wird. Der Intent, den Sie erhalten, enthält die KeyEvent
für die gedrückte Medientaste, die Sie mit getParcelableExtra(Intent.EXTRA_KEY_EVENT)
aus dem Intent abrufen können.
Um auf der Fernbedienung Informationen über die Medien zu sehen, die gerade abgespielt werden, rufen Sie editMetaData()
auf und fügen Sie dem zurückgegebenen RemoteControlClient.MetadataEditor
Metadaten hinzu. Du kannst eine Bitmap für Media-Artwork, numerische Informationen wie die verstrichene Zeit und Textinformationen wie den Titeltitel bereitstellen. Informationen zu verfügbaren Schlüsseln finden Sie unter den METADATA_KEY_*
-Flags in MediaMetadataRetriever
.
Eine Beispielimplementierung finden Sie in Random Music Player. Mit einer Kompatibilitätslogik wird der Remote Control-Client auf Geräten mit Android 4.0 aktiviert, während Geräte weiterhin bis Android 2.1 unterstützt werden.
Mediaplayer
- Zum Streamen von Online-Medien von
MediaPlayer
ist jetzt die BerechtigungINTERNET
erforderlich. Wenn SieMediaPlayer
zum Abspielen von Inhalten aus dem Internet verwenden, müssen Sie Ihrem Manifest die BerechtigungINTERNET
hinzufügen. Andernfalls funktioniert die Medienwiedergabe ab Android 4.0 nicht. - Mit
setSurface()
können Sie einenSurface
definieren, der sich als Videosenke verhält. - Mit
setDataSource()
kannst du mit deiner Anfrage zusätzliche HTTP-Header senden, was für HTTP(S)-Livestreaming nützlich sein kann - HTTP(S)-Livestreaming berücksichtigt jetzt HTTP-Cookies für Anfragen
Medientypen
Android 4.0 unterstützt:
- HTTP/HTTPS-Live-Streaming-Protokoll Version 3
- ADTS-RAW-AAC-Audiocodierung
- WEBP-Bilder
- Matroska-Video
Weitere Informationen finden Sie unter Unterstützte Medienformate.
Kamera
Die Klasse Camera
enthält jetzt APIs zur Gesichtserkennung und zum Steuern des Fokus- und Messbereichs.
Gesichtserkennung
Kamera-Apps können jetzt mit den Gesichtserkennungs-APIs von Android die Fähigkeiten verbessern. Diese erkennen nicht nur das Gesicht eines Motivs, sondern auch bestimmte Gesichtsmerkmale wie Augen und Mund.
Damit in deiner Kamera-App Gesichter erkannt werden können, musst du durch Aufrufen von setFaceDetectionListener()
eine Camera.FaceDetectionListener
registrieren. Anschließend können Sie startFaceDetection()
aufrufen, um die Oberfläche der Kamera zu starten und mit der Gesichtserkennung zu beginnen.
Wenn das System ein oder mehrere Gesichter in der Kameraszene erkennt, ruft es den onFaceDetection()
-Callback in der Implementierung von Camera.FaceDetectionListener
auf, einschließlich eines Arrays mit Camera.Face
-Objekten.
Eine Instanz der Camera.Face
-Klasse stellt verschiedene Informationen zum erkannten Gesicht bereit, darunter:
- Ein
Rect
, der die Grenzen des Gesichts bezogen auf das aktuelle Sichtfeld der Kamera angibt - Eine Ganzzahl zwischen 1 und 100, die angibt, wie sicher das System ist, dass das Objekt ein menschliches Gesicht ist
- Eine eindeutige ID, mit der mehrere Gesichter erfasst werden können
- Mehrere
Point
-Objekte, die angeben, wo sich Augen und Mund befinden
Hinweis:Die Gesichtserkennung wird auf einigen Geräten möglicherweise nicht unterstützt. Rufen Sie daher getMaxNumDetectedFaces()
auf und prüfen Sie, ob der Rückgabewert größer als null ist. Außerdem unterstützen einige Geräte die Identifikation von Augen und Mund möglicherweise nicht. In diesem Fall sind diese Felder im Camera.Face
-Objekt null.
Fokus- und Messbereiche
Kamera-Apps können jetzt die Bereiche steuern, die die Kamera für den Fokus und die Messung des Weißabgleichs und der automatischen Belichtung verwendet. Beide Funktionen verwenden die neue Camera.Area
-Klasse, um den Bereich der aktuellen Kamera-Ansicht anzugeben, der fokussiert oder gemessen werden soll. Eine Instanz der Camera.Area
-Klasse definiert die Grenzen des Gebiets mit einer Rect
und dessen Gewichtung, die die Wichtigkeit des Gebiets im Verhältnis zu anderen berücksichtigten Gebieten durch eine Ganzzahl darstellt.
Bevor Sie einen Fokus- oder Messbereich festlegen, sollten Sie getMaxNumFocusAreas()
bzw. getMaxNumMeteringAreas()
aufrufen. Wenn diese Nullen zurückgeben, unterstützt das Gerät die entsprechende Funktion nicht.
Um den Fokus oder die Messbereiche festzulegen, die verwendet werden sollen, rufen Sie einfach setFocusAreas()
oder setMeteringAreas()
auf. Jedes Objekt nimmt eine List
mit Camera.Area
-Objekten an, die die Bereiche angeben, die für die Fokussierung oder Messung berücksichtigt werden sollen. Sie können beispielsweise eine Funktion implementieren, mit der der Nutzer den Fokusbereich festlegen kann. Dazu berührt er einen Bereich der Vorschau, den Sie dann in ein Camera.Area
-Objekt übertragen und die Kamera auffordern, diesen Bereich der Szene zu fokussieren.
Der Fokus oder die Belichtung in diesem Bereich wird ständig aktualisiert, wenn sich das Motiv ändert.
Kontinuierlicher Autofokus für Fotos
Du kannst jetzt beim Aufnehmen von Fotos den fortlaufenden automatischen Fokus aktivieren. Übergeben Sie FOCUS_MODE_CONTINUOUS_PICTURE
an setFocusMode()
, um CAF in der Kamera-App zu aktivieren. Wenn Sie ein Foto aufnehmen möchten, rufen Sie autoFocus()
auf. Camera.AutoFocusCallback
erhält sofort einen Callback, der angibt, ob der Fokus erzielt wurde. Um CAF nach Erhalt des Callbacks fortzusetzen, müssen Sie cancelAutoFocus()
aufrufen.
Hinweis:Der kontinuierliche automatische Fokus wird auch beim Aufzeichnen von Videos mit FOCUS_MODE_CONTINUOUS_VIDEO
unterstützt, das in API-Level 9 hinzugefügt wurde.
Weitere Kamerafunktionen
- Während der Videoaufnahme kannst du jetzt
takePicture()
aufrufen, um ein Foto zu speichern, ohne die Videositzung zu unterbrechen. Zuvor sollten SieisVideoSnapshotSupported()
aufrufen, um zu prüfen, ob die Hardware die Funktion unterstützt. - Sie können jetzt die automatische Belichtung und den Weißabgleich mit
setAutoExposureLock()
undsetAutoWhiteBalanceLock()
sperren, um zu verhindern, dass sich diese Eigenschaften ändern. - Du kannst jetzt
setDisplayOrientation()
aufrufen, während die Kameravorschau läuft. Bisher war dies nur vor Beginn der Vorschau möglich, aber jetzt lässt sich die Ausrichtung jederzeit ändern.
Kamera-Broadcast-Intents
Camera.ACTION_NEW_PICTURE
: Zeigt an, dass der Nutzer ein neues Foto aufgenommen hat. Die integrierte Kamera App ruft diese Übertragung auf, nachdem ein Foto aufgenommen wurde. Kamera-Apps von Drittanbietern sollten diesen Intent ebenfalls senden, nachdem ein Foto aufgenommen wurde.Camera.ACTION_NEW_VIDEO
: Das bedeutet, dass der Nutzer ein neues Video aufgenommen hat. Die integrierte Kamera App ruft diese Broadcasting-Übertragung auf, nachdem ein Video aufgezeichnet wurde. Kamera-Apps von Drittanbietern sollten diesen Intent ebenfalls nach der Videoaufnahme übertragen.
Android Beam (NDEF-Push mit NFC)
Android Beam ist eine neue NFC-Funktion, mit der Sie NDEF-Nachrichten von einem Gerät an ein anderes senden können. Dieser Prozess wird auch als „NDEF Push“ bezeichnet. Die Datenübertragung wird eingeleitet, wenn zwei Android-Geräte, die Android Beam unterstützen, sich in unmittelbarer Nähe befinden (ca. 4 cm), wobei sich ihre Rückseiten in der Regel berühren. Die Daten in der NDEF-Nachricht können alle Daten enthalten, die Sie zwischen Geräten teilen möchten. Die Kontakte App teilt beispielsweise Kontakte, YouTube teilt Videos und der Browser teilt über Android Beam URLs.
Zum Übertragen von Daten zwischen Geräten mit Android Beam musst du ein NdefMessage
erstellen, das die Informationen enthält, die geteilt werden sollen, während deine Aktivität im Vordergrund ausgeführt wird. Anschließend müssen Sie die NdefMessage
auf eine der beiden folgenden Arten an das System übergeben:
- Definieren Sie ein einzelnes
NdefMessage
-Element, das während der Aktivität übertragen werden soll:Sie können jederzeit
setNdefPushMessage()
aufrufen, um die Nachricht festzulegen, die Sie senden möchten. Sie können diese Methode beispielsweise aufrufen undNdefMessage
während deronCreate()
-Methode Ihrer Aktivität übergeben. Jedes Mal, wenn Android Beam mit einem anderen Gerät aktiviert wird, während sich die Aktivität im Vordergrund befindet, sendet das System dieNdefMessage
an das andere Gerät. - Definieren Sie den
NdefMessage
, der bei der Initiierung von Android Beam übertragen werden soll:Implementieren Sie
NfcAdapter.CreateNdefMessageCallback
. Ihre Implementierung der MethodecreateNdefMessage()
gibt dann dasNdefMessage
zurück, das Sie senden möchten. Übergeben Sie dann die ImplementierungNfcAdapter.CreateNdefMessageCallback
ansetNdefPushMessageCallback()
.Wenn in diesem Fall Android Beam mit einem anderen Gerät aktiviert wird, während sich Ihre Aktivität im Vordergrund befindet, ruft das System
createNdefMessage()
auf, um dieNdefMessage
abzurufen, die Sie senden möchten. So können Sie festlegen, dassNdefMessage
nur dann gesendet wird, wenn Android Beam initiiert wurde, für den Fall, dass der Inhalt der Nachricht im Laufe der Aktivität variieren kann.
Wenn Sie einen bestimmten Code ausführen möchten, sobald das System Ihre NDEF-Nachricht erfolgreich an das andere Gerät gesendet hat, können Sie NfcAdapter.OnNdefPushCompleteCallback
implementieren und mit setNdefPushCompleteCallback()
festlegen. Das System ruft dann onNdefPushComplete()
auf, wenn die Nachricht zugestellt wird.
Auf dem empfangenden Gerät sendet das System NDEF-Push-Nachrichten ähnlich wie normale NFC-Tags. Das System ruft einen Intent mit der Aktion ACTION_NDEF_DISCOVERED
auf, um eine Aktivität zu starten. Dabei wird entweder eine URL oder ein MIME-Typ gemäß dem ersten NdefRecord
in NdefMessage
festgelegt. Für die Aktivität, auf die Sie antworten möchten, können Sie Intent-Filter für die URLs oder MIME-Typen deklarieren, die für Ihre Anwendung wichtig sind. Weitere Informationen zu Tag Dispatch finden Sie im NFC-Entwicklerleitfaden.
Wenn das NdefMessage
einen URI enthalten soll, können Sie jetzt mit der praktischen Methode createUri
eine neue NdefRecord
basierend auf einem String oder einem Uri
-Objekt erstellen. Wenn der URI ein spezielles Format ist, den Ihre App auch während eines Android Beam-Ereignisses empfangen soll, sollten Sie mit demselben URI-Schema einen Intent-Filter für Ihre Aktivität erstellen, um die eingehende NDEF-Nachricht zu erhalten.
Sie sollten außerdem einen „Android-Anwendungseintrag“ mit Ihrem NdefMessage
übergeben, damit Ihre App die eingehende NDEF-Nachricht auch dann verarbeitet, wenn andere Anwendungen nach derselben Intent-Aktion filtern. Sie können einen Android-Anwendungseintrag erstellen, indem Sie createApplicationRecord()
aufrufen und den Paketnamen Ihrer App übergeben. Wenn das andere Gerät die NDEF-Nachricht mit dem Anwendungseintrag empfängt und mehrere Anwendungen Aktivitäten enthalten, die den angegebenen Intent verarbeiten, sendet das System die Nachricht immer an die Aktivität in Ihrer Anwendung (basierend auf dem übereinstimmenden Anwendungseintrag). Wenn Ihre App derzeit nicht auf dem Zielgerät installiert ist, verwendet das System den Android-App-Eintrag, um Google Play zu starten. Der Nutzer wird zur Installation weitergeleitet.
Wenn Ihre App keine NFC-APIs für NDEF-Push-Nachrichten verwendet, bietet Android ein Standardverhalten: Wenn Ihre App auf einem Gerät im Vordergrund ausgeführt wird und Android Beam mit einem anderen Android-Gerät aufgerufen wird, empfängt das andere Gerät eine NDEF-Nachricht mit einem Android-App-Eintrag, der Ihre App identifiziert. Wenn die App auf dem empfangenden Gerät installiert ist, wird sie vom System gestartet. Falls sie nicht installiert ist, wird Google Play geöffnet und der Nutzer wird zu Ihrer App weitergeleitet, um sie zu installieren.
Weitere Informationen zu Android Beam und anderen NFC-Funktionen finden Sie im Entwicklerleitfaden NFC-Grundlagen. Beispielcode für Android Beam finden Sie in der Android Beam-Demo.
WLAN-P2P
Android unterstützt jetzt WLAN-Peer-to-Peer-Verbindungen (P2P) zwischen Android-Geräten und anderen Gerätetypen, gemäß dem Wi-Fi DirectTM-Zertifizierungsprogramm der Wi-Fi DirectTM, ohne Hotspot oder Internetverbindung. Das Android-Framework bietet eine Reihe von Wi-Fi-P2P-APIs, mit denen Sie andere Geräte erkennen und eine Verbindung zu anderen Geräten herstellen können, wenn jedes Gerät Wi-Fi P2P unterstützt. Anschließend können Sie über eine schnelle Verbindung über größere Entfernungen kommunizieren, die deutlich länger sind als eine Bluetooth-Verbindung.
Das neue Paket android.net.wifi.p2p
enthält alle APIs zum Herstellen von Peer-to-Peer-Verbindungen mit WLAN. Der primäre Kurs, mit dem Sie arbeiten müssen, ist WifiP2pManager
. Sie können diesen durch Aufrufen von getSystemService(WIFI_P2P_SERVICE)
erwerben. Die WifiP2pManager
umfasst APIs zum:
- Initialisieren Sie Ihre Anwendung für P2P-Verbindungen durch Aufrufen von
initialize()
discoverPeers()
anrufen und Geräte in der Nähe finden- Starte eine P2P-Verbindung, indem du
connect()
anrufst - Und andere Vorteile
Außerdem sind einige weitere Schnittstellen und Klassen erforderlich, z. B.:
- Über die Schnittstelle
WifiP2pManager.ActionListener
können Sie Callbacks empfangen, wenn ein Vorgang wie das Erkennen von Peers oder das Herstellen einer Verbindung zu ihnen erfolgreich ist oder fehlschlägt. - Über die
WifiP2pManager.PeerListListener
-Schnittstelle können Sie Informationen über erkannte Peers empfangen. Der Callback stellt einWifiP2pDeviceList
bereit, mit dem du einWifiP2pDevice
-Objekt für jedes Gerät in Reichweite abrufen und Informationen wie den Gerätenamen, die Adresse, den Gerätetyp, die vom Gerät unterstützten WPS-Konfigurationen und mehr abrufen kannst. - Über die Schnittstelle
WifiP2pManager.GroupInfoListener
können Sie Informationen zu einer P2P-Gruppe erhalten. Der Callback stellt einWifiP2pGroup
-Objekt bereit, das Gruppeninformationen wie den Inhaber, den Netzwerknamen und die Passphrase bereitstellt. - Über die
WifiP2pManager.ConnectionInfoListener
-Schnittstelle können Sie Informationen zur aktuellen Verbindung erhalten. Der Callback stellt einWifiP2pInfo
-Objekt mit Informationen bereit, z. B. ob eine Gruppe gebildet wurde und wer der Gruppeninhaber ist.
Damit Sie die Wi-Fi P2P APIs verwenden können, muss Ihre App die folgenden Nutzerberechtigungen anfordern:
ACCESS_WIFI_STATE
CHANGE_WIFI_STATE
INTERNET
: Obwohl Ihre App technisch nicht mit dem Internet verbunden ist, ist für die Kommunikation mit Wi-Fi-P2P-Peers mit Standard-Java-Sockets eine Internetberechtigung erforderlich.
Das Android-System sendet bei bestimmten WLAN-P2P-Ereignissen außerdem verschiedene Aktionen:
WIFI_P2P_CONNECTION_CHANGED_ACTION
: Der P2P-Verbindungsstatus hat sich geändert. Dieses enthältEXTRA_WIFI_P2P_INFO
mit einemWifiP2pInfo
-Objekt undEXTRA_NETWORK_INFO
mit einemNetworkInfo
-Objekt.WIFI_P2P_STATE_CHANGED_ACTION
: Der P2P-Status hat sich zwischen „Aktiviert“ und „Deaktiviert“ geändert. Er umfasstEXTRA_WIFI_STATE
mitWIFI_P2P_STATE_DISABLED
oderWIFI_P2P_STATE_ENABLED
WIFI_P2P_PEERS_CHANGED_ACTION
: Die Liste der Peer-Geräte hat sich geändert.WIFI_P2P_THIS_DEVICE_CHANGED_ACTION
: Die Details für dieses Gerät haben sich geändert.
Weitere Informationen finden Sie in der WifiP2pManager
-Dokumentation. Sehen Sie sich auch die Beispielanwendung Wi-Fi P2P Demo an.
Bluetooth Health-Geräte
Android unterstützt jetzt Bluetooth Health Profile-Geräte, sodass Sie Apps erstellen können, die Bluetooth verwenden, um mit Gesundheitsgeräten zu kommunizieren, die Bluetooth unterstützen, wie z. B. Herzfrequenzmesser, Blutmessgeräte, Thermometer und Waagen.
Ähnlich wie bei regulären Headset- und A2DP-Profilgeräten müssen Sie getProfileProxy()
mit dem Profiltyp BluetoothProfile.ServiceListener
und HEALTH
aufrufen, um eine Verbindung mit dem Profil-Proxyobjekt herzustellen.
Nachdem Sie den Health Profile-Proxy (das BluetoothHealth
-Objekt) erhalten haben, umfasst die Verbindung mit den gekoppelten Health-Geräten und die Kommunikation mit diesen die folgenden neuen Bluetooth-Klassen:
BluetoothHealthCallback
: Sie müssen diese Klasse erweitern und die Callback-Methoden implementieren, um Benachrichtigungen über Änderungen am Registrierungsstatus und am Status des Bluetooth-Kanals der App zu erhalten.BluetoothHealthAppConfiguration
: Bei Callbacks anBluetoothHealthCallback
empfangen Sie eine Instanz dieses Objekts, die Konfigurationsinformationen über das verfügbare Bluetooth-Gerät zur Verfügung stellt. Diese Informationen müssen Sie für verschiedene Vorgänge wie das Initiieren und Beenden von Verbindungen mit denBluetoothHealth
-APIs verwenden.
Weitere Informationen zur Verwendung des Bluetooth Health Profile findest du in der Dokumentation zu BluetoothHealth
.
Bedienungshilfen
Android 4.0 verbessert die Zugänglichkeit für Nutzer mit Sehbehinderung mit dem neuen Touchscreen-Modus "Erkundung" und erweiterten APIs, mit denen Sie mehr Informationen zum Anzeigen von Inhalten bereitstellen oder erweiterte Bedienungshilfen entwickeln können.
Modus „Tippen & Entdecken“
Nutzer mit Sehverlust können den Bildschirm jetzt erkunden, indem sie einen Finger über den Bildschirm berühren und ziehen, um Sprachbeschreibungen des Inhalts zu hören. Da der Explore-by-Touch-Modus wie ein virtueller Cursor funktioniert, können Screenreader den beschreibenden Text auf dieselbe Weise identifizieren wie Screenreader, wenn der Nutzer mit einem Steuerkreuz oder einem Trackball navigiert. Dazu werden die von android:contentDescription
und setContentDescription()
bei einem simulierten „Hover“-Ereignis bereitgestellten Informationen gelesen. Wir weisen Sie darauf hin, dass Sie beschreibenden Text für die Ansichten in Ihrer App angeben sollten, insbesondere für ImageButton
, EditText
, ImageView
und andere Widgets, die normalerweise keinen beschreibenden Text enthalten.
Bedienungshilfen für Ansichten
Um die für Bedienungshilfen wie Screenreader verfügbaren Informationen zu verbessern, kannst du neue Callback-Methoden für Bedienungshilfen in deinen benutzerdefinierten View
-Komponenten implementieren.
Wichtig: Das Verhalten der Methode sendAccessibilityEvent()
hat sich in Android 4.0 geändert. Wie bei der vorherigen Android-Version wird die entsprechende Ansicht mit einem Aufruf von sendAccessibilityEvent()
benachrichtigt, wenn der Nutzer Bedienungshilfen auf dem Gerät aktiviert und ein Eingabeereignis wie ein Klick oder das Bewegen des Mauszeigers erfolgt. Bisher wurde bei der Implementierung von sendAccessibilityEvent()
ein AccessibilityEvent
initialisiert und an AccessibilityManager
gesendet. Das neue Verhalten umfasst einige zusätzliche Callback-Methoden, mit denen die Ansicht und ihre übergeordneten Elemente dem Ereignis weitere Kontextinformationen hinzufügen können:
- Beim Aufruf erfolgen die Methoden
sendAccessibilityEvent()
undsendAccessibilityEventUnchecked()
aufonInitializeAccessibilityEvent()
.Bei benutzerdefinierten Implementierungen von
View
kannonInitializeAccessibilityEvent()
implementiert werden, um zusätzliche Informationen zur Barrierefreiheit an dieAccessibilityEvent
anzuhängen. Sie sollten jedoch auch die Superimplementierung aufrufen, um Standardinformationen wie die standardmäßige Inhaltsbeschreibung, den Elementindex usw. bereitzustellen. Du solltest in diesem Callback jedoch keinen zusätzlichen Textinhalt hinzufügen – das geschieht als Nächstes. - Wenn das Ereignis nach der Initialisierung zu einem von mehreren Typen gehört, die mit Textinformationen gefüllt werden sollten, empfängt die Ansicht einen Aufruf von
dispatchPopulateAccessibilityEvent()
, der auf denonPopulateAccessibilityEvent()
-Callback zurückgreift.In benutzerdefinierten Implementierungen von
View
sollte normalerweiseonPopulateAccessibilityEvent()
implementiert werden, um demAccessibilityEvent
zusätzlichen Textinhalt hinzuzufügen, wenn derandroid:contentDescription
-Text fehlt oder nicht ausreicht. Rufen SiegetText()
.add()
auf, um eine weitere Textbeschreibung fürAccessibilityEvent
hinzuzufügen. - An dieser Stelle übergibt
View
das Ereignis in der Ansichtshierarchie nach oben, indemrequestSendAccessibilityEvent()
in der übergeordneten Ansicht aufgerufen wird. Jede übergeordnete Ansicht hat dann die Möglichkeit, die Informationen zur Barrierefreiheit durch Hinzufügen einerAccessibilityRecord
zu erweitern, bis sie die Stammansicht erreicht, die das Ereignis mitsendAccessibilityEvent()
an dieAccessibilityManager
sendet.
Zusätzlich zu den oben genannten neuen Methoden, die beim Erweitern der View
-Klasse nützlich sind, können Sie diese Ereignis-Callbacks auch für ein beliebiges View
abfangen. Dazu erweitern Sie AccessibilityDelegate
und legen es in der Ansicht mit setAccessibilityDelegate()
fest.
Dabei wird der Aufruf von jeder Bedienungshilfen-Methode in der Ansicht an die entsprechende Methode im Delegaten verschoben. Wenn die Ansicht beispielsweise einen Aufruf von onPopulateAccessibilityEvent()
empfängt, übergibt sie ihn an dieselbe Methode im View.AccessibilityDelegate
. Alle Methoden, die nicht vom Bevollmächtigten verarbeitet werden, werden für das Standardverhalten direkt wieder der Ansicht zurückgegeben. So können Sie nur die Methoden überschreiben, die für eine bestimmte Ansicht erforderlich sind, ohne die View
-Klasse zu erweitern.
Wenn Sie die Kompatibilität mit Android-Versionen vor 4.0 aufrechterhalten und gleichzeitig die neuen Accessibility APIs unterstützen möchten, können Sie dafür die aktuelle Version der Supportbibliothek Version 4 (im Kompatibilitätspaket, r4) verwenden. Verwenden Sie dazu eine Reihe von Dienstprogrammklassen, die die neuen Accessibility APIs in einem abwärtskompatiblen Design bereitstellen.
Bedienungshilfen
Wenn Sie einen Dienst zur Barrierefreiheit entwickeln, wurden die Informationen zu verschiedenen Ereignissen zur Barrierefreiheit erheblich erweitert, um den Nutzern erweitertes Feedback zur Barrierefreiheit zu ermöglichen. Insbesondere werden Ereignisse basierend auf der Zusammensetzung der Ansichten generiert. Dies bietet bessere Kontextinformationen und ermöglicht es Bedienungshilfen, Ansichtshierarchien zu durchlaufen, um zusätzliche Ansichtsinformationen zu erhalten und Sonderfälle abzuwickeln.
Wenn Sie eine Bedienungshilfe entwickeln (z. B. einen Screenreader), können Sie folgendermaßen auf zusätzliche Inhaltsinformationen zugreifen und Ansichtshierarchien durchlaufen:
- Nach dem Empfang eines
AccessibilityEvent
von einer Anwendung rufen SieAccessibilityEvent.getRecord()
auf, um eine bestimmteAccessibilityRecord
abzurufen. An das Ereignis können mehrere Datensätze angehängt sein. - Von
AccessibilityEvent
oder einer einzelnenAccessibilityRecord
können SiegetSource()
aufrufen, um einAccessibilityNodeInfo
-Objekt abzurufen.Ein
AccessibilityNodeInfo
stellt einen einzelnen Knoten des Fensterinhalts in einem Format dar, mit dem Sie Informationen zur Barrierefreiheit dieses Knotens abfragen können. Das vonAccessibilityEvent
zurückgegebeneAccessibilityNodeInfo
-Objekt beschreibt die Ereignisquelle, während die Quelle von einemAccessibilityRecord
den Vorgänger der Ereignisquelle beschreibt. - Mit
AccessibilityNodeInfo
können Sie Informationen dazu abfragen,getParent()
odergetChild()
aufrufen, um die Ansichtshierarchie zu durchlaufen, und dem Knoten sogar untergeordnete Ansichten hinzufügen.
Damit sich Ihre App als Bedienungshilfe im System veröffentlichen kann, muss sie eine XML-Konfigurationsdatei deklarieren, die AccessibilityServiceInfo
entspricht. Weitere Informationen zum Erstellen eines Bedienungshilfedienstes finden Sie unter AccessibilityService
und SERVICE_META_DATA
.
Weitere APIs für Barrierefreiheit
Wenn du dich für die Barrierefreiheit des Geräts interessierst, gibt es in AccessibilityManager
einige neue APIs, z. B.:
AccessibilityManager.AccessibilityStateChangeListener
ist eine Schnittstelle, über die Sie einen Callback erhalten, wenn die Bedienungshilfen aktiviert oder deaktiviert sind.getEnabledAccessibilityServiceList()
liefert Informationen darüber, welche Bedienungshilfen derzeit aktiviert sind.isTouchExplorationEnabled()
gibt an, ob der Modus „Tippen & Entdecken“ aktiviert ist.
Rechtschreibprüfung
Mit einem neuen Framework für die Rechtschreibprüfung können Apps Rechtschreibprüfungen auf ähnliche Weise wie das Framework der Eingabemethode (für IMEs) erstellen. Um eine neue Rechtschreibprüfung zu erstellen, müssen Sie einen Dienst implementieren, der SpellCheckerService
erweitert und die SpellCheckerService.Session
-Klasse erweitert, um Rechtschreibvorschläge basierend auf dem Text bereitzustellen, der von den Callback-Methoden der Schnittstelle bereitgestellt wird. In den SpellCheckerService.Session
-Callback-Methoden müssen die Rechtschreibvorschläge als SuggestionsInfo
-Objekte zurückgegeben werden.
In Anwendungen mit einem Rechtschreibprüfungsdienst muss die Berechtigung BIND_TEXT_SERVICE
wie für den Dienst erforderlich deklariert werden.
Der Dienst muss außerdem einen Intent-Filter mit <action
android:name="android.service.textservice.SpellCheckerService" />
als Aktion des Intents deklarieren. Er sollte ein <meta-data>
-Element enthalten, das Konfigurationsinformationen für die Rechtschreibprüfung deklariert.
Sehen Sie sich dazu die Beispielanwendung Rechtschreibprüfung und Rechtschreibprüfungs-Client an.
Sprachausgabe-Engines
Die Sprachausgabe-APIs (TTS) von Android wurden erheblich erweitert, damit Anwendungen benutzerdefinierte Sprachausgabe-Engines einfacher implementieren können. Anwendungen, die eine Sprachausgabe-Engine verwenden möchten, verfügen über einige neue APIs zur Auswahl einer Suchmaschine.
Sprachausgabe-Engines verwenden
In früheren Android-Versionen konnten Sie die Klasse TextToSpeech
verwenden, um mit der vom System bereitgestellten TTS-Engine Sprachausgabevorgänge auszuführen oder mit setEngineByPackageName()
eine benutzerdefinierte Suchmaschine festzulegen. In Android 4.0 wurde die Methode setEngineByPackageName()
eingestellt. Sie können jetzt die zu verwendende Suchmaschine mit einem neuen TextToSpeech
-Konstruktor angeben, der den Paketnamen einer TTS-Engine akzeptiert.
Du kannst die verfügbaren TTS-Suchmaschinen auch mit getEngines()
abfragen. Diese Methode gibt eine Liste von TextToSpeech.EngineInfo
-Objekten zurück, die Metadaten wie das Symbol, das Label und den Paketnamen der Suchmaschine enthalten.
Sprachausgabe-Engines erstellen
Bisher war es bei benutzerdefinierten Engines erforderlich, die Engine mit einer undokumentierten nativen Headerdatei zu erstellen. In Android 4.0 gibt es eine vollständige Reihe von Framework-APIs für die Erstellung von Sprachausgabe-Engines.
Für die grundlegende Einrichtung ist eine Implementierung von TextToSpeechService
erforderlich, die auf den Intent INTENT_ACTION_TTS_SERVICE
reagiert. Die Hauptarbeit für eine TTS-Engine erfolgt während des onSynthesizeText()
-Callbacks in einem Dienst, der TextToSpeechService
erweitert. Das System liefert bei dieser Methode zwei Objekte:
SynthesisRequest
: Enthält verschiedene Daten, einschließlich des zu synthetisierenden Textes, der Sprache, der Sprechgeschwindigkeit und der Stimmlage.SynthesisCallback
: Über diese Schnittstelle liefert die TTS-Engine die resultierenden Sprachdaten als Audio-Streaming. Zuerst muss die Enginestart()
aufrufen, um anzugeben, dass die Engine für die Übermittlung der Audiodaten bereit ist. Danach mussaudioAvailable()
aufgerufen und die Audiodaten in einem Byte-Zwischenspeicher übergeben werden. Sobald die Suchmaschine alle Audiodaten durch den Zwischenspeicher übergeben hat, rufen Siedone()
auf.
Da das Framework nun eine echte API zum Erstellen von Sprachausgabe-Engines unterstützt, wird die Implementierung des nativen Codes nicht mehr unterstützt. Suchen Sie nach einem Blogpost über eine Kompatibilitätsebene, mit der Sie Ihre alten Sprachausgabe-Engines in das neue Framework konvertieren können.
Ein Beispiel für eine TTS-Engine mit den neuen APIs finden Sie in der Beispielanwendung Text to Speech Engine.
Netzwerknutzung
Mit Android 4.0 können Nutzer genau sehen, wie viele Netzwerkdaten ihre Anwendungen nutzen. Die App „Einstellungen“ bietet Steuerelemente, mit denen Nutzer festgelegte Limits für die Netzwerkdatennutzung verwalten und sogar die Verwendung von Hintergrunddaten für einzelne Apps deaktivieren können. Damit Nutzer nicht den Zugriff Ihrer App auf Daten im Hintergrund deaktivieren, sollten Sie Strategien entwickeln, um die Datenverbindung effizient zu nutzen und Ihre Nutzung an die Art der verfügbaren Verbindung anzupassen.
Wenn Ihre Anwendung viele Netzwerktransaktionen ausführt, sollten Sie Nutzereinstellungen bereitstellen, mit denen Nutzer die Datengewohnheiten Ihrer App steuern können, z. B. wie oft Ihre App Daten synchronisiert, ob Uploads/Downloads nur über WLAN ausgeführt werden, ob Daten beim Roaming verwendet werden sollen usw. Mit diesen Steuerelementen, die ihnen zur Verfügung stehen, ist es viel weniger wahrscheinlich, dass Nutzer den Zugriff Ihrer App auf Daten deaktivieren, wenn sie sich stattdessen ihrer Datennutzung nähern.
Wenn Sie eine Einstellungsaktivität mit diesen Einstellungen angeben, sollten Sie in der Manifestdeklaration einen Intent-Filter für die Aktion ACTION_MANAGE_NETWORK_USAGE
angeben. Beispiele:
<activity android:name="DataPreferences" android:label="@string/title_preferences"> <intent-filter> <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> </activity>
Dieser Intent-Filter zeigt dem System an, dass es sich um die Aktivität handelt, die die Datennutzung Ihrer Anwendung steuert. Wenn der Nutzer also in der App „Einstellungen“ überprüft, wie viele Daten Ihre App verwendet, ist die Schaltfläche „App-Einstellungen anzeigen“ verfügbar, über die Ihre Präferenzaktivität gestartet wird. So kann der Nutzer festlegen, welche Datenmenge Ihre App verwendet.
getBackgroundDataSetting()
wurde verworfen und gibt immer „true“ zurück. Verwenden Sie stattdessen getActiveNetworkInfo()
. Bevor Sie Netzwerktransaktionen ausführen, sollten Sie immer getActiveNetworkInfo()
aufrufen, um das NetworkInfo
für das aktuelle Netzwerk abzurufen, und isConnected()
abfragen, um zu prüfen, ob das Gerät eine Verbindung hat. Sie können dann andere Verbindungseigenschaften prüfen, z. B. ob das Gerät Roaming oder mit einem WLAN verbunden ist.
Unternehmen
Android 4.0 erweitert die Möglichkeiten für Unternehmensanwendungen um folgende Funktionen.
VPN-Dienste
Mit dem neuen VpnService
können Anwendungen ihr eigenes VPN (virtuelles privates Netzwerk) erstellen, das als Service
ausgeführt wird. Ein VPN-Dienst erstellt eine Schnittstelle für ein virtuelles Netzwerk mit eigenen Adress- und Routingregeln und führt alle Lese- und Schreibvorgänge mit einem Dateideskriptor aus.
Verwenden Sie VpnService.Builder
, um einen VPN-Dienst zu erstellen. Damit können Sie die Netzwerkadresse, den DNS-Server, die Netzwerkroute und mehr angeben. Wenn Sie fertig sind, können Sie die Schnittstelle einrichten, indem Sie establish()
aufrufen. Dadurch wird ein ParcelFileDescriptor
zurückgegeben.
Da ein VPN-Dienst Pakete abfangen kann, hat dies Auswirkungen auf die Sicherheit. Wenn Sie VpnService
implementieren, muss Ihr Dienst daher die BIND_VPN_SERVICE
anfordern, damit nur das System eine Verbindung herstellen kann. Nur das System erhält diese Berechtigung, Apps können sie nicht anfordern. Zur Verwendung Ihres VPN-Dienstes müssen Nutzer ihn manuell in den Systemeinstellungen aktivieren.
Geräterichtlinien
Bei Anwendungen, die Geräteeinschränkungen verwalten, kann die Kamera jetzt mithilfe von setCameraDisabled()
und der Eigenschaft USES_POLICY_DISABLE_CAMERA
deaktiviert werden. Diese wird mit einem <disable-camera />
-Element in der Richtlinienkonfigurationsdatei angewendet.
Zertifikatsverwaltung
Die neue KeyChain
-Klasse stellt APIs bereit, mit denen Sie Zertifikate in den Systemschlüsselspeicher importieren und darauf zugreifen können. Zertifikate vereinfachen die Installation von Clientzertifikaten (zur Validierung der Identität des Nutzers) und von Zertifikaten der Zertifizierungsstelle (zur Überprüfung der Serveridentität). Anwendungen wie Webbrowser oder E-Mail-Clients können auf die installierten Zertifikate zugreifen, um Nutzer bei Servern zu authentifizieren. Weitere Informationen finden Sie in der KeyChain
-Dokumentation.
Gerätesensoren
In Android 4.0 wurden zwei neue Sensortypen hinzugefügt:
TYPE_AMBIENT_TEMPERATURE
: Ein Temperatursensor, der die Umgebungs- bzw. Raumtemperatur in Grad Celsius angibt.TYPE_RELATIVE_HUMIDITY
: Ein Luftfeuchtigkeitssensor, der die relative Luftfeuchtigkeit in der Umgebung (Raum) in Prozent angibt.
Wenn ein Gerät sowohl TYPE_AMBIENT_TEMPERATURE
- als auch TYPE_RELATIVE_HUMIDITY
-Sensoren hat, können Sie diese verwenden, um den Taupunkt und die absolute Luftfeuchtigkeit zu berechnen.
Der vorherige Temperatursensor TYPE_TEMPERATURE
wurde eingestellt. Sie sollten stattdessen den Sensor TYPE_AMBIENT_TEMPERATURE
verwenden.
Darüber hinaus wurden die drei synthetischen Sensoren von Android stark verbessert, sodass sie jetzt eine geringere Latenz und eine flüssigere Ausgabe aufweisen. Zu diesen Sensoren gehören der Schwerkraftsensor (TYPE_GRAVITY
), der Rotationsvektorsensor (TYPE_ROTATION_VECTOR
) und der lineare Beschleunigungssensor (TYPE_LINEAR_ACCELERATION
). Die verbesserten Sensoren nutzen den Gyroskopsensor, um ihre Ausgabe zu verbessern. Daher werden die Sensoren nur auf Geräten mit Gyroskop angezeigt.
Aktionsleiste
Das ActionBar
wurde aktualisiert, um mehrere neue Verhaltensweisen zu unterstützen. Vor allem aber verwaltet das System die Größe und Konfiguration der Aktionsleiste auf kleineren Bildschirmen, um eine optimale Nutzererfahrung auf allen Bildschirmgrößen zu bieten. Bei schmalem Bildschirm, etwa im Hochformat, werden die Navigationstabs der Aktionsleiste in einer „gestapelten Leiste“ direkt unter der Hauptaktionsleiste angezeigt. Sie können auch eine geteilte Aktionsleiste aktivieren, bei der alle Aufgaben in einer separaten Leiste am unteren Bildschirmrand platziert werden, wenn der Bildschirm schmal ist.
Aktionsleiste teilen
Wenn Ihre Aktionsleiste mehrere Aktionselemente enthält, passen nicht alle in die Aktionsleiste auf einem schmalen Bildschirm. Das System platziert dann mehr davon im Dreipunkt-Menü. Unter Android 4.0 können Sie jedoch die Option „Aktionsleiste aufteilen“ aktivieren, sodass in einer separaten Leiste am unteren Bildschirmrand weitere Aktionselemente auf dem Bildschirm angezeigt werden können. Wenn Sie die Aktionsleiste zum Teilen aktivieren möchten, fügen Sie entweder Ihrem <application>
-Tag oder den einzelnen <activity>
-Tags in der Manifestdatei android:uiOptions
mit "splitActionBarWhenNarrow"
hinzu. Wenn diese Option aktiviert ist, fügt das System am unteren Bildschirmrand eine zusätzliche Leiste für alle Aufgaben hinzu, wenn der Bildschirm schmal ist. Auf der primären Aktionsleiste werden keine Aufgaben angezeigt.
Wenn Sie die von den ActionBar.Tab
APIs bereitgestellten Navigationstabs verwenden möchten, aber die Hauptaktionsleiste oben nicht benötigen (es sollen nur die Tabs oben angezeigt werden), aktivieren Sie die Leiste für geteilte Aktionen wie oben beschrieben und rufen Sie auch setDisplayShowHomeEnabled(false)
auf, um das Anwendungssymbol in der Aktionsleiste zu deaktivieren. Wenn die Hauptaktionsleiste nichts mehr enthält, verschwindet sie – nur noch die Navigationstabs oben und die Aktionselemente am unteren Bildschirmrand.
Stile für Aktionsleisten
Wenn Sie benutzerdefinierte Stile auf die Aktionsleiste anwenden möchten, können Sie die neuen Stileigenschaften backgroundStacked
und backgroundSplit
verwenden, um einen Hintergrund oder eine Hintergrundfarbe auf den gestapelten Balken bzw. die geteilte Leiste anzuwenden. Sie können diese Stile auch zur Laufzeit mit setStackedBackgroundDrawable()
und setSplitBackgroundDrawable()
festlegen.
Anbieter der Aktion
Mit der neuen ActionProvider
-Klasse können Sie einen speziellen Handler für Aktionselemente erstellen. Ein Aktionsanbieter kann eine Aktionsansicht, ein Standardverhalten für Aktionen und ein Untermenü für jede Aktion definieren, der sie zugeordnet ist. Wenn Sie eine Aufgabe mit dynamischem Verhalten erstellen möchten (z. B. eine variable Aktionsansicht, eine Standardaktion oder ein Untermenü), ist die Erweiterung von ActionProvider
eine gute Lösung, um eine wiederverwendbare Komponente zu erstellen, anstatt die verschiedenen Transformationen von Aufgaben im Fragment oder in der Aktivität zu verarbeiten.
ShareActionProvider
ist beispielsweise eine Erweiterung von ActionProvider
, mit der das Teilen über die Aktionsleiste ermöglicht wird. Anstatt eine herkömmliche Aufgabe zu verwenden, die den Intent ACTION_SEND
aufruft, können Sie mit diesem Aktionsanbieter eine Aktionsansicht mit einer Drop-down-Liste von Anwendungen präsentieren, die den Intent ACTION_SEND
verarbeiten. Wenn der Nutzer eine Anwendung auswählt, die für die Aktion verwendet werden soll, merkt sich ShareActionProvider
diese Auswahl und stellt sie in der Aktionsansicht bereit, damit sie schneller für diese App freigegeben werden kann.
Wenn Sie einen Aktionsanbieter für eine Aufgabe deklarieren möchten, fügen Sie im Optionsmenü Ihrer Aktivität das Attribut android:actionProviderClass
in das Element <item>
ein und geben Sie dabei den Klassennamen des Aktionsanbieters als Wert an. Beispiele:
<item android:id="@+id/menu_share" android:title="Share" android:showAsAction="ifRoom" android:actionProviderClass="android.widget.ShareActionProvider" />
Rufen Sie in der Callback-Methode onCreateOptionsMenu()
Ihrer Aktivität über den Menüpunkt eine Instanz des Aktionsanbieters ab und legen Sie den Intent fest:
Kotlin
override fun onCreateOptionsMenu(menu: Menu): Boolean { menuInflater.inflate(R.menu.options, menu) val shareActionProvider = menu.findItem(R.id.menu_share)?.actionProvider as? ShareActionProvider // Set the share intent of the share action provider. shareActionProvider?.setShareIntent(createShareIntent()) ... return super.onCreateOptionsMenu(menu) }
Java
public boolean onCreateOptionsMenu(Menu menu) { getMenuInflater().inflate(R.menu.options, menu); ShareActionProvider shareActionProvider = (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider(); // Set the share intent of the share action provider. shareActionProvider.setShareIntent(createShareIntent()); ... return super.onCreateOptionsMenu(menu); }
Ein Beispiel für die Verwendung der ShareActionProvider
findest du unter ActionBarShareActionProviderActivity in ApiDemos.
Minimierbare Aktionsansichten
Aufgaben, die eine Aktionsansicht bieten, können jetzt zwischen dem Status der Aktionsansicht und der herkömmlichen Aufgabenansicht wechseln. Bisher wurde bei Verwendung als Aktionsansicht nur die SearchView
-Funktion zum Minimieren unterstützt. Jetzt können Sie aber jeder Aufgabe eine Aktionsansicht hinzufügen und zwischen dem maximierten Zustand (Aktionsansicht ist sichtbar) und dem minimierten Zustand (Aktionselement ist sichtbar) wechseln.
Wenn Sie festlegen möchten, dass eine Aufgabe, die eine Aktionsansicht enthält, minimierbar ist, fügen Sie in der XML-Datei des Menüs das Flag “collapseActionView"
in das Attribut android:showAsAction
für das Element <item>
ein.
Damit Sie Callbacks erhalten, wenn eine Aktionsansicht zwischen maximierter und minimierter Ansicht wechselt, müssen Sie eine Instanz von MenuItem.OnActionExpandListener
mit der entsprechenden MenuItem
registrieren. Rufen Sie dazu setOnActionExpandListener()
auf. Normalerweise sollten Sie dies während des onCreateOptionsMenu()
-Callbacks tun.
Zum Steuern einer minimierbaren Aktionsansicht können Sie collapseActionView()
und expandActionView()
im jeweiligen MenuItem
aufrufen.
Beim Erstellen einer benutzerdefinierten Aktionsansicht können Sie auch die neue CollapsibleActionView
-Schnittstelle implementieren, um Callbacks zu erhalten, wenn die Ansicht maximiert und minimiert wird.
Weitere APIs für Aktionsleiste
- Mit
setHomeButtonEnabled()
können Sie angeben, ob sich das Symbol bzw. das Logo als Schaltfläche für den Startbildschirm oder nach oben verhalten soll. Wenn Sie „true“ übergeben, funktioniert es wie eine Schaltfläche. - Mit
setIcon()
undsetLogo()
können Sie das Symbol oder das Logo für die Aktionsleiste zur Laufzeit definieren. - Mit
Fragment.setMenuVisibility()
können Sie die Sichtbarkeit der vom Fragment deklarierten Optionsmenüelemente aktivieren oder deaktivieren. Dies ist nützlich, wenn das Fragment der Aktivität hinzugefügt wurde, aber nicht sichtbar ist, sodass die Menüelemente ausgeblendet werden sollten. - Mit
FragmentManager.invalidateOptionsMenu()
können Sie das Menü mit Aktivitätsoptionen während verschiedener Stadien des Fragmentlebenszyklus entwerten, in denen die Verwendung der entsprechenden Methode ausActivity
möglicherweise nicht verfügbar ist.
Benutzeroberfläche und Aufrufe
Mit Android 4.0 wurden eine Vielzahl neuer Ansichten und weiterer UI-Komponenten eingeführt.
Rasterlayout
GridLayout
ist eine neue Ansichtsgruppe, bei der untergeordnete Ansichten in einem rechteckigen Raster angeordnet werden. Im Gegensatz zu TableLayout
beruht GridLayout
auf einer flachen Hierarchie und verwendet zur Strukturierung keine Zwischenansichten wie Tabellenzeilen.
Stattdessen geben untergeordnete Elemente an, welche Zeilen und Spalten sie einnehmen sollen (Zellen können sich über mehrere Zeilen und/oder Spalten erstrecken) und werden standardmäßig nacheinander über die Zeilen und Spalten des Rasters angeordnet.
Die Ausrichtung GridLayout
bestimmt, ob sequenzielle untergeordnete Elemente standardmäßig horizontal oder vertikal angeordnet sind. Der Abstand zwischen untergeordneten Elementen kann entweder mithilfe von Instanzen der neuen Space
-Ansicht oder durch Festlegen der relevanten Randparameter für untergeordnete Elemente angegeben werden.
Unter ApiDemos finden Sie Beispiele, in denen GridLayout
verwendet wird.
Texturansicht
TextureView
ist eine neue Ansicht, in der Sie einen Contentstream anzeigen können, z. B. ein Video oder eine OpenGL-Szene. TextureView
ähnelt SurfaceView
, ist aber einzigartig, da es sich wie eine normale Ansicht verhält, kein separates Fenster erstellt, sodass Sie es wie jedes andere View
-Objekt behandeln können. Beispielsweise können Sie Transformationen anwenden, sie mit ViewPropertyAnimator
animieren oder mit setAlpha()
die Deckkraft anpassen.
TextureView
funktioniert nur in einem hardwarebeschleunigten Fenster.
Weitere Informationen finden Sie in der Dokumentation zu TextureView
.
Widget wechseln
Das neue Switch
-Widget ist eine Ein-/Aus-Schaltfläche mit zwei Status, die Nutzer auf die eine Seite oder die andere Seite ziehen oder einfach darauf tippen können, um zwischen zwei Zuständen zu wechseln.
Mit den Attributen android:textOn
und android:textOff
können Sie den Text festlegen, der bei aktivierter/aus-der Einstellung auf dem Schalter angezeigt werden soll. Mit dem Attribut android:text
können Sie außerdem ein Label neben dem Schalter platzieren.
Ein Beispiel mit Switches finden Sie in der Layoutdatei switches.xml und in den entsprechenden Aktivitäten für Switches .
Pop-up-Menüs
In Android 3.0 wurde PopupMenu
zum Erstellen kurzer Kontextmenüs eingeführt, die an einem von Ihnen angegebenen Ankerpunkt eingeblendet werden (normalerweise am Punkt des ausgewählten Elements). Unter Android 4.0 wird PopupMenu
um einige nützliche Funktionen erweitert:
- Sie können den Inhalt eines Pop-up-Menüs aus einer XML-Menüressource jetzt ganz einfach mit
inflate()
erweitern und dabei die Menüressourcen-ID übergeben. - Sie können jetzt auch eine
PopupMenu.OnDismissListener
erstellen, die einen Callback empfängt, wenn das Menü geschlossen wird.
Einstellungen
Eine neue abstrakte Klasse TwoStatePreference
dient als Grundlage für Präferenzen, die eine Auswahloption mit zwei Status bieten. Das neue SwitchPreference
ist eine Erweiterung von TwoStatePreference
. Es bietet in der Einstellungsansicht ein Switch
-Widget, mit dem Nutzer eine Einstellung aktivieren oder deaktivieren können, ohne einen zusätzlichen Einstellungsbildschirm oder ein zusätzliches Dialogfeld öffnen zu müssen. Die App „Einstellungen“ verwendet beispielsweise ein SwitchPreference
für die WLAN- und Bluetooth-Einstellungen.
Systemdesigns
Das Standarddesign für alle Apps, die auf Android 4.0 ausgerichtet sind, ist jetzt das Standarddesign des Geräts: Theme.DeviceDefault
. Dazu musst du entweder targetSdkVersion
oder minSdkVersion
auf “14"
oder höher setzen. Das kann das dunkle Holo-Design oder ein anderes dunkles Design sein, das vom jeweiligen Gerät definiert wird.
Die Theme.Holo
-Designs ändern sich garantiert nicht von einem Gerät zum anderen, wenn dieselbe Android-Version ausgeführt wird. Wenn du eines der Theme.Holo
-Designs explizit auf deine Aktivitäten anwendest, kannst du beruhigt sein, dass sich diese Designs auf verschiedenen Geräten innerhalb derselben Plattformversion nicht ändern.
Wenn du möchtest, dass sich deine App in das allgemeine Gerätedesign einfügt, z. B. wenn verschiedene OEMs unterschiedliche Standarddesigns für das System bereitstellen, solltest du explizit Designs aus der Theme.DeviceDefault
-Familie anwenden.
Schaltfläche für Optionsmenü
Ab Android 4.0 werden Sie feststellen, dass auf Mobiltelefonen keine Menü-Hardwaretaste mehr erforderlich ist. Wenn Ihre vorhandene Anwendung jedoch ein Optionsmenü zur Verfügung stellt und erwartet, dass eine Menüschaltfläche vorhanden ist, müssen Sie sich darüber keine Gedanken machen. Damit vorhandene Apps weiterhin wie erwartet funktionieren, bietet das System eine Menüschaltfläche auf dem Bildschirm für Apps, die für ältere Android-Versionen entwickelt wurden.
Für eine optimale Nutzererfahrung sollten neue und aktualisierte Apps stattdessen ActionBar
verwenden, um Zugriff auf Menüelemente zu gewähren, und targetSdkVersion
auf "14"
setzen, um die neuesten Framework-Standardverhalten zu nutzen.
Steuerelemente für Sichtbarkeit der System-UI
Seit den Anfängen von Android wurde eine UI-Komponente namens Statusleiste verwaltet, die sich oben auf Mobiltelefonen befindet und Informationen wie Netzbetreibersignal, Uhrzeit, Benachrichtigungen usw. bereitstellt. In Android 3.0 wurde die Systemleiste für Tablets hinzugefügt. Sie befindet sich unten auf dem Bildschirm, um Steuerelemente für die Systemsteuerung (Startseite, Zurück usw.) sowie eine Oberfläche für Elemente bereitzustellen, die bisher über die Statusleiste bereitgestellt wurden. In Android 4.0 bietet das System eine neue Art von System-UI, die sogenannte Navigationsleiste. Die Navigationsleiste ist vielleicht eine überarbeitete Version der Systemleiste für Mobilgeräte. Sie bietet Navigationssteuerelemente für Geräte, die keine Hardware zur Bedienung haben, ohne die Benutzeroberfläche für Benachrichtigungen und die Einstellungen in der Systemleiste. Daher ist bei Geräten mit einer Navigationsleiste auch die Statusleiste oben zu sehen.
Bis heute können Sie die Statusleiste auf Mobilgeräten mithilfe der Kennzeichnung FLAG_FULLSCREEN
ausblenden. In Android 4.0 wurden die APIs, die die Sichtbarkeit der Systemleiste steuern, aktualisiert, um das Verhalten der Systemleiste und der Navigationsleiste besser widerzuspiegeln:
- Das Flag
SYSTEM_UI_FLAG_LOW_PROFILE
ersetzt das FlagSTATUS_BAR_HIDDEN
. Wenn dieses Flag festgelegt ist, wird der „Low Profile“-Modus für die System- oder Navigationsleiste aktiviert. Navigationsschaltflächen werden gedimmt und andere Elemente in der Systemleiste werden ebenfalls ausgeblendet. Diese Option ist nützlich, um immersivere Spiele zu erstellen, ohne von den Schaltflächen der Systemsteuerung abgelenkt zu werden. - Das Flag
SYSTEM_UI_FLAG_VISIBLE
ersetzt das FlagSTATUS_BAR_VISIBLE
, um festzulegen, dass die System- oder Navigationsleiste sichtbar ist. - Das
SYSTEM_UI_FLAG_HIDE_NAVIGATION
ist ein neues Flag, mit dem angefordert wird, dass die Navigationsleiste vollständig ausgeblendet wird. Dies funktioniert nur für die Navigationsleiste, die von einigen Mobilgeräten verwendet wird. Die Systemleiste wird auf Tablets nicht ausgeblendet. Die Navigationsleiste wird wieder angezeigt, sobald das System eine Nutzereingabe empfängt. Dieser Modus eignet sich daher vor allem für die Videowiedergabe oder andere Fälle, in denen der gesamte Bildschirm benötigt wird, aber keine Nutzereingabe erforderlich ist.
Du kannst diese Flags für die System- und Navigationsleiste setzen, indem du in jeder Ansicht deiner Aktivität setSystemUiVisibility()
aufrufst. Der Fenstermanager kombiniert alle Flags aus allen Ansichten in Ihrem Fenster (ODER-verkettet) und wendet sie auf die System-UI an, solange das Fenster Eingabefokus hat. Wenn der Eingabefokus Ihres Fensters nicht mehr angezeigt wird, d. h. der Nutzer die App verlässt oder ein Dialogfeld erscheint, sind Ihre Flags nicht mehr wirksam.
Dasselbe gilt, wenn Sie diese Ansichten aus der Ansichtshierarchie entfernen.
Wenn Sie andere Ereignisse in Ihrer Aktivität mit Änderungen der Sichtbarkeit der System-UI synchronisieren möchten (z. B. die Aktionsleiste oder andere UI-Steuerelemente ausblenden, wenn die System-UI ausgeblendet wird), sollten Sie einen View.OnSystemUiVisibilityChangeListener
registrieren, der benachrichtigt wird, wenn sich die Sichtbarkeit der System- oder Navigationsleiste ändert.
In der Klasse OverscanActivity finden Sie eine Demonstration der verschiedenen System-UI-Optionen.
Input Framework
Unter Android 4.0 werden jetzt auch Ereignisse beim Bewegen des Mauszeigers sowie neue Eingabestift- und Maustastenereignisse unterstützt.
Hover-Ereignisse
Die Klasse View
unterstützt jetzt „Hover“-Ereignisse, um umfassendere Interaktionen durch Zeigergeräte zu ermöglichen, z. B. eine Maus oder andere Geräte, die einen Cursor auf dem Bildschirm steuern.
Wenn Sie Hover-Ereignisse für eine Ansicht erhalten möchten, implementieren Sie View.OnHoverListener
und registrieren Sie es mit setOnHoverListener()
. Wenn ein Hover-Ereignis in der Ansicht eintritt, erhält der Listener einen Aufruf an onHover()
, der das View
-Element enthält, in dem das Ereignis empfangen wurde, und ein MotionEvent
-Element, das den Typ des aufgetretenen Hover-Ereignisses beschreibt. Das Hover-Ereignis kann eines der folgenden Ereignisse sein:
View.OnHoverListener
sollte „true“ von onHover()
zurückgeben, wenn das Hover-Ereignis verarbeitet wird. Wenn der Listener den Wert „false“ zurückgibt, wird das Hover-Ereignis wie gewohnt an die übergeordnete Ansicht gesendet.
Wenn in Ihrer App Schaltflächen oder andere Widgets verwendet werden, deren Darstellung sich je nach aktuellem Status ändert, können Sie jetzt das Attribut android:state_hovered
in einem Drawable mit Statusliste verwenden, um ein anderes Drawable für den Hintergrund bereitzustellen, wenn ein Cursor über die Ansicht bewegt wird.
Eine Demonstration der neuen Hover-Ereignisse finden Sie in der Hover-Klasse in ApiDemos.
Ereignisse für Eingabestift und Maustaste
Android bietet jetzt APIs für den Empfang von Eingaben von einem Eingabegerät für den Eingabestift, z. B. einem Digitizer-Tablet-Peripheriegerät oder einem Eingabestift-Touchscreen.
Die Eingabe mit dem Eingabestift funktioniert ähnlich wie die Eingabe per Berührung oder Maus. Wenn der Eingabestift den Digitizer berührt, empfangen Anwendungen Touch-Ereignisse wie beim Berühren des Bildschirms mit einem Finger. Wenn sich der Eingabestift über dem Digitizer befindet, empfangen Anwendungen Mouseover-Ereignisse, genau wie wenn ein Mauszeiger über den Bildschirm bewegt wird, wenn keine Tasten gedrückt werden.
Ihre Anwendung kann zwischen der Eingabe per Finger, Maus, Eingabestift und Radierer unterscheiden, indem sie den mit jedem Zeiger in einem MotionEvent
verknüpften „Tooltyp“ mithilfe von getToolType()
abfragt. Derzeit sind folgende Tooltypen definiert: TOOL_TYPE_UNKNOWN
, TOOL_TYPE_FINGER
, TOOL_TYPE_MOUSE
, TOOL_TYPE_STYLUS
und TOOL_TYPE_ERASER
. Durch Abfragen des Tooltyps kann Ihre Anwendung die Eingabe des Eingabestifts auf andere Weise als die Eingabe per Finger oder Maus verarbeiten.
Ihre Anwendung kann auch abfragen, welche Maus oder Eingabestifttasten gedrückt werden, indem der „Tastenstatus“ eines MotionEvent
mit getButtonState()
abgefragt wird. Die aktuell definierten Schaltflächenstatus sind: BUTTON_PRIMARY
, BUTTON_SECONDARY
, BUTTON_TERTIARY
, BUTTON_BACK
und BUTTON_FORWARD
. Der Einfachheit halber werden die Vor- und Zurück-Maustasten automatisch den Tasten KEYCODE_BACK
und KEYCODE_FORWARD
zugeordnet. Ihre App kann mit diesen Tasten die Mausschaltflächen auf Basis der Vor- und Zurück-Navigation unterstützen.
Neben der genauen Messung der Position und des Drucks eines Kontakts erfassen einige Eingabestifte auch den Abstand zwischen der Spitze des Eingabestifts und dem Digitalisierer sowie den Neigungswinkel des Eingabestifts und den Ausrichtungswinkel des Eingabestifts. Ihre Anwendung kann diese Informationen mithilfe von getAxisValue()
und den Achsencodes AXIS_DISTANCE
, AXIS_TILT
und AXIS_ORIENTATION
abfragen.
Eine Demonstration der Tooltypen, Schaltflächenstatus und der neuen Achsencodes findest du in der Klasse TouchPaint in ApiDemos.
Properties
Die neue Property
-Klasse bietet eine schnelle, effiziente und einfache Möglichkeit, ein Attribut für jedes Objekt anzugeben, mit dem Aufrufer Werte für Zielobjekte allgemein festlegen/abrufen können. Sie ermöglicht außerdem die Weitergabe von Feld-/Methodenreferenzen und ermöglicht, dass Code Werte der Eigenschaft festlegen/abrufen kann, ohne die Details der Felder/Methoden zu kennen.
Wenn Sie beispielsweise den Wert des Felds bar
für das Objekt foo
festlegen möchten, haben Sie bisher so vorgegangen:
Kotlin
foo.bar = value
Java
foo.bar = value;
Wenn Sie den Setter für ein zugrunde liegendes privates Feld bar
aufrufen möchten, haben Sie zuvor Folgendes ausgeführt:
Kotlin
foo.setBar(value)
Java
foo.setBar(value);
Wenn Sie jedoch die Instanz foo
umgehen und anderen Code auf den Wert bar
setzen möchten, ist dies vor Android 4.0 nicht möglich.
Mit der Klasse Property
können Sie ein Property
-Objekt BAR
in der Klasse Foo
deklarieren, sodass Sie das Feld für die Instanz foo
der Klasse Foo
so festlegen können:
Kotlin
BAR.set(foo, value)
Java
BAR.set(foo, value);
Die Klasse View
nutzt jetzt die Klasse Property
, damit Sie verschiedene Felder festlegen können, z. B. Transformationsattribute, die in Android 3.0 hinzugefügt wurden (ROTATION
, ROTATION_X
, TRANSLATION_X
usw.).
Die Klasse ObjectAnimator
verwendet auch die Klasse Property
. Sie können also eine ObjectAnimator
mit einer Property
erstellen, die schneller, effizienter und typsicherer als der stringbasierte Ansatz ist.
Hardwarebeschleunigung
Ab Android 4.0 ist die Hardwarebeschleunigung für alle Fenster standardmäßig aktiviert, wenn in Ihrer Anwendung entweder targetSdkVersion
oder minSdkVersion
auf “14"
oder höher gesetzt wurde. Die Hardwarebeschleunigung sorgt in der Regel für flüssigere Animationen, flüssigeres Scrollen sowie insgesamt eine bessere Leistung und Reaktion auf Nutzerinteraktionen.
Bei Bedarf kannst du die Hardwarebeschleunigung manuell mit dem Attribut hardwareAccelerated
für einzelne <activity>
-Elemente oder das Element <application>
deaktivieren. Alternativ können Sie die Hardwarebeschleunigung für einzelne Ansichten deaktivieren, indem Sie setLayerType(LAYER_TYPE_SOFTWARE)
aufrufen.
Weitere Informationen zur Hardwarebeschleunigung, einschließlich einer Liste nicht unterstützter Zeichenvorgänge, finden Sie im Dokument Hardwarebeschleunigung.
JNI-Änderungen
In früheren Versionen von Android waren lokale JNI-Verweise keine indirekten Handles. Android verwendete direkte Zeiger. Dies war kein Problem, solange die automatische Speicherbereinigung keine Objekte verschoben hat, aber es schien zu funktionieren, da es damit das Schreiben von fehlerhaften Code ermöglichte. In Android 4.0 verwendet das System jetzt indirekte Referenzen, um diese Fehler zu erkennen.
Ausführliche Informationen zu lokalen JNI-Referenzen findest du in den JNI-Tipps unter „Lokale und globale Referenzen“. In Android 4.0 wurde CheckJNI optimiert, um diese Fehler zu erkennen. Im Blog für Android-Entwickler finden Sie einen nächsten Beitrag über häufige Fehler bei JNI-Referenzen und wie Sie diese beheben können.
Diese Änderung in der JNI-Implementierung betrifft nur Apps, die auf Android 4.0 ausgerichtet sind. Dazu wird entweder targetSdkVersion
oder minSdkVersion
auf “14"
oder höher gesetzt. Wenn Sie diese Attribute auf einen niedrigeren Wert setzen, verhalten sich die lokalen JNI-Verweise wie in früheren Versionen.
WebKit
- WebKit wurde auf Version 534.30 aktualisiert
- Unterstützung indischer Schriftarten (Devanagari, Bengali und Tamil, einschließlich der komplexen Zeichenunterstützung, die zum Kombinieren von Glyphen erforderlich ist) in
WebView
und dem integrierten Browser - Unterstützung für äthiopische, georgische und armenische Schriftarten in
WebView
und dem integrierten Browser - Durch die Unterstützung von WebDriver lassen sich Anwendungen, die
WebView
verwenden, leichter testen.
Android-Browser
Der Browser bietet die folgenden Funktionen zur Unterstützung von Webanwendungen:
- Aktualisierter V8-JavaScript-Compiler für höhere Leistung
- Außerdem sind jetzt noch weitere wichtige Verbesserungen aus Android 3.0 für Mobilgeräte verfügbar:
- Unterstützung für Elemente mit fester Position auf allen Seiten
- HTML-Media Capture
- Ereignisse zur Geräteausrichtung
- CSS-3D-Transformationen
Berechtigungen
Dies sind neue Berechtigungen:
ADD_VOICEMAIL
: Ermöglicht einem Mailboxdienst, dem Gerät Mailboxnachrichten hinzuzufügen.BIND_TEXT_SERVICE
: Ein Dienst, derSpellCheckerService
implementiert, muss diese Berechtigung für sich selbst benötigen.BIND_VPN_SERVICE
: Ein Dienst, derVpnService
implementiert, muss diese Berechtigung für sich selbst benötigen.- android.Manifest.permission#READ_PROFILE: Bietet Lesezugriff für den Anbieter
ContactsContract.Profile
. - android.Manifest.permission#WRITE_PROFILE: Bietet Schreibzugriff für den Anbieter
ContactsContract.Profile
.
Gerätefunktionen
Dies sind die neuen Gerätefunktionen:
FEATURE_WIFI_DIRECT
: Gibt an, dass die Anwendung WLAN für Peer-to-Peer-Kommunikation verwendet.
Eine detaillierte Ansicht aller API-Änderungen in Android 4.0 (API-Level 14) finden Sie im Bericht zu API-Unterschieden.
Vorherige APIs
Zusätzlich zu den oben genannten Funktionen unterstützt Android 4.0 natürlich alle APIs früherer Releases. Da die Plattform Android 3.x nur für Geräte mit großen Bildschirmen verfügbar ist, kennen Sie möglicherweise nicht alle APIs, die in diesen aktuellen Releases zu Android hinzugefügt wurden, wenn Sie hauptsächlich für Mobilgeräte entwickelt haben.
Hier sind einige der interessantesten APIs, die Sie vielleicht übersehen haben und die jetzt auch für Mobilgeräte verfügbar sind:
- Android 3.0
-
Fragment
: Eine Framework-Komponente, mit der Sie verschiedene Elemente einer Aktivität in eigenständige Module aufteilen können, die ihre eigene UI und ihren eigenen Lebenszyklus definieren. Weitere Informationen finden Sie im Entwicklerleitfaden zu Fragmenten.ActionBar
: Ein Ersatz für die herkömmliche Titelleiste oben im Aktivitätsfenster. Sie enthält das Anwendungslogo in der linken Ecke und bietet eine neue Oberfläche für Menüpunkte. Weitere Informationen finden Sie im Entwicklerleitfaden für die Aktionsleiste.Loader
: Eine Framework-Komponente, die das asynchrone Laden von Daten in Kombination mit UI-Komponenten ermöglicht, um Daten dynamisch zu laden, ohne den Hauptthread zu blockieren. Weitere Informationen finden Sie im Entwicklerleitfaden für Loader.- Systemzwischenablage: Anwendungen können Daten (neben Text) in die und aus der systemweiten Zwischenablage kopieren und einfügen. Beschnittene Daten können Nur-Text, ein URI oder ein Intent sein. Weitere Informationen finden Sie im Entwicklerleitfaden zum Kopieren und Einfügen.
- Drag-and-drop: Eine Reihe von APIs, die in das View-Framework integriert sind und Drag-and-drop-Vorgänge unterstützen. Weitere Informationen finden Sie im Entwicklerleitfaden Drag-and-drop.
- Mit dem neuen flexiblen Animations-Framework können Sie beliebige Eigenschaften eines beliebigen Objekts animieren (View, Drawable, Fragment, Objekt usw.) und Animationsaspekte wie Dauer, Interpolation, Wiederholung und mehr definieren. Das neue Framework macht Animationen in Android einfacher denn je. Weitere Informationen finden Sie im Entwicklerleitfaden für Property-Animation.
- RenderScript-Grafik- und Compute Engine: RenderScript bietet eine leistungsstarke 3D-Grafik-Rendering- und Computing-API auf nativer Ebene, die im C99-Standard geschrieben wird. Sie bietet die Leistung, die Sie von einer nativen Umgebung erwarten, während sie auf verschiedene CPUs und GPUs übertragen werden kann. Weitere Informationen finden Sie im RenderScript-Entwicklerleitfaden.
- Hardwarebeschleunigte 2D-Grafik: Du kannst jetzt den OpenGL-Renderer für deine App aktivieren, indem du {android:hardwareAccelerated="true"} im
<application>
-Element deines Manifest-Elements oder für einzelne<activity>
-Elemente festlegst. Das Ergebnis sind flüssigere Animationen, flüssigeres Scrollen sowie insgesamt eine bessere Leistung und Reaktion auf Nutzerinteraktionen.Hinweis:Wenn Sie
minSdkVersion
odertargetSdkVersion
Ihrer Anwendung auf"14"
oder höher setzen, ist die Hardwarebeschleunigung standardmäßig aktiviert. - Und vieles, vieles mehr. Weitere Informationen finden Sie in den Hinweisen zur Android 3.0-Plattform.
- Android 3.1
-
- USB APIs: Leistungsstarke neue APIs zur Einbindung verbundener Peripheriegeräte in Android-Anwendungen Die APIs basieren auf einem USB-Stack und den in die Plattform integrierten Diensten, einschließlich Unterstützung für USB-Host- und Geräteinteraktionen. Weitere Informationen finden Sie im Entwicklerhandbuch für USB-Host und Zubehör.
- MTP/PTP-APIs: Anwendungen können direkt mit verbundenen Kameras und anderen PTP-Geräten interagieren, um Benachrichtigungen zu erhalten, wenn Geräte angehängt oder entfernt werden, Dateien und Speicher auf diesen Geräten zu verwalten sowie Dateien und Metadaten an und von ihnen zu übertragen. Die MTP API implementiert die PTP (Picture Transfer Protocol)-Teilmenge der MTP-Spezifikation (Media Transfer Protocol). Weitere Informationen finden Sie in der
android.mtp
-Dokumentation. - RTP-APIs: Android stellt eine API im integrierten RTP-Stack (Real-time Transport Protocol) bereit, mit dem Anwendungen On-Demand- oder interaktives Datenstreaming verwalten können. Insbesondere können Anwendungen, die VoIP, Push-to-Talk, Konferenzen und Audiostreaming bereitstellen, die API verwenden, um Sitzungen zu initiieren und Datenstreams über jedes verfügbare Netzwerk zu senden oder zu empfangen. Weitere Informationen finden Sie in der
android.net.rtp
-Dokumentation. - Unterstützung für Joysticks und andere allgemeine Bewegungseingaben.
- In den Hinweisen zur Android 3.1-Plattform finden Sie viele weitere neue APIs.
- Android 3.2
-
- Neue Bildschirme unterstützen APIs, mit denen Sie besser steuern können, wie Ihre Anwendungen auf verschiedenen Bildschirmgrößen angezeigt werden. Die API erweitert das vorhandene Bildschirmunterstützungsmodell um die Möglichkeit, bestimmte Bildschirmgrößenbereiche präzise anhand von Dimensionen abzudecken. 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. Dies ist beispielsweise wichtig, damit Sie zwischen einem 5"- und einem 7"-Gerät unterscheiden können, die beide traditionell als "große" Bildschirme kategorisiert würden. Weitere Informationen finden Sie im Blogpost Neue Tools zur Verwaltung von Bildschirmgrößen.
- Neue Konstanten für
<uses-feature>
zur Angabe von Anforderungen im Quer- oder Hochformat. - Die Konfiguration für die Bildschirmgröße des Geräts ändert sich jetzt, wenn die Bildschirmausrichtung geändert wird. Wenn Ihre Anwendung auf API-Level 13 oder höher ausgerichtet ist, müssen Sie die Konfigurationsänderung
"screenSize"
verarbeiten, wenn Sie auch die Konfigurationsänderung"orientation"
verarbeiten möchten. Weitere Informationen finden Sie unterandroid:configChanges
. - Informationen zu anderen neuen APIs finden Sie in den Hinweisen zur Android 3.2-Plattform.
API-Ebene
Der Android 4.0 API wird eine Ganzzahl-ID (14) zugewiesen, die im System selbst gespeichert wird. Diese Kennung, die als „API-Ebene“ bezeichnet wird, ermöglicht dem System, vor der Installation der Anwendung korrekt zu bestimmen, ob eine Anwendung mit dem System kompatibel ist.
Wenn Sie in Android 4.0 eingeführte APIs in Ihrer App verwenden möchten, müssen Sie die App mithilfe einer Android-Plattform kompilieren, die API-Level 14 oder höher unterstützt. Je nach Ihren Anforderungen müssen Sie dem Element <uses-sdk>
möglicherweise auch ein android:minSdkVersion="14"
-Attribut hinzufügen.
Weitere Informationen finden Sie unter Was ist das API-Level?