APIs unter Android 4.0

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 in MAX_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:

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:

  1. Sie müssen an ein GL_TEXTURE_2D-Texturbild gebunden sein.
  2. 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:

  1. Rufe EffectContext.createWithCurrentGlContext() aus deinem OpenGL ES 2.0-Kontext auf.
  2. Verwenden Sie das zurückgegebene EffectContext, um EffectContext.getFactory() aufzurufen, das eine Instanz von EffectFactory zurückgibt.
  3. Rufen Sie createEffect() auf und übergeben Sie einen Effektnamen aus @link android.media.effect.EffectFactory}, z. B. EFFECT_FISHEYE oder EFFECT_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 Berechtigung INTERNET erforderlich. Wenn Sie MediaPlayer zum Abspielen von Inhalten aus dem Internet verwenden, müssen Sie Ihrem Manifest die Berechtigung INTERNET hinzufügen. Andernfalls funktioniert die Medienwiedergabe ab Android 4.0 nicht.
  • Mit setSurface() können Sie einen Surface 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 Sie isVideoSnapshotSupported() 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() und setAutoWhiteBalanceLock() 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 und NdefMessage während der onCreate()-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 die NdefMessage 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 Methode createNdefMessage() gibt dann das NdefMessage zurück, das Sie senden möchten. Übergeben Sie dann die Implementierung NfcAdapter.CreateNdefMessageCallback an setNdefPushMessageCallback().

    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 die NdefMessage abzurufen, die Sie senden möchten. So können Sie festlegen, dass NdefMessage 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 noch mehr

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 ein WifiP2pDeviceList bereit, mit dem du ein WifiP2pDevice-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 ein WifiP2pGroup-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 ein WifiP2pInfo-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:

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 an BluetoothHealthCallback 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 den BluetoothHealth-APIs verwenden.

Weitere Informationen zur Verwendung des Bluetooth Health Profile findest du in der Dokumentation zu BluetoothHealth.

Barrierefreiheit

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:

  1. Beim Aufruf erfolgen die Methoden sendAccessibilityEvent() und sendAccessibilityEventUnchecked() auf onInitializeAccessibilityEvent().

    Bei benutzerdefinierten Implementierungen von View kann onInitializeAccessibilityEvent() implementiert werden, um zusätzliche Informationen zur Barrierefreiheit an die AccessibilityEvent 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.

  2. 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 den onPopulateAccessibilityEvent()-Callback zurückgreift.

    In benutzerdefinierten Implementierungen von View sollte normalerweise onPopulateAccessibilityEvent() implementiert werden, um dem AccessibilityEvent zusätzlichen Textinhalt hinzuzufügen, wenn der android:contentDescription-Text fehlt oder nicht ausreicht. Rufen Sie getText().add() auf, um eine weitere Textbeschreibung für AccessibilityEvent hinzuzufügen.

  3. An dieser Stelle übergibt View das Ereignis in der Ansichtshierarchie nach oben, indem requestSendAccessibilityEvent() in der übergeordneten Ansicht aufgerufen wird. Jede übergeordnete Ansicht hat dann die Möglichkeit, die Informationen zur Barrierefreiheit durch Hinzufügen einer AccessibilityRecord zu erweitern, bis sie die Stammansicht erreicht, die das Ereignis mit sendAccessibilityEvent() an die AccessibilityManager 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:

  1. Nach dem Empfang eines AccessibilityEvent von einer Anwendung rufen Sie AccessibilityEvent.getRecord() auf, um eine bestimmte AccessibilityRecord abzurufen. An das Ereignis können mehrere Datensätze angehängt sein.
  2. Von AccessibilityEvent oder einer einzelnen AccessibilityRecord können Sie getSource() aufrufen, um ein AccessibilityNodeInfo-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 von AccessibilityEvent zurückgegebene AccessibilityNodeInfo-Objekt beschreibt die Ereignisquelle, während die Quelle von einem AccessibilityRecord den Vorgänger der Ereignisquelle beschreibt.

  3. Mit AccessibilityNodeInfo können Sie Informationen dazu abfragen, getParent() oder getChild() 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.:

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 Engine start() aufrufen, um anzugeben, dass die Engine für die Übermittlung der Audiodaten bereit ist. Danach muss audioAvailable() aufgerufen und die Audiodaten in einem Byte-Zwischenspeicher übergeben werden. Sobald die Suchmaschine alle Audiodaten durch den Zwischenspeicher übergeben hat, rufen Sie done() 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() und setLogo() 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 aus Activity 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 .

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 Flag STATUS_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 Flag STATUS_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:

Berechtigungen

Dies sind neue Berechtigungen:

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 oder targetSdkVersion 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 unter android: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?