Konzepte und Jetpack Compose-Implementierung
Ressourcen sind die zusätzlichen Dateien und statischen Inhalte, die von Ihrem Code verwendet werden, z. B. Bitmaps, Layoutdefinitionen, Strings für die Benutzeroberfläche und Animationsanweisungen.
Lagern Sie App-Ressourcen wie Bilder und Strings immer aus Ihrem Code aus, damit Sie sie unabhängig verwalten können. Außerdem können Sie alternative Ressourcen für bestimmte Gerätekonfigurationen bereitstellen, indem Sie sie in speziell benannten Ressourcenverzeichnissen gruppieren. Zur Laufzeit verwendet Android die entsprechende Ressource basierend auf der aktuellen Konfiguration. Beispielsweise möchten Sie je nach Bildschirmgröße ein anderes UI-Layout oder je nach Spracheinstellung andere Strings bereitstellen.
Sobald Sie Ihre App-Ressourcen externalisiert haben, können Sie über Ressourcen-IDs darauf zugreifen, die in der Klasse R Ihres Projekts generiert werden. In diesem Dokument wird beschrieben, wie Sie die Ressourcen in Ihrem Android-Projekt gruppieren. Außerdem erfahren Sie, wie Sie alternative Ressourcen für bestimmte Gerätekonfigurationen bereitstellen und dann über Ihren App-Code oder andere XML-Dateien darauf zugreifen.
Ressourcentypen gruppieren
Platzieren Sie jeden Ressourcentyp in einem bestimmten Unterverzeichnis des res/-Verzeichnisses Ihres Projekts. Hier sehen Sie beispielsweise die Dateihierarchie für ein einfaches Projekt:
MyProject/
src/
MyActivity.java
res/
drawable/
graphic.png
layout/
main.xml
info.xml
mipmap/
icon.png
values/
strings.xml
Das Verzeichnis res/ enthält alle Ressourcen in seinen Unterverzeichnissen: eine Bildressource, zwei Layoutressourcen, ein mipmap/-Verzeichnis für Launcher-Symbole und eine String-Ressourcendatei. Die Namen der Ressourcenverzeichnisse sind wichtig und werden in Tabelle 1 beschrieben.
Tabelle 1: Im Projektverzeichnis res/ werden folgende Ressourcenverzeichnisse unterstützt.
Verzeichnis |
Ressourcentyp |
|
|
XML-Dateien, in denen Eigenschaftsanimationen definiert sind. |
|
|
XML-Dateien, in denen Tween-Animationen definiert werden. Property-Animationen können auch in diesem Verzeichnis gespeichert werden. Das Verzeichnis |
|
|
XML-Dateien, die eine Zustandsliste von Farben definieren. Weitere Informationen finden Sie unter Ressource für Farbstatusliste. |
|
|
Bitmap-Dateien (PNG, .
Weitere Informationen finden Sie unter Drawable-Ressourcen. |
|
|
Drawable-Dateien für verschiedene Launcher-Symbol-Dichten. Weitere Informationen zum Verwalten von Launcher-Symbolen mit |
|
|
XML-Dateien, die ein Layout für die Benutzeroberfläche definieren. Weitere Informationen finden Sie unter Layout-Ressource. |
|
|
XML-Dateien, in denen App-Menüs wie ein Optionsmenü, ein Kontextmenü oder ein Untermenü definiert werden. Weitere Informationen finden Sie unter Menüressource. |
|
|
Beliebige Dateien, die im Rohformat gespeichert werden sollen. Wenn Sie diese Ressourcen mit einem Roh- Wenn Sie jedoch Zugriff auf die ursprünglichen Dateinamen und die Dateihierarchie benötigen, sollten Sie Ressourcen im Verzeichnis |
|
|
XML-Dateien, die einfache Werte wie Strings, Ganzzahlen und Farben enthalten. Während in XML-Ressourcendateien in anderen Da jede Ressource mit einem eigenen XML-Element definiert wird, können Sie die Datei beliebig benennen und verschiedene Ressourcentypen in einer Datei platzieren. Aus Gründen der Übersichtlichkeit sollten Sie eindeutige Ressourcentypen jedoch in verschiedenen Dateien platzieren. Hier sind einige Beispiele für Dateinamenkonventionen für Ressourcen, die Sie in diesem Verzeichnis erstellen können:
Weitere Informationen finden Sie unter String-Ressourcen, Stilressourcen und Weitere Ressourcentypen. |
|
|
Beliebige XML-Dateien, die zur Laufzeit durch Aufrufen von |
|
|
Schriftartdateien mit Erweiterungen wie TTF, OTF oder TTC oder XML-Dateien, die ein |
Die Ressourcen, die Sie in den in Tabelle 1 definierten Unterverzeichnissen speichern, sind Ihre Standardressourcen. Diese Ressourcen definieren das Standarddesign und den Standardinhalt für Ihre App. Für verschiedene Arten von Android-Geräten sind jedoch möglicherweise unterschiedliche Arten von Ressourcen erforderlich.
Sie können beispielsweise verschiedene Layoutressourcen für Geräte mit größeren als normalen Bildschirmen bereitstellen, um den zusätzlichen Bildschirmplatz optimal zu nutzen. Sie können auch verschiedene String-Ressourcen bereitstellen, die den Text in Ihrer Benutzeroberfläche basierend auf der Spracheinstellung des Geräts übersetzen. Wenn Sie diese verschiedenen Ressourcen für verschiedene Gerätekonfigurationen bereitstellen möchten, müssen Sie zusätzlich zu Ihren Standardressourcen alternative Ressourcen angeben.
Alternative Ressourcen bereitstellen
Die meisten Apps bieten alternative Ressourcen zur Unterstützung bestimmter Gerätekonfigurationen. Fügen Sie beispielsweise alternative Drawables für verschiedene Bildschirmdichten und alternative String-Ressourcen für verschiedene Sprachen ein. Zur Laufzeit erkennt Android die aktuelle Gerätekonfiguration und lädt die entsprechenden Ressourcen für Ihre App.
Abbildung 1: Zwei Geräte, die je nach Bildschirmgröße unterschiedliche Layoutressourcen verwenden.
So geben Sie konfigurationsspezifische Alternativen für eine Reihe von Ressourcen an:
Erstellen Sie in
res/ein neues Verzeichnis mit dem Namen<resources_name>-<qualifier>.<resources_name>ist der Verzeichnisname der entsprechenden Standardressourcen (in Tabelle 1 definiert).<qualifier>ist ein Name, der eine einzelne Konfiguration angibt, für die diese Ressourcen verwendet werden sollen (in Tabelle 2 definiert).
Sie können mehrere
<qualifier>anhängen. Trennen Sie die einzelnen Elemente durch einen Bindestrich.Speichern Sie die entsprechenden alternativen Ressourcen in diesem neuen Verzeichnis. Die Ressourcendateien müssen genau wie die Standardressourcendateien benannt werden.
Hier sind einige Standard- und alternative Ressourcen:
res/
drawable/
icon.png
background.png
drawable-hdpi/
icon.png
background.png
Der Qualifizierer hdpi gibt an, dass die Ressourcen in diesem Verzeichnis für Geräte mit einem Bildschirm mit hoher Dichte bestimmt sind. Die Bilder in diesen Drawable-Verzeichnissen sind für bestimmte Bildschirmdichten optimiert, die Dateinamen sind jedoch identisch.
So bleibt die Ressourcen-ID, mit der Sie auf das icon.png- oder background.png-Bild verweisen, immer gleich. Android wählt die Version jeder Ressource aus, die am besten zum aktuellen Gerät passt. Dazu werden die Gerätekonfigurationsinformationen mit den Qualifizierern im Namen des Ressourcenverzeichnisses verglichen.
In Tabelle 2 sind die gültigen Konfigurationsqualifizierer in der Reihenfolge ihrer Priorität aufgeführt. Sie können einem Verzeichnisnamen mehrere Qualifizierer hinzufügen, indem Sie die einzelnen Qualifizierer durch einen Bindestrich trennen. Wenn Sie mehrere Qualifizierer für ein Ressourcenverzeichnis verwenden, müssen Sie sie in der Reihenfolge, in der sie in der Tabelle aufgeführt sind, dem Verzeichnisnamen hinzufügen.
Tabelle 2: Namen von Konfigurationskennzeichnern.
Konfiguration |
Qualifierwerte |
Beschreibung |
MCC und MNC |
Beispiele:
|
Der Ländercode des Mobilgeräts (Mobile Country Code, MCC), optional gefolgt vom Netzwerkcode des Mobilgeräts (Mobile Network Code, MNC) der SIM-Karte im Gerät. Beispiele: Wenn das Gerät eine Funkverbindung verwendet (d. h. ein GSM-Telefon ist), stammen die MCC- und MNC-Werte von der SIM-Karte. Sie können auch nur den MCC verwenden, um beispielsweise länderspezifische rechtliche Ressourcen in Ihre App aufzunehmen. Wenn Sie nur anhand der Sprache angeben müssen, verwenden Sie stattdessen den Qualifier Sprache, Schriftsystem (optional) und Region (optional). Wenn Sie den Qualifikator „MCC“ und „MNC“ verwenden, gehen Sie sorgfältig vor und testen Sie, ob er wie erwartet funktioniert. Sehen Sie sich auch die Konfigurationsfelder |
Sprache, Schriftart (optional) und Region (optional) |
Beispiele:
|
Die Sprache wird durch einen zweistelligen ISO 639-2-Sprachcode{:.external} definiert, optional gefolgt von einem zweistelligen ISO 3166-1-Alpha-2-Regionscode{:.external} (vorangestellt durch Kleinbuchstaben Bei den Codes wird nicht zwischen Groß- und Kleinschreibung unterschieden. Das Präfix Mit Android 7.0 (API-Level 24) wurde die Unterstützung für BCP 47-Sprachentags{:.external} eingeführt, mit denen Sie sprach- und regionsspezifische Ressourcen qualifizieren können. Ein Sprach-Tag besteht aus einer Sequenz von einem oder mehreren Untertags, die jeweils den Bereich der durch das gesamte Tag identifizierten Sprache verfeinern oder eingrenzen. Weitere Informationen zu Sprach-Tags finden Sie unter Tags zur Identifizierung von Sprachen{:.external}. Um einen BCP 47-Sprachcode zu verwenden, hängen Sie Das Sprach-Tag kann sich im Laufe der Lebensdauer Ihrer App ändern, wenn Nutzer die Sprache in den Systemeinstellungen ändern. Informationen dazu, wie sich das auf Ihre App während der Laufzeit auswirken kann, finden Sie unter Konfigurationsänderungen verarbeiten. Eine vollständige Anleitung zur Lokalisierung Ihrer App für andere Sprachen finden Sie unter App lokalisieren. Sehen Sie sich auch die Methode |
| Genus | masculinefeminineneuter |
Das grammatische Geschlecht des Nutzers. Wird für Sprachen mit grammatischem Geschlecht verwendet. Wenn Sie beispielsweise unterschiedliche Ressourcen für französischsprachige Nutzer bereitstellen müssen, können Sie Verzeichnisse wie die folgenden verwenden:
Weitere Informationen finden Sie unter Grammatische Form in Android. Weitere Informationen finden Sie unter der In API-Level 34 hinzugefügt. |
Layoutrichtung |
|
Die Layoutrichtung Ihrer App. Das kann für jede Ressource gelten, z. B. für Layouts, Drawables oder Werte. Wenn Sie beispielsweise ein bestimmtes Layout für Arabisch und ein allgemeines Layout für alle anderen linksläufigen Sprachen wie Persisch oder Hebräisch bereitstellen möchten, verwenden Sie Verzeichnisse wie die folgenden:
Hinweis: Wenn Sie Funktionen für das Layout von rechts nach links für Ihre App aktivieren möchten, müssen Sie In API-Level 17 hinzugefügt. |
Geringste Breite |
Beispiele:
usw. |
Die kürzeste Abmessung des Bildschirmbereichs, der einer App zur Verfügung steht. Konkret ist die Wenn für Ihr Layout beispielsweise immer eine Mindestbreite von 600 dp erforderlich ist, können Sie diesen Qualifizierer verwenden, um die Layoutressourcen in einem Die Verwendung der kleinsten Breite zur Bestimmung der allgemeinen Bildschirmgröße ist nützlich, da die Breite oft der entscheidende Faktor beim Entwerfen eines Layouts ist. Eine Benutzeroberfläche wird oft vertikal gescrollt, hat aber ziemlich strenge Einschränkungen hinsichtlich des horizontalen Mindestplatzes. Die verfügbare Breite ist auch der entscheidende Faktor dafür, ob für Smartphones ein Layout mit einem Bereich oder für Tablets ein Layout mit mehreren Bereichen verwendet wird. Daher ist es für Sie wahrscheinlich am wichtigsten, die kleinstmögliche Breite auf jedem Gerät zu kennen. Bei der kleinsten Breite eines Geräts werden Bildschirmdekorationen und die System-UI berücksichtigt. Wenn das Gerät beispielsweise dauerhafte UI-Elemente auf dem Bildschirm hat, die Platz entlang der Achse der kleinsten Breite einnehmen, deklariert das System die kleinste Breite als kleiner als die tatsächliche Bildschirmgröße, da diese Bildschirmpixel nicht für Ihre Benutzeroberfläche verfügbar sind. Hier sind einige Werte, die Sie für gängige Bildschirmgrößen verwenden können:
Wenn Ihre App mehrere Ressourcenverzeichnisse mit unterschiedlichen Werten für den In API-Level 13 hinzugefügt. Sehen Sie sich auch das Attribut Weitere Informationen zum Entwerfen für verschiedene Bildschirme mit diesem Qualifizierer finden Sie unter Responsives/adaptives Design mit Ansichten. |
Verfügbare Breite und Höhe |
Beispiele:
usw. |
Gibt die minimale verfügbare Bildschirmbreite oder ‑höhe (in Die verfügbare Breite und Höhe sind oft nützlich, um zu bestimmen, ob ein Layout mit mehreren Bereichen verwendet werden soll. Selbst auf einem Tablet ist das Layout mit mehreren Bereichen im Hochformat oft nicht dasselbe wie im Querformat. Sie können damit also die für das Layout erforderliche Mindestbreite und/oder ‑höhe angeben, anstatt die Qualifizierer für Bildschirmgröße und ‑ausrichtung zusammen zu verwenden. Wenn Ihre App mehrere Ressourcenverzeichnisse mit unterschiedlichen Werten für diese Konfigurationen bereitstellt, verwendet das System das Verzeichnis, das der aktuellen Bildschirmbreite des Geräts am nächsten kommt (ohne sie zu überschreiten). Am nächsten wird ermittelt, indem die Differenzen zwischen der tatsächlichen Bildschirmbreite und der angegebenen Breite zur Differenz zwischen der tatsächlichen Bildschirmhöhe und der angegebenen Höhe addiert werden. Nicht angegebene Höhen und Breiten haben den Wert 0. Die Werte schließen den Bereich aus, der von Fenstereinsätzen belegt wird. Wenn das Gerät also dauerhafte UI-Elemente an den Rändern des Displays hat, sind die Werte für Breite und Höhe kleiner als die tatsächlichen Bildschirmabmessungen, auch wenn die App mit Einige vertikale Bildschirmdekorationen, die nicht fixiert sind (z. B. eine Telefonstatusleiste, die im Vollbildmodus ausgeblendet werden kann), werden hier nicht berücksichtigt. Das gilt auch für Fensterdekorationen wie die Titelleiste oder die Aktionsleiste. Apps müssen also mit einem etwas kleineren Bereich als angegeben zurechtkommen. Hinweis: Das System wählt die Ressource aus, die sowohl in Breite als auch in Höhe übereinstimmt. Daher ist eine Ressource, die beide angibt, einer Ressource, die nur eine der beiden angibt, vorzuziehen. Wenn der tatsächliche Bildschirm beispielsweise 720 dp breit und 1.280 dp hoch ist und eine Ressource mit w720dp und eine andere mit w700dp-h1200dp qualifiziert ist, wird die zweite Ressource ausgewählt, obwohl die erste genau mit den angegebenen Werten übereinstimmt. In API-Level 13 hinzugefügt. Sehen Sie sich auch die Konfigurationsfelder Weitere Informationen zum Entwerfen für verschiedene Bildschirme mit diesem Qualifizierer finden Sie unter Responsives/adaptives Design mit Ansichten. |
Bildschirmgröße |
|
Hinweis: Die Verwendung eines Größenqualifizierers bedeutet nicht, dass die Ressourcen nur für Bildschirme dieser Größe bestimmt sind. Wenn Sie keine alternativen Ressourcen mit Qualifizierern bereitstellen, die besser zur aktuellen Gerätekonfiguration passen, kann das System die Ressourcen verwenden, die am besten passen. Achtung: Wenn alle Ihre Ressourcen einen Größenqualifizierer verwenden, der größer als der aktuelle Bildschirm ist, verwendet das System sie nicht und Ihre App stürzt zur Laufzeit ab. Das ist beispielsweise der Fall, wenn alle Layoutressourcen mit dem Qualifikator In API-Level 4 hinzugefügt. Sehen Sie sich auch das Konfigurationsfeld Weitere Informationen finden Sie unter Bildschirmkompatibilität – Übersicht. |
Bildformat |
|
In API-Level 4 hinzugefügt. Das hängt nur vom Seitenverhältnis des Bildschirms ab (ein Sehen Sie sich auch das Konfigurationsfeld |
Rundes Display |
|
In API-Level 23 hinzugefügt. Sehen Sie sich auch die |
Breite Farbskala |
|
Hinzugefügt in API-Level 26. Weitere Informationen finden Sie unter |
High Dynamic Range (HDR) |
|
Hinzugefügt in API-Level 26. Weitere Informationen finden Sie unter |
Bildschirmausrichtung |
|
Dies kann sich im Laufe der Nutzung Ihrer App ändern, wenn der Nutzer den Bildschirm dreht. Informationen dazu, wie sich das auf Ihre App während der Laufzeit auswirkt, finden Sie unter Konfigurationsänderungen verarbeiten. Weitere Informationen finden Sie auch im Konfigurationsfeld |
UI-Modus |
|
Hinzugefügt in API-Level 8; Fernseher hinzugefügt in API 13; Haushaltsgerät hinzugefügt in API 16; Smartwatch hinzugefügt in API 20; VR-Headset hinzugefügt in API 26. Informationen dazu, wie Ihre App reagieren kann, wenn das Gerät in ein Dock eingesetzt oder aus einem Dock entfernt wird, finden Sie unter Dockingstatus und ‑typ ermitteln und überwachen. Dies kann sich im Laufe der Lebensdauer Ihrer App ändern, wenn der Nutzer das Gerät in ein Dock stellt. Einige dieser Modi lassen sich über |
Nachtmodus |
|
In API-Level 8 hinzugefügt. Das kann sich im Laufe der Lebensdauer Ihrer App ändern, wenn der Nachtmodus im automatischen Modus (Standard) belassen wird. In diesem Fall ändert sich der Modus je nach Tageszeit. Sie können diesen Modus mit |
Pixeldichte des Displays (dpi) |
|
Zwischen den sechs primären Dichten (ohne die tvdpi-Dichte) besteht ein Skalierungsverhältnis von 3:4:6:8:12:16. Eine 9 × 9-Bitmap in ldpi ist also 12 × 12 in mdpi, 18 × 18 in hdpi, 24 × 24 in xhdpi usw. Hinweis: Die Verwendung eines Pixeldichte-Kennzeichners bedeutet nicht, dass die Ressourcen nur für Bildschirme mit dieser Dichte bestimmt sind. Wenn Sie keine alternativen Ressourcen mit Qualifizierern bereitstellen, die besser zur aktuellen Gerätekonfiguration passen, verwendet das System die Ressourcen, die am besten passen. Weitere Informationen zum Umgang mit verschiedenen Bildschirmdichten und dazu, wie Android Ihre Bitmaps an die aktuelle Dichte anpasst, finden Sie unter Bildschirmkompatibilität – Übersicht. |
Touchscreentyp |
|
Weitere Informationen finden Sie auch im Konfigurationsfeld |
Verfügbarkeit der Tastatur |
|
Wenn Sie Dies kann sich während der Lebensdauer Ihrer App ändern, wenn der Nutzer eine Hardwaretastatur öffnet. Informationen dazu, wie sich das auf Ihre App während der Laufzeit auswirkt, finden Sie unter Konfigurationsänderungen verarbeiten. Sehen Sie sich auch die Konfigurationsfelder |
Primäre Texteingabemethode |
|
Sehen Sie sich auch das Konfigurationsfeld |
Verfügbarkeit von Navigationstasten |
|
Das kann sich im Laufe der Lebensdauer Ihrer App ändern, wenn der Nutzer die Navigationstasten einblendet. Informationen dazu, wie sich das auf Ihre App während der Laufzeit auswirkt, finden Sie unter Konfigurationsänderungen verarbeiten. Sehen Sie sich auch das Konfigurationsfeld |
Primäre Navigationsmethode ohne Touch-Bedienung |
|
Sehen Sie sich auch das Konfigurationsfeld |
Plattformversion (API-Level) |
Beispiele:
usw. |
Das vom Gerät unterstützte API-Level. Beispiel: |
Regeln für Namen von Qualifizierern
Hier sind einige Regeln für die Verwendung von Konfigurationsqualifizierernamen:
- Sie können mehrere Qualifizierer für eine einzelne Gruppe von Ressourcen angeben, die durch Bindestriche getrennt sind.
drawable-en-rUS-landgilt beispielsweise für Geräte mit US-Englisch im Querformat. - Die Qualifizierer müssen in der Reihenfolge aufgeführt sein, die in Tabelle 2 angegeben ist.
- Falsch:
drawable-hdpi-port/ - Richtig:
drawable-port-hdpi/
- Falsch:
- Alternative Ressourcenverzeichnisse können nicht verschachtelt werden.
res/drawable/drawable-en/ist beispielsweise nicht zulässig. - Bei den Werten wird die Groß- und Kleinschreibung nicht berücksichtigt. Der Ressourcencompiler konvertiert Verzeichnisnamen vor der Verarbeitung in Kleinbuchstaben, um Probleme auf Dateisystemen zu vermeiden, bei denen die Groß-/Kleinschreibung keine Rolle spielt. Die Großschreibung in den Namen dient nur der Lesbarkeit.
- Es wird nur ein Wert für jeden Qualifizierertyp unterstützt. Wenn Sie beispielsweise dieselben Drawable-Dateien für Spanien und Frankreich verwenden möchten, dürfen Sie kein Verzeichnis mit dem Namen
drawable-es-fr/haben. Stattdessen benötigen Sie zwei Ressourcenverzeichnisse, z. B.drawable-es/unddrawable-fr/, die die entsprechenden Dateien enthalten. Sie müssen die Dateien jedoch nicht tatsächlich an beiden Speicherorten duplizieren. Stattdessen können Sie einen Alias für eine Ressource erstellen, wie im Abschnitt Aliasressourcen erstellen beschrieben.
Nachdem Sie alternative Ressourcen in Verzeichnissen gespeichert haben, die mit diesen Qualifizierern benannt sind, wendet Android die Ressourcen in Ihrer App automatisch basierend auf der aktuellen Gerätekonfiguration an. Jedes Mal, wenn eine Ressource angefordert wird, sucht Android nach alternativen Ressourcenverzeichnissen, die die angeforderte Ressourcendatei enthalten, und findet dann die am besten passende Ressource.
Wenn es keine alternativen Ressourcen gibt, die einer bestimmten Gerätekonfiguration entsprechen, verwendet Android die entsprechenden Standardressourcen. Das sind die Ressourcen für einen bestimmten Ressourcentyp, die keinen Konfigurationsqualifizierer enthalten.
Aliasressourcen erstellen
Wenn Sie eine Ressource haben, die Sie für mehr als eine Gerätekonfiguration verwenden möchten, aber nicht als Standardressource bereitstellen möchten, müssen Sie sie nicht in mehr als ein alternatives Ressourcenverzeichnis einfügen. Stattdessen können Sie eine alternative Ressource erstellen, die als Alias für eine Ressource dient, die in Ihrem Standardressourcenverzeichnis gespeichert ist.
Angenommen, Sie haben ein App-Symbol (icon.png) und benötigen eine eindeutige Version davon für verschiedene Sprachen. Für die beiden Sprachen Englisch (Kanada) und Französisch (Kanada) muss jedoch dieselbe Version verwendet werden. Sie müssen dasselbe Bild nicht in das Verzeichnis der Ressourcen für Englisch-Kanada und Französisch-Kanada kopieren.
Stattdessen können Sie das Bild, das für beide verwendet wird, unter einem beliebigen Namen außer
icon.png speichern, z. B. icon_ca.png, und es in das Standardverzeichnis res/drawable/ einfügen. Erstellen Sie dann in res/drawable-en-rCA/ und res/drawable-fr-rCA/ eine icon.xml-Datei, die mit dem Element <bitmap> auf die icon_ca.png-Ressource verweist. So können Sie nur eine Version der PNG-Datei und zwei kleine XML-Dateien speichern, die darauf verweisen. Weitere Informationen finden Sie in den Beispielen in den folgenden Abschnitten.
Drawable
Verwenden Sie das Element <drawable>, um einen Alias für eine vorhandene Drawable zu erstellen:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<drawable name="icon">@drawable/icon_ca</drawable>
</resources>
Wenn Sie diese Datei als icon.xml in einem alternativen Ressourcenverzeichnis wie res/values-en-rCA/ speichern, wird sie in eine Ressource kompiliert, auf die Sie als R.drawable.icon verweisen können. Sie ist jedoch eigentlich ein Alias für die Ressource R.drawable.icon_ca, die in res/drawable/ gespeichert ist.
Layout
Verwenden Sie das <include>-Element, das in ein <merge>-Element eingeschlossen ist, um einen Alias für ein vorhandenes Layout zu erstellen:
<?xml version="1.0" encoding="utf-8"?>
<merge>
<include layout="@layout/main_ltr"/>
</merge>
Wenn Sie diese Datei als main.xml speichern, wird sie in eine Ressource kompiliert, auf die Sie als R.layout.main verweisen können. Sie ist jedoch eigentlich ein Alias für die R.layout.main_ltr-Ressource.
Auf App-Ressourcen zugreifen
Wenn Sie eine Ressource in Ihrer Anwendung bereitgestellt haben, können Sie sie anwenden, indem Sie auf ihre Ressourcen-ID verweisen. Alle Ressourcen-IDs sind in der Klasse R Ihres Projekts definiert, die vom Tool aapt automatisch generiert wird.
Wenn Ihre Anwendung kompiliert wird, generiert aapt die Klasse R, die Ressourcen-IDs für alle Ressourcen in Ihrem res/-Verzeichnis enthält. Für jeden Ressourcentyp gibt es eine R-Unterklasse, z. B. R.drawable für alle Drawables. Für jede Ressource dieses Typs gibt es eine statische Ganzzahl, z. B. R.drawable.icon. Diese Ganzzahl ist die Ressourcen-ID, mit der Sie Ihre Ressource abrufen können.
Obwohl die Ressourcen-IDs in der Klasse R angegeben werden, müssen Sie dort nicht nach einer Ressourcen-ID suchen. Eine Ressourcen-ID besteht immer aus Folgendem:
- Der Ressourcentyp: Jede Ressource wird in einen „Typ“ gruppiert, z. B.
string, drawableundlayout. Weitere Informationen zu den verschiedenen Typen finden Sie unter Ressourcentypen – Übersicht. - Der Ressourcennamen, der entweder der Dateiname ohne die Erweiterung oder der Wert im XML-Attribut
android:nameist, wenn die Ressource ein einfacher Wert wie ein String ist.
Es gibt zwei Möglichkeiten, auf eine Ressource zuzugreifen:
- Im Code: Verwenden Sie eine statische Ganzzahl aus einer untergeordneten Klasse Ihrer
R-Klasse, z. B.:R.string.hellostringist der Ressourcentyp undhelloder Ressourcenname. Es gibt viele Android-APIs, die auf Ihre Ressourcen zugreifen können, wenn Sie eine Ressourcen-ID in diesem Format angeben. Weitere Informationen finden Sie im Abschnitt Auf Ressourcen im Code zugreifen. - In XML: mit einer speziellen XML-Syntax, die der in Ihrer
R-Klasse definierten Ressourcen-ID entspricht, z. B.:@string/hellostringist der Ressourcentyp undhelloder Ressourcenname. Sie können diese Syntax in einer XML-Ressource überall dort verwenden, wo ein Wert erwartet wird, den Sie in einer Ressource angeben. Weitere Informationen finden Sie im Abschnitt Auf Ressourcen über XML zugreifen.
Auf Ressourcen im Code zugreifen
Sie können eine Ressource im Code verwenden, indem Sie die Ressourcen-ID als Methodenparameter übergeben.
Sie können beispielsweise ein ImageView so festlegen, dass die res/drawable/myimage.png-Ressource mit setImageResource verwendet wird:
Kotlin
val imageView = findViewById(R.id.myimageview) as ImageView
imageView.setImageResource(R.drawable.myimage)
Java
ImageView imageView = (ImageView) findViewById(R.id.myimageview);
imageView.setImageResource(R.drawable.myimage);
Sie können auch einzelne Ressourcen mit Methoden in Resources abrufen, deren Instanz Sie mit getResources erhalten.
Syntax
So referenzieren Sie eine Ressource im Code:
[<package_name>.]R.<resource_type>.<resource_name>
<package_name>ist der Name des Pakets, in dem sich die Ressource befindet. Dies ist nicht erforderlich, wenn Sie auf Ressourcen aus Ihrem eigenen Paket verweisen.<resource_type>ist dieR-Unterklasse für den Ressourcentyp.<resource_name>ist entweder der Ressourcen-Dateiname ohne die Erweiterung oder derandroid:name-Attributwert im XML-Element für einfache Werte.
Anwendungsfälle
Es gibt viele Methoden, die einen Parameter für die Ressourcen-ID akzeptieren. Sie können Ressourcen mit Methoden in Resources abrufen. Sie können eine Instanz von Resources mit Context.getResources abrufen.
Hier sind einige Beispiele für den Zugriff auf Ressourcen im Code:
Kotlin
// Load a background for the current screen from a drawable resource.
window.setBackgroundDrawableResource(R.drawable.my_background_image)
// Set the Activity title by getting a string from the Resources object, because
// this method requires a CharSequence rather than a resource ID.
window.setTitle(resources.getText(R.string.main_title))
// Load a custom layout for the current screen.
setContentView(R.layout.main_screen)
// Set a slide in animation by getting an Animation from the Resources object.
flipper.setInAnimation(AnimationUtils.loadAnimation(this,
R.anim.hyperspace_in))
// Set the text on a TextView object using a resource ID.
val msgTextView = findViewById(R.id.msg) as TextView
msgTextView.setText(R.string.hello_message)
Java
// Load a background for the current screen from a drawable resource.
getWindow().setBackgroundDrawableResource(R.drawable.my_background_image) ;
// Set the Activity title by getting a string from the Resources object, because
// this method requires a CharSequence rather than a resource ID.
getWindow().setTitle(getResources().getText(R.string.main_title));
// Load a custom layout for the current screen.
setContentView(R.layout.main_screen);
// Set a slide in animation by getting an Animation from the Resources object.
flipper.setInAnimation(AnimationUtils.loadAnimation(this,
R.anim.hyperspace_in));
// Set the text on a TextView object using a resource ID.
TextView msgTextView = (TextView) findViewById(R.id.msg);
msgTextView.setText(R.string.hello_message);
Über XML auf Ressourcen zugreifen
Sie können Werte für einige XML-Attribute und -Elemente mithilfe einer Referenz auf eine vorhandene Ressource definieren. Das ist häufig der Fall, wenn Sie Layoutdateien erstellen, um Strings und Bilder für Ihre Widgets bereitzustellen.
Wenn Sie Ihrem Layout beispielsweise ein Button hinzufügen, verwenden Sie eine String-Ressource für den Schaltflächentext:
<Button
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="@string/submit" />
Syntax
Hier ist die Syntax zum Verweisen auf eine Ressource in einer XML-Ressource:
@[<package_name>:]<resource_type>/<resource_name>
<package_name>ist der Name des Pakets, in dem sich die Ressource befindet (nicht erforderlich, wenn auf Ressourcen aus demselben Paket verwiesen wird).<resource_type>ist dieR-Unterklasse für den Ressourcentyp.<resource_name>ist entweder der Ressourcen-Dateiname ohne die Erweiterung oder derandroid:name-Attributwert im XML-Element für einfache Werte.
Anwendungsfälle
In einigen Fällen müssen Sie eine Ressource für einen Wert in XML verwenden, z. B. um ein Drawable-Bild auf ein Widget anzuwenden. Sie können eine Ressource in XML aber auch überall dort verwenden, wo ein einfacher Wert akzeptiert wird. Angenommen, Sie haben die folgende Ressourcendatei mit einer Farbressource und einer String-Ressource:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<color name="opaque_red">#f00</color>
<string name="hello">Hello!</string>
</resources>
Sie können diese Ressourcen in der folgenden Layoutdatei verwenden, um die Textfarbe und den Textstring festzulegen:
<?xml version="1.0" encoding="utf-8"?>
<EditText xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:textColor="@color/opaque_red"
android:text="@string/hello" />
In diesem Fall müssen Sie den Paketnamen im Ressourcenverweis nicht angeben, da die Ressourcen aus Ihrem eigenen Paket stammen. Wenn Sie auf eine Systemressource verweisen möchten, müssen Sie den Paketnamen angeben, wie im folgenden Beispiel gezeigt:
<?xml version="1.0" encoding="utf-8"?>
<EditText xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:textColor="@android:color/secondary_text_dark"
android:text="@string/hello" />
Sie können sogar Ressourcen in XML verwenden, um Aliase zu erstellen. Sie können beispielsweise eine zeichenfähige Ressource erstellen, die ein Alias für eine andere zeichenfähige Ressource ist:
<?xml version="1.0" encoding="utf-8"?>
<bitmap xmlns:android="http://schemas.android.com/apk/res/android"
android:src="@drawable/other_drawable" />
Das klingt redundant, kann aber sehr nützlich sein, wenn Sie eine alternative Ressource verwenden. Weitere Informationen finden Sie im Abschnitt zum Erstellen von Aliasressourcen.
Attribute für Referenzstil
Mit einer Stilattributressource können Sie auf den Wert eines Attributs im aktuell angewendeten Theme verweisen. Wenn Sie auf ein Stilattribut verweisen, können Sie das Aussehen von UI-Elementen anpassen, indem Sie sie so gestalten, dass sie den Standardvariationen des aktuellen Designs entsprechen, anstatt einen hartcodierten Wert anzugeben. Wenn Sie auf ein Stilattribut verweisen, bedeutet das im Grunde: „Verwende den Stil, der durch dieses Attribut im aktuellen Design definiert ist.“
Wenn Sie auf ein Stilattribut verweisen möchten, ist die Namenssyntax fast identisch mit dem normalen Ressourcenformat. Verwenden Sie jedoch anstelle des „at“-Symbols (@) ein Fragezeichen (?). Der Ressourcentyp ist optional. Die Referenzsyntax lautet also:
?[<package_name>:][<resource_type>/]<resource_name>
So können Sie beispielsweise auf ein Attribut verweisen, um die Textfarbe an die sekundäre Textfarbe des Systemdesigns anzupassen:
<EditText id="text"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:textColor="?android:textColorSecondary"
android:text="@string/hello_world" />
Das Attribut android:textColor gibt den Namen eines Stilattributs im aktuellen Design an. Unter Android wird jetzt der Wert, der auf das Stilattribut android:textColorSecondary angewendet wird, als Wert für android:textColor in diesem Widget verwendet. Da das Systemressourcentool weiß, dass in diesem Kontext eine Attributressource erwartet wird, müssen Sie den Typ, der ?android:attr/textColorSecondary ist, nicht explizit angeben. Sie können den Typ attr ausschließen.
Auf Originaldateien zugreifen
Es kann vorkommen, dass Sie auf Ihre Originaldateien und ‑verzeichnisse zugreifen müssen. Wenn das der Fall ist, können Sie Ihre Dateien nicht in res/ speichern, da Ressourcen in res/ nur über die Ressourcen-ID gelesen werden können. Stattdessen können Sie Ihre Ressourcen im Verzeichnis assets/ speichern.
Dateien, die im Verzeichnis assets/ gespeichert sind, erhalten keine Ressourcen-ID. Sie können also nicht über die Klasse R oder über XML-Ressourcen darauf verweisen. Stattdessen können Sie Dateien im Verzeichnis assets/ wie in einem normalen Dateisystem abfragen und Rohdaten mit AssetManager lesen.
Wenn Sie jedoch nur Rohdaten (z. B. eine Video- oder Audiodatei) lesen müssen, speichern Sie die Datei im Verzeichnis res/raw/ und lesen Sie einen Stream von Byte mit openRawResource.
Auf Plattformressourcen zugreifen
Android enthält eine Reihe von Standardressourcen wie Stile, Designs und Layouts. Um auf diese Ressourcen zuzugreifen, müssen Sie Ihren Ressourcenverweis mit dem Paketnamen android qualifizieren. Android bietet beispielsweise eine Layoutressource, die Sie für Listenelemente in einem ListAdapter verwenden können:
Kotlin
listAdapter = ArrayAdapter(this, android.R.layout.simple_list_item_1, myarray)
Java
setListAdapter(new ArrayAdapter<String>(this, android.R.layout.simple_list_item_1, myarray));
In diesem Beispiel ist simple_list_item_1 eine von der Plattform definierte Layoutressource für Elemente in einem ListView. Sie können diese Option verwenden, anstatt ein eigenes Layout für Listenelemente zu erstellen.
Beste Gerätekompatibilität mit Ressourcen
Damit Ihre App mehrere Gerätekonfigurationen unterstützt, ist es sehr wichtig, dass Sie immer Standardressourcen für jeden Ressourcentyp bereitstellen, den Ihre App verwendet.
Wenn Ihre App beispielsweise mehrere Sprachen unterstützt, fügen Sie immer ein values/-Verzeichnis (in dem Ihre Strings gespeichert sind) ohne Sprach- und Regionsqualifizierer ein. Wenn Sie stattdessen alle Ihre String-Dateien in Verzeichnisse mit einem Sprach- und Regionsqualifizierer einfügen, stürzt Ihre App ab, wenn sie auf einem Gerät ausgeführt wird, das auf eine Sprache eingestellt ist, die von Ihren Strings nicht unterstützt wird.
Solange Sie Standardressourcen für values/ bereitstellen, funktioniert Ihre App ordnungsgemäß, auch wenn der Nutzer die Sprache nicht versteht, in der sie präsentiert wird. Besser als ein Absturz.
Wenn Sie verschiedene Layoutressourcen basierend auf der Bildschirmausrichtung bereitstellen, wählen Sie eine Ausrichtung als Standard aus. Anstatt beispielsweise Layoutressourcen in layout-land/ für das Querformat und in layout-port/ für das Hochformat bereitzustellen, lassen Sie eine als Standardeinstellung, z. B. layout/ für das Querformat und layout-port/ für das Hochformat.
Die Bereitstellung von Standardressourcen ist nicht nur wichtig, weil Ihre App möglicherweise in einer Konfiguration ausgeführt wird, die Sie nicht erwartet haben, sondern auch, weil in neuen Android-Versionen manchmal Konfigurationsqualifizierer hinzugefügt werden, die in niedrigeren Versionen nicht unterstützt werden. Wenn Sie einen neuen Ressourcenqualifizierer verwenden, aber die Codekompatibilität mit niedrigeren Android-Versionen beibehalten, stürzt Ihre App ab, wenn sie auf einer niedrigeren Android-Version ausgeführt wird, sofern Sie keine Standardressourcen bereitstellen. Das liegt daran, dass die Ressourcen, die mit dem neuen Qualifizierer benannt sind, nicht verwendet werden können.
Wenn Ihr minSdkVersion beispielsweise auf 4 festgelegt ist und Sie alle Ihre Drawable-Ressourcen mit dem Nachtmodus (night oder notnight, die in API-Level 8 hinzugefügt wurden) qualifizieren, kann ein Gerät mit API-Level 4 nicht auf Ihre Drawable-Ressourcen zugreifen und stürzt ab. In diesem Fall sollten notnight wahrscheinlich Ihre Standardressourcen sein. Schließen Sie diesen Qualifier also aus und legen Sie Ihre Drawable-Ressourcen entweder in drawable/ oder drawable-night/ ab.
Kurz gesagt: Um die beste Gerätekompatibilität zu gewährleisten, sollten Sie immer Standardressourcen für die Ressourcen bereitstellen, die Ihre App für eine ordnungsgemäße Funktion benötigt. Erstellen Sie dann mit Konfigurationsqualifizierern alternative Ressourcen für bestimmte Gerätekonfigurationen.
Es gibt eine Ausnahme von dieser Regel: Wenn die minSdkVersion Ihrer App 4 oder höher ist, benötigen Sie keine Standard-Drawable-Ressourcen, wenn Sie alternative Drawable-Ressourcen mit dem Qualifikator Bildschirmdichte bereitstellen. Auch ohne Standard-Drawable-Ressourcen kann Android die beste Übereinstimmung unter den alternativen Bildschirmdichten finden und die Bitmaps nach Bedarf skalieren. Für eine optimale Darstellung auf allen Gerätetypen sollten Sie jedoch alternative Drawables für alle drei Dichtetypen bereitstellen.