Ressourcen sind die zusätzlichen Dateien und statischen Inhalte, die Ihr Code verwendet, z. B. Bitmaps, Layoutdefinitionen, Benutzeroberflächen-Strings, Animationsanleitungen und mehr.
Externalisieren Sie Anwendungsressourcen wie Bilder und Strings immer aus Ihrem Code, damit Sie sie unabhängig verwalten können. Sie können auch alternative Ressourcen für bestimmte Gerätekonfigurationen bereitstellen, indem Sie sie in speziell benannten Ressourcenverzeichnissen gruppieren. Während der Laufzeit verwendet Android die entsprechende Ressource basierend auf der aktuellen Konfiguration. Sie können beispielsweise je nach Bildschirmgröße ein anderes UI-Layout bereitstellen oder je nach Spracheinstellung unterschiedliche Strings verwenden.
Nachdem Sie Ihre Anwendungsressourcen externalisiert haben, können Sie mithilfe von Ressourcen-IDs, die in der R
-Klasse Ihres Projekts generiert werden, darauf zugreifen.
In diesem Dokument erfahren Sie, wie Sie die Ressourcen in Ihrem Android-Projekt gruppieren können. 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 können.
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.
Hinweis:Weitere Informationen zur Verwendung der Mipmap-Ordner finden Sie unter Anwendungssymbole in Mipmap-Verzeichnisse einfügen.
Tabelle 1 Ressourcenverzeichnisse, die im Projektverzeichnis res/
unterstützt werden.
Verzeichnis | Ressourcentyp |
---|---|
animator/ |
XML-Dateien, die Property-Animationen definieren |
anim/ |
XML-Dateien, die Tween-Animationen definieren Eigenschaftsanimationen können auch in diesem Verzeichnis gespeichert werden. Allerdings wird das Verzeichnis animator/ für Attributanimationen bevorzugt, um zwischen den beiden Typen zu unterscheiden. |
color/ |
XML-Dateien, die eine Farbliste der Status definieren. Weitere Informationen finden Sie unter Ressourcen für die Liste des Farbstatus. |
drawable/ |
Bitmapdateien (PNG,
Weitere Informationen findest du unter Drawable-Ressourcen. |
mipmap/ |
Drawable-Dateien für verschiedene Dichten von Launcher-Symbolen Weitere Informationen zum Verwalten von Launcher-Symbolen mit mipmap/ -Ordnern findest du unter App-Symbole in Mipmap-Verzeichnisse einfügen. |
layout/ |
XML-Dateien, die ein Layout der Benutzeroberfläche definieren. Weitere Informationen finden Sie unter Layoutressource. |
menu/ |
XML-Dateien, mit denen Anwendungsmenüs definiert werden, z. B. ein Optionsmenü, ein Kontextmenü oder ein Untermenü. Weitere Informationen finden Sie unter Menüressource. |
raw/ |
Beliebige Dateien, die in Rohform 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 |
values/ |
XML-Dateien, die einfache Werte wie Zeichenfolgen, Ganzzahlen und Farben enthalten. Während XML-Ressourcendateien in anderen Da jede Ressource mit einem eigenen XML-Element definiert ist, können Sie der Datei einen beliebigen Namen geben und verschiedene Ressourcentypen in einer Datei platzieren. Möglicherweise möchten Sie jedoch eindeutige Ressourcentypen in verschiedenen Dateien platzieren. Hier sind einige Dateinamenskonventionen für Ressourcen, die Sie in diesem Verzeichnis erstellen können:
Weitere Informationen finden Sie unter Stringressourcen, Stilressource und Weitere Ressourcentypen. |
xml/ |
Beliebige XML-Dateien, die zur Laufzeit durch Aufrufen von Resources.getXML() gelesen werden können. Hier müssen verschiedene XML-Konfigurationsdateien gespeichert werden, z. B. eine Suchkonfiguration.
|
font/ |
Schriftartdateien mit Erweiterungen wie TTF, OTF oder TTC oder XML-Dateien, die ein <font-family> -Element enthalten. Weitere Informationen zu Schriftarten als Ressourcen finden Sie unter Schriftart als XML-Ressource hinzufügen.
|
Achtung:Speichern Sie Ressourcendateien niemals direkt im Verzeichnis res/
. Dies verursacht einen Compiler-Fehler.
Weitere Informationen zu den einzelnen Ressourcentypen finden Sie in der Übersicht zu Ressourcentypen.
Die Ressourcen, die Sie in den in Tabelle 1 definierten Unterverzeichnissen speichern, sind Ihre Standardressourcen. Diese Ressourcen definieren also das Standarddesign und den Standardinhalt für Ihre App. Unterschiedliche Arten von Android-Geräten erfordern jedoch möglicherweise unterschiedliche Arten von Ressourcen.
Sie können beispielsweise unterschiedliche Layoutressourcen für Geräte bereitstellen, die größer als normale Bildschirme sind, um den zusätzlichen Platz auf dem Bildschirm zu nutzen. Sie können auch verschiedene Stringressourcen bereitstellen, die den Text auf Ihrer Benutzeroberfläche je nach der Spracheinstellung des Geräts übersetzen. Damit Sie diese verschiedenen Ressourcen für verschiedene Gerätekonfigurationen bereitstellen können, müssen Sie zusätzlich zu Ihren Standardressourcen alternative Ressourcen bereitstellen.
Alternative Ressourcen bereitstellen
Die meisten Apps bieten alternative Ressourcen zur Unterstützung bestimmter Gerätekonfigurationen. Füge beispielsweise alternative Drawable-Ressourcen für verschiedene Bildschirmdichten und alternative String-Ressourcen für verschiedene Sprachen hinzu. Während der Laufzeit erkennt Android die aktuelle Gerätekonfiguration und lädt die entsprechenden Ressourcen für Ihre App.
![](https://developer.android.com/static/images/resources/resource_devices_diagram2.png?authuser=6&hl=de)
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 (definiert in Tabelle 1).<qualifier>
ist ein Name, der eine einzelne Konfiguration angibt, für die diese Ressourcen verwendet werden sollen (definiert in Tabelle 2).
Sie können mehrere
<qualifier>
anhängen. Trennen Sie die Einträge durch einen Bindestrich.Achtung:Wenn Sie mehrere Qualifizierer anhängen, müssen Sie diese in der gleichen Reihenfolge platzieren, in der sie in Tabelle 2 aufgeführt sind. Wenn die Qualifier nicht richtig angeordnet sind, werden die Ressourcen ignoriert.
- Speichern Sie die entsprechenden alternativen Ressourcen in diesem neuen Verzeichnis. Die Ressourcendateien müssen exakt denselben Namen wie die Standardressourcendateien haben.
Hier sind einige Standardressourcen 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 HD-Bildschirm bestimmt sind. Die Bilder in diesen Drawable-Verzeichnissen haben eine bestimmte Größe an bestimmte Bildschirmdichten, die Dateinamen sind jedoch identisch. Auf diese Weise ist die Ressourcen-ID, mit der Sie auf das icon.png
- oder background.png
-Image verweisen, immer identisch. Android wählt die Version jeder Ressource aus, die am besten mit dem aktuellen Gerät übereinstimmt, indem die Gerätekonfigurationsinformationen mit den Qualifiern im Namen des Ressourcenverzeichnisses verglichen werden.
Achtung:Definieren Sie beim Definieren einer alternativen Ressource unbedingt auch die Ressource in einer Standardkonfiguration. Andernfalls könnten bei Ihrer Anwendung Laufzeitausnahmen auftreten, wenn das Gerät eine Konfiguration ändert. Wenn Sie beispielsweise nur values-en
und nicht values
einen String hinzufügen, kann in Ihrer Anwendung die Ausnahme Resource Not Found
auftreten, wenn der Nutzer die standardmäßige Systemsprache ändert.
In Tabelle 2 sind die gültigen Konfigurationskennzeichner nach Priorität geordnet aufgeführt. Sie können einem Verzeichnisnamen mehrere Qualifizierer hinzufügen. Trennen Sie dazu die einzelnen Qualifier durch einen Bindestrich. Wenn Sie für ein Ressourcenverzeichnis mehrere Qualifizierer verwenden, müssen Sie sie in der Reihenfolge, in der sie in der Tabelle aufgeführt sind, dem Verzeichnisnamen hinzufügen.
Tabelle 2 die Namen der Konfigurationsqualifizierer.
Konfiguration | Qualifier-Werte | Beschreibung |
---|---|---|
Kundencenter und MNC | Beispiele:mcc310
mcc208-mnc00
|
Der Mobile Country Code (MCC), optional gefolgt vom Mobile Network Code (MNC) der SIM-Karte im Gerät. Beispiel: Wenn das Gerät eine Funkverbindung verwendet (d. h. ein GSM-Telefon), stammen die Kundencenter- und MNC-Werte von der SIM-Karte. Sie können beispielsweise auch nur das Verwaltungskonto verwenden, um länderspezifische rechtliche Ressourcen in Ihre App einzubinden. Wenn Sie dies nur basierend auf der Sprache angeben müssen, verwenden Sie stattdessen den Kennzeichner Sprache, Skript (optional) und Region (optional). Wenn du den Kundencenter- und den MNC-Qualifier verwendest, solltest du vorsichtig vorgehen und testen, ob er erwartungsgemäß funktioniert. Sehen Sie sich auch die Konfigurationsfelder |
Sprache, Skript (optional) und Region (optional) | Beispiele:en fr en-rUS fr-rFR fr-rCA b+en b+en+US b+es+419 b+zh+Hant b+sr+Latn+RS |
Die Sprache wird durch einen aus zwei Buchstaben bestehenden ISO 639-1-Sprachcode definiert, optional gefolgt von einem aus zwei Buchstaben bestehenden ISO 3166-1-alpha-2-Regionscode, dem der kleingeschriebene Bei den Codes wird nicht zwischen Groß- und Kleinschreibung unterschieden. Das Präfix Mit Android 7.0 (API-Level 24) werden BCP 47-Sprach-Tags unterstützt, mit denen Sie sprach- und regionsspezifische Ressourcen qualifizieren können. Ein Sprach-Tag besteht aus einer Sequenz von einem oder mehreren Untertags, von denen jedes den vom Gesamt-Tag ermittelten Sprachbereich eingrenzt oder eingrenzt. Weitere Informationen zu Sprach-Tags finden Sie unter Tags zur Identifizierung von Sprachen. Wenn Sie ein BCP 47-Sprach-Tag verwenden möchten, verketten Sie
Das Sprach-Tag kann sich im Laufe deiner App ändern, wenn Nutzer die Sprache in den Systemeinstellungen ändern. Informationen dazu, wie sich dies während der Laufzeit auf Ihre Anwendung auswirken kann, finden Sie unter Konfigurationsänderungen verarbeiten. Eine vollständige Anleitung zum Lokalisieren Ihrer App in andere Sprachen finden Sie unter App lokalisieren. Weitere Informationen finden Sie in der Methode |
Layoutrichtung | ldrtl ldltr |
Die Layoutrichtung Ihrer App. Dies kann für jede Ressource gelten, z. B. Layouts, Drawables oder Werte. Wenn Sie beispielsweise ein spezielles Layout für die arabische Sprache und ein generisches Layout für eine andere linksläufige Sprache wie Persisch oder Hebräisch angeben möchten, verwenden Sie Verzeichnisse wie die folgenden:
Hinweis:Wenn Sie Funktionen für das linksläufige Layout für Ihre App aktivieren möchten, müssen Sie In API-Level 17 hinzugefügt. |
Geringste Breite | sw<N>dp Beispiele: sw320dp sw600dp sw720dp usw. |
Die kürzeste Abmessung des Bildschirmbereichs, die für eine App verfügbar ist. Das
Wenn Ihr Layout beispielsweise erfordert, dass die kleinste Dimension des Bildschirmbereichs mindestens 600 dp beträgt, können Sie diesen Qualifizierer verwenden, um die Layoutressourcen in einem Es ist nützlich, die kleinste Breite zu verwenden, um die allgemeine Bildschirmgröße zu bestimmen, da sie oft der entscheidende Faktor beim Entwerfen eines Layouts ist. Eine UI scrollt oft vertikal, allerdings gibt es recht große Einschränkungen im Hinblick auf den erforderlichen Mindestabstand in horizontaler Richtung. Die verfügbare Breite ist auch der Schlüsselfaktor bei der Entscheidung, ob ein Ein-Fenster-Layout für Mobilgeräte oder ein Mehrfenster-Layout für Tablets verwendet werden soll. Daher ist die kleinstmögliche Breite für jedes Gerät wahrscheinlich am wichtigsten. Die kleinste Breite eines Geräts berücksichtigt Bildschirmdekorationen und die System-UI. Wenn das Gerät beispielsweise persistente UI-Elemente auf dem Bildschirm hat, die den Platz entlang der Achse der kleinsten Breite ausmachen, gibt das System an, dass die kleinste Breite kleiner als die tatsächliche Bildschirmgröße ist, da diese Bildschirmpixel nicht für Ihre UI verfügbar sind. Hier einige Werte, die Sie hier für gängige Bildschirmgrößen verwenden können:
Wenn Ihre App mehrere Ressourcenverzeichnisse mit unterschiedlichen Werten für den Qualifizierer In API-Level 13 hinzugefügt. Weitere Informationen findest du im Attribut Weitere Informationen zum Design für verschiedene Bildschirme mit diesem Qualifier finden Sie unter Responsives/adaptives Design mit Ansichten. |
Verfügbare Breite und Höhe | w<N>dp h<N>dp Beispiele: w720dp w1024dp h720dp h1024dp usw. |
Gibt die minimale verfügbare Bildschirmbreite oder -höhe an (in Die verfügbaren Breiten und Höhen sind oft hilfreich, um zu bestimmen, ob Sie ein Mehrfensterlayout verwenden sollten, da Sie selbst auf einem Tablet oft nicht dasselbe Mehrfensterlayout für das Hochformat benötigen wie für das Querformat. So können Sie also die Mindestbreite und/oder -höhe angeben, die für das Layout erforderlich sind, anstatt die Qualifier 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 diese zu überschreiten). Nähe an wird ermittelt, indem die Differenz zwischen der tatsächlichen und der angegebenen Breite zur Differenz zwischen der tatsächlichen und der angegebenen Höhe addiert wird. Die angegebenen Höhen und Breiten haben dabei den Wert 0. Die Werte schließen den von Fenster-Einsätzen eingenommenen Bereich aus. Wenn das Gerät also an den Displayrändern UI-Elemente hat, sind die Werte für Breite und Höhe kleiner als die tatsächlichen Bildschirmabmessungen, auch wenn die App mit
Einige vertikale Bildschirmelemente, die nicht festgelegt sind, z. B. eine Smartphone-Statusleiste, die im Vollbildmodus ausgeblendet werden kann, werden hier nicht berücksichtigt. Dasselbe gilt für Fenstergestaltungen wie die Titel- oder Aktionsleiste. Daher müssen Apps mit etwas kleinerem Platz umgehen können als angegeben. Hinweis: Das System wählt die Ressource aus, deren Breite und Höhe jeweils übereinstimmen. Daher wird eine Ressource, die beides angibt, deutlich bevorzugt vor einer Ressource, die nur eine der beiden Optionen angibt. Wenn der tatsächliche Bildschirm beispielsweise 720 dp breit und 1.280 dp hoch ist und eine Ressource mit w720dp und eine andere als w700dp-h1200dp qualifiziert ist, wird Letztere ausgewählt, obwohl erstere genau mit der angegebenen übereinstimmt. In API-Level 13 hinzugefügt. Sieh dir auch die Konfigurationsfelder Weitere Informationen zum Design für verschiedene Bildschirme mit diesem Qualifier finden Sie unter Responsives/adaptives Design mit Ansichten. |
Displaygröße |
small normal large xlarge
|
Hinweis:Die Verwendung eines Größenkennzeichners bedeutet nicht, dass die Ressourcen nur für Bildschirme dieser Größe gelten. Wenn Sie keine alternativen Ressourcen mit Qualifizierern bereitstellen, die besser der aktuellen Gerätekonfiguration entsprechen, kann das System die besten Ressourcen verwenden. Achtung:Wenn alle Ressourcen einen Größenkennzeichner verwenden, der größer als der aktuelle Bildschirm ist, verwendet das System diesen nicht und Ihre App stürzt zur Laufzeit ab. Das passiert beispielsweise, wenn alle Layoutressourcen mit dem Qualifier In API-Level 4 hinzugefügt. Im Konfigurationsfeld Weitere Informationen findest du unter Bildschirmkompatibilität – Übersicht. |
Display-Seitenverhältnis |
long notlong
|
In API-Level 4 hinzugefügt. Das hängt einzig vom Seitenverhältnis des Displays ab (ein Im Konfigurationsfeld |
Runder Bildschirm |
round notround
|
In API-Level 23 hinzugefügt. Die Konfigurationsmethode |
Breiter Farbgamut |
widecg nowidecg
|
In API-Level 26 hinzugefügt. Die Konfigurationsmethode |
High Dynamic Range (HDR) |
highdr lowdr
|
In API-Level 26 hinzugefügt. Die Konfigurationsmethode |
Bildschirmausrichtung |
port land
|
Dies kann sich im Laufe der Lebensdauer deiner App ändern, wenn der Nutzer den Bildschirm dreht. Informationen dazu, wie sich das auf Ihre Anwendung während der Laufzeit auswirkt, finden Sie unter Konfigurationsänderungen verarbeiten. Im Konfigurationsfeld |
UI-Modus |
car desk television appliance watch vrheadset
|
Hinzugefügt in API-Level 8, Fernseher in API 13, Smartwatch in API 20 hinzugefügt. Informationen dazu, wie Ihre App reagieren kann, wenn das Gerät in ein Dock eingesetzt oder daraus entfernt wird, finden Sie unter Status und Typ der Docking-Funktion ermitteln und überwachen. Dies kann sich im Laufe der Nutzungsdauer deiner App ändern, wenn der Nutzer das Gerät in ein Dock setzt. Einige dieser Modi können mit |
Nachtmodus |
night notnight
|
In API-Level 8 hinzugefügt. Dies kann sich während 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 |
Bildschirm-Pixeldichte (dpi) |
ldpi mdpi hdpi xhdpi xxhdpi xxxhdpi nodpi tvdpi anydpi nnndpi
|
Zwischen den sechs primären Dichten gibt es ein Skalierungsverhältnis von 3:4:6:8:12:16 (und ignoriert die tvdpi-Dichte). Eine 9 x 9-Bitmap in ldpi ist also 12 x 12 in MDPI, 18 x 18 in HDPI, 24 x 24 in xhdpi und so weiter. Hinweis:Die Verwendung eines Dichtekennzeichners bedeutet nicht, dass die Ressourcen nur für Bildschirme mit dieser Dichte vorgesehen sind. Wenn Sie keine alternativen Ressourcen mit Qualifier zur Verfügung stellen, die besser zur aktuellen Gerätekonfiguration passen, verwendet das System die Ressourcen, die am besten geeignet sind. Weitere Informationen zum Umgang mit unterschiedlichen Bildschirmdichten und dazu, wie Android Ihre Bitmaps an die aktuelle Dichte anpassen könnte, finden Sie unter Bildschirmkompatibilität – Übersicht. |
Touchscreentyp |
notouch finger
|
Im Konfigurationsfeld |
Verfügbarkeit der Tastatur |
keysexposed keyshidden keyssoft
|
Wenn Sie Dies kann sich im Laufe der Lebensdauer Ihrer App ändern, wenn der Nutzer eine Hardwaretastatur öffnet. Informationen dazu, wie sich das auf Ihre Anwendung während der Laufzeit auswirkt, finden Sie unter Konfigurationsänderungen verarbeiten. Sehen Sie sich auch die Konfigurationsfelder |
Primäre Texteingabemethode |
nokeys qwerty 12key
|
Im Konfigurationsfeld |
Verfügbarkeit der Navigationstasten |
navexposed navhidden
|
Dies kann sich im Laufe deiner App ändern, wenn der Nutzer die Navigationstasten zeigt. Informationen dazu, wie sich das auf Ihre Anwendung während der Laufzeit auswirkt, finden Sie unter Konfigurationsänderungen verarbeiten. Im Konfigurationsfeld |
Primäre Navigationsmethode ohne Berührung |
nonav dpad trackball wheel
|
Im Konfigurationsfeld |
Plattformversion (API-Level) | Beispiele:v3 v4 v7 usw. |
Das vom Gerät unterstützte API-Level. Beispiel: |
Hinweis:Nicht alle Android-Versionen unterstützen alle Qualifizierer. Bei Verwendung eines neuen Qualifiers wird implizit der Plattformversionsqualifizierer hinzugefügt, sodass er von älteren Geräten ignoriert werden kann. Bei Verwendung eines w600dp
-Qualifiers wird beispielsweise automatisch der Qualifier v13
mit einbezogen, da der Qualifier für die verfügbare Breite in API-Level 13 neu war. Fügen Sie immer eine Reihe von Standardressourcen hinzu, d. h. eine Reihe von Ressourcen ohne Qualifier, um Probleme zu vermeiden. Weitere Informationen finden Sie im Abschnitt Optimale Gerätekompatibilität mit Ressourcen bereitstellen.
Regeln für Qualifier-Namen
Im Folgenden finden Sie einige Regeln zur Verwendung der Namen von Konfigurationsqualifizierern:
- Sie können für eine einzelne Gruppe von Ressourcen mehrere Qualifizierer angeben, die durch Bindestriche getrennt sind. Beispielsweise gilt
drawable-en-rUS-land
für Geräte in US-Englisch im Querformat. - Die Qualifizierer müssen in der Reihenfolge angeordnet sein, in der sie in Tabelle 2 aufgeführt sind.
- 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ß-/Kleinschreibung nicht berücksichtigt. Der Ressourcencompiler wandelt Verzeichnisnamen vor der Verarbeitung in Kleinbuchstaben um, um Probleme bei Dateisystemen zu vermeiden, bei denen die Groß-/Kleinschreibung nicht berücksichtigt wird. Die Großschreibung in den Namen dient nur der besseren Lesbarkeit.
- Für jeden Qualifizierertyp wird nur ein Wert unterstützt. Wenn du beispielsweise für Spanien und Frankreich dieselben Drawable-Dateien verwenden möchtest, kannst du kein Verzeichnis namens
drawable-es-fr/
haben. Stattdessen benötigen Sie zwei Ressourcenverzeichnisse wiedrawable-es/
unddrawable-fr/
, die die entsprechenden Dateien enthalten. Sie müssen die Dateien jedoch nicht an beiden Speicherorten duplizieren. Stattdessen können Sie einen Alias für eine Ressource erstellen, wie im Abschnitt Alias-Ressourcen erstellen beschrieben.
Nachdem Sie alternative Ressourcen in Verzeichnissen gespeichert haben, die mit diesen Qualifizierern benannt sind, wendet Android die Ressourcen in Ihrer App automatisch auf Grundlage 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 übereinstimmende Ressource.
Wenn es keine alternativen Ressourcen gibt, die einer bestimmten Gerätekonfiguration entsprechen, verwendet Android die entsprechenden Standardressourcen, also den Satz von Ressourcen für einen bestimmten Ressourcentyp, der keinen Konfigurationsqualifizierer enthält.
Alias-Ressourcen erstellen
Wenn Sie eine Ressource für mehrere Gerätekonfigurationen verwenden, aber nicht als Standardressource bereitstellen möchten, müssen Sie dieselbe Ressource nicht in mehr als einem alternativen Ressourcenverzeichnis speichern. Stattdessen können Sie eine alternative Ressource erstellen, die als Alias für eine in Ihrem Standard-Ressourcenverzeichnis gespeicherte Ressource dient.
Hinweis: Nicht alle Ressourcen bieten einen Mechanismus, mit dem Sie einen Alias für eine andere Ressource erstellen können. Insbesondere für Animationen, Speisekarten, Rohdateien und andere nicht angegebene Ressourcen im Verzeichnis xml/
steht diese Funktion nicht zur Verfügung.
Angenommen, Sie haben das App-Symbol icon.png
und benötigen eine eindeutige Version davon für verschiedene Sprachen. Allerdings muss für die beiden Sprachen Englisch-Kanada und Französisch-Kanada dieselbe Version verwendet werden. Sie müssen nicht dasselbe Image in das Ressourcenverzeichnis für Englisch (Kanada) und Französisch (Kanada) kopieren.
Stattdessen können Sie das Image, das für beide verwendet wird, mit einem anderen Namen als
icon.png
speichern, z. B. icon_ca.png
, und es im Standardverzeichnis res/drawable/
ablegen. Erstellen Sie dann eine icon.xml
-Datei in res/drawable-en-rCA/
und res/drawable-fr-rCA/
, die mit dem Element <bitmap>
auf die Ressource icon_ca.png
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
Verwende das <drawable>
-Element, um einen Alias für ein vorhandenes 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. Tatsächlich ist sie jedoch ein Alias für die Ressource R.drawable.icon_ca
, die in res/drawable/
gespeichert ist.
Layout
Verwenden Sie das Element <include>
in einem <merge>
-Element, 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, die Sie als R.layout.main
referenzieren können, tatsächlich aber ein Alias für die Ressource R.layout.main_ltr
ist.
Strings und andere einfache Werte
Verwenden Sie die Ressourcen-ID des gewünschten Strings als Wert für den neuen String, um einen Alias für einen vorhandenen String zu erstellen:
<?xml version="1.0" encoding="utf-8"?> <resources> <string name="hello">Hello</string> <string name="hi">@string/hello</string> </resources>
Die Ressource R.string.hi
ist jetzt ein Alias für den R.string.hello
.
Andere einfache Werte funktionieren auf die gleiche Weise, z. B. Farben:
<?xml version="1.0" encoding="utf-8"?> <resources> <color name="red">#f00</color> <color name="highlight">@color/red</color> </resources>
Auf Anwendungsressourcen zugreifen
Nachdem Sie eine Ressource in Ihrer Anwendung bereitgestellt haben, können Sie sie anwenden, indem Sie auf ihre Ressourcen-ID verweisen. Alle Ressourcen-IDs werden in der R
-Klasse Ihres Projekts definiert, die vom aapt
-Tool automatisch generiert wird.
Beim Kompilieren Ihrer Anwendung generiert aapt
die Klasse R
, die die Ressourcen-IDs für alle Ressourcen im Verzeichnis res/
enthält. Für jeden Ressourcentyp gibt es eine abgeleitete R
-Klasse, z. B. R.drawable
für alle Drawable-Ressourcen. Und 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 Ressourcen-IDs in der Klasse R
angegeben werden, müssen Sie dort nicht suchen, um eine Ressourcen-ID zu ermitteln. Eine Ressourcen-ID setzt sich immer aus Folgendem zusammen:
- Ressourcentyp: Jede Ressource wird in einen „Typ“ gruppiert, z. B.
string
,drawable
oderlayout
. Weitere Informationen zu den verschiedenen Typen finden Sie unter Ressourcentypen – Übersicht. - Der Ressourcenname. Dies ist entweder der Dateiname ohne Erweiterung oder der Wert im XML-Attribut
android:name
, wenn die Ressource ein einfacher Wert wie ein String ist.
Es gibt zwei Möglichkeiten, auf eine Ressource zuzugreifen:
- Im Code: Verwendung einer statischen Ganzzahl aus einer abgeleiteten Klasse Ihrer
R
-Klasse. Beispiel:R.string.hello
string
ist der Ressourcentyp undhello
der 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: Verwenden Sie eine spezielle XML-Syntax, die der Ressourcen-ID entspricht, die in Ihrer
R
-Klasse definiert ist. Beispiel:@string/hello
string
ist der Ressourcentyp undhello
der Ressourcenname. Sie können diese Syntax in einer XML-Ressource überall 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. So können Sie beispielsweise mit setImageResource()
festlegen, dass ein ImageView
die Ressource res/drawable/myimage.png
verwendet:
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 den Methoden in Resources
abrufen, für die Sie eine Instanz mit getResources()
abrufen können.
Syntax
So sieht die Syntax für den Verweis auf eine Ressource im Code aus:
[<package_name>.]R.<resource_type>.<resource_name>
<package_name>
ist der Name des Pakets, in dem sich die Ressource befindet (nicht erforderlich, wenn auf Ressourcen aus Ihrem eigenen Paket verwiesen wird).<resource_type>
ist die abgeleiteteR
-Klasse für den Ressourcentyp.<resource_name>
ist entweder der Name der Ressourcendatei ohne Erweiterung oder der Attributwertandroid:name
im XML-Element für einfache Werte.
Weitere Informationen zu den einzelnen Ressourcentypen und wie Sie darauf verweisen können, finden Sie unter Ressourcentypen – Übersicht.
Anwendungsfälle
Es gibt viele Methoden, die einen Ressourcen-ID-Parameter akzeptieren. In Resources
können Sie Ressourcen mithilfe von Methoden abrufen. Sie können mit Context.getResources()
eine Instanz von Resources
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);
Achtung:Ändern Sie die Datei R.java
nicht manuell. Sie wird vom aapt
-Tool generiert, wenn Ihr Projekt kompiliert wird. Alle Änderungen werden bei der nächsten Kompilierung überschrieben.
Zugriff auf Ressourcen über XML
Sie können Werte für einige XML-Attribute und -Elemente mithilfe eines Verweises auf eine vorhandene Ressource definieren. Dies geschieht häufig bei der Erstellung von Layoutdateien, um Strings und Bilder für die Widgets bereitzustellen.
Wenn Sie beispielsweise Ihrem Layout eine 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 für den Verweis 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 die abgeleiteteR
-Klasse für den Ressourcentyp.<resource_name>
ist entweder der Name der Ressourcendatei ohne Erweiterung oder der Attributwertandroid:name
im XML-Element für einfache Werte.
Weitere Informationen zu den einzelnen Ressourcentypen und wie Sie darauf verweisen können, finden Sie unter Ressourcentypen – Übersicht.
Anwendungsfälle
In einigen Fällen musst du eine Ressource für einen Wert in XML verwenden, z. B. um ein Drawable-Bild auf ein Widget anzuwenden. Du kannst aber auch eine XML-Ressource für jede Stelle verwenden, die einen einfachen Wert akzeptiert. Angenommen, die folgende Ressourcendatei enthält eine Farbressource und eine String-Ressource:
<?xml version="1.0" encoding="utf-8"?> <resources> <color name="opaque_red">#f00</color> <string name="hello">Hello!</string> </resources>
Du kannst 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 nicht in der Ressourcenreferenz angeben, da die Ressourcen aus Ihrem eigenen Paket stammen. Um auf eine Systemressource zu verweisen, 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" />
Hinweis:Verwenden Sie immer Stringressourcen, damit Ihre Anwendung für andere Sprachen lokalisiert werden kann. Informationen zum Erstellen alternativer Ressourcen (z. B. lokalisierte Strings) findest du unter Alternative Ressourcen bereitstellen. Eine vollständige Anleitung zum Lokalisieren Ihrer Anwendung für andere Sprachen finden Sie unter Anwendung lokalisieren.
Sie können sogar Ressourcen in XML verwenden, um Aliasse zu erstellen. Sie können beispielsweise eine Drawable-Ressource erstellen, die ein Alias für eine andere Drawable-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 überflüssig, kann aber bei Verwendung einer alternativen Ressource sehr nützlich sein. Weitere Informationen finden Sie im Abschnitt zum Erstellen von Alias-Ressourcen.
Referenzstilattribute
Mit einer Stilattributressource können Sie auf den Wert eines Attributs im aktuell angewendeten Design verweisen. Wenn Sie auf ein Stilattribut verweisen, können Sie das Erscheinungsbild von UI-Elementen anpassen, indem Sie sie so gestalten, dass sie den Standardvarianten des aktuellen Designs entsprechen, anstatt einen hartcodierten Wert anzugeben. Der Verweis auf ein Stilattribut sagt im Wesentlichen: „Verwenden Sie den durch dieses Attribut im aktuellen Design definierten Stil.“
Um auf ein Stilattribut zu verweisen, ist die Namenssyntax fast identisch mit dem normalen Ressourcenformat. Verwenden Sie jedoch anstelle des At-Symbols (@
) ein Fragezeichen (?
). Der Teil des Ressourcentyps ist optional. Daher lautet die Referenzsyntax wie folgt:
?[<package_name>:][<resource_type>/]<resource_name>
So können Sie beispielsweise auf ein Attribut verweisen, um die Textfarbe so festzulegen, dass sie der sekundären Textfarbe des Systemdesigns entspricht:
<EditText id="text" android:layout_width="fill_parent" android:layout_height="wrap_content" android:textColor="?android:textColorSecondary" android:text="@string/hello_world" />
Hier gibt das Attribut android:textColor
den Namen eines Stilattributs im aktuellen Design an. Android verwendet jetzt den Wert, der auf das Stilattribut android:textColorSecondary
angewendet wird, als Wert für android:textColor
in diesem Widget. Da das Systemressourcentool weiß, dass eine Attributressource in diesem Kontext erwartet wird, müssen Sie den Typ, also ?android:attr/textColorSecondary
, nicht explizit angeben. Sie können den Typ attr
ausschließen.
Auf Originaldateien zugreifen
In seltenen Fällen benötigen Sie möglicherweise Zugriff auf Ihre ursprünglichen Dateien und Verzeichnisse. In diesem Fall funktioniert das Speichern Ihrer Dateien in res/
nicht, da eine Ressource nur über die Ressourcen-ID aus res/
gelesen werden kann. 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 auf sie verweisen. Stattdessen können Sie Dateien im Verzeichnis assets/
wie ein normales Dateisystem abfragen und Rohdaten mit AssetManager
lesen.
Wenn Sie jedoch nur Rohdaten (z. B. eine Video- oder Audiodatei) lesen können, 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. Für den Zugriff auf diese Ressourcen müssen Sie Ihre Ressourcenreferenz 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 Layoutressource, die von der Plattform für Elemente in einer ListView
definiert wird. Sie können dieses Layout verwenden,
statt ein eigenes Layout für Listenelemente zu erstellen.
Für optimale Gerätekompatibilität mit Ressourcen sorgen
Damit Ihre Anwendung mehrere Gerätekonfigurationen unterstützt, ist es sehr wichtig, dass Sie für jeden von Ihrer Anwendung verwendeten Ressourcentyp immer Standardressourcen angeben.
Wenn Ihre App beispielsweise mehrere Sprachen unterstützt, geben Sie immer ein values/
-Verzeichnis an, in dem Ihre Strings gespeichert sind, ohne Bezeichner für Sprache und Region. Wenn Sie stattdessen alle Ihre Stringdateien in Verzeichnissen mit einem Sprach- und Regions-Qualifier ablegen, stürzt Ihre App bei Ausführung auf einem Gerät ab, das auf eine Sprache eingestellt ist, die von Ihren Strings nicht unterstützt wird.
Solange Sie values/
-Standardressourcen angeben, wird Ihre Anwendung auch dann ordnungsgemäß ausgeführt, wenn der Nutzer die dargestellte Sprache nicht versteht. Das ist besser als ein Absturz.
Wenn Sie je nach Bildschirmausrichtung unterschiedliche Layoutressourcen bereitstellen, wählen Sie ebenfalls eine Ausrichtung als Standard aus. Anstatt beispielsweise Layoutressourcen in layout-land/
für Querformat und layout-port/
für Hochformat bereitzustellen, belassen Sie eine der Standardressourcen, z. B. layout/
für Querformat und layout-port/
für Hochformat.
Die Bereitstellung von Standardressourcen ist nicht nur wichtig, weil Ihre Anwendung möglicherweise mit einer Konfiguration ausgeführt wird, die Sie nicht erwartet hatten, sondern auch, weil neue Versionen von Android manchmal Konfigurationsqualifizierer hinzufügen, die von älteren Versionen nicht unterstützt werden. Wenn Sie einen neuen Ressourcenqualifizierer verwenden, aber die Codekompatibilität mit älteren Android-Versionen beibehalten, stürzt Ihre App in einer älteren Android-Version ab, wenn Sie keine Standardressourcen angeben, da die mit dem neuen Qualifier benannten Ressourcen nicht verwendet werden können.
Wenn dein minSdkVersion
beispielsweise auf 4 gesetzt ist und du alle deine Drawable-Ressourcen mit dem Nachtmodus qualifizieren (night
oder notnight
, die in API-Level 8 hinzugefügt wurden), kann ein API-Level-4-Gerät nicht auf deine Drawable-Ressourcen zugreifen und stürzt ab. In diesem Fall möchten Sie wahrscheinlich notnight
als Standardressourcen verwenden. Schließen Sie diesen Qualifier aus und platzieren Sie die Drawable-Ressourcen entweder in drawable/
oder drawable-night/
.
Kurz gesagt: Stellen Sie für eine optimale Gerätekompatibilität immer Standardressourcen für die Ressourcen bereit, die Ihre App ordnungsgemäß ausführen muss. Erstellen Sie dann mithilfe von Konfigurationsqualifizierern alternative Ressourcen für bestimmte Gerätekonfigurationen.
Es gibt eine Ausnahme von dieser Regel: Wenn die minSdkVersion
deiner App 4 oder höher hat, benötigst du keine standardmäßigen Drawable-Ressourcen, wenn du alternative Drawable-Ressourcen mit dem Qualifier Bildschirmdichte angibst. Auch ohne standardmäßige Drawable-Ressourcen kann Android die beste Übereinstimmung unter den alternativen Bildschirmdichten finden und die Bitmaps nach Bedarf skalieren. Damit es jedoch auf allen Arten von Geräten optimal funktioniert, solltest du alternative Drawables für alle drei Arten von Dichten anbieten.
So findet Android die am besten übereinstimmende Ressource
Wenn Sie eine Ressource anfordern, für die Sie Alternativen bereitstellen, wählt Android je nach aktueller Gerätekonfiguration aus, welche alternative Ressource zur Laufzeit verwendet werden soll. Um zu zeigen, wie Android eine alternative Ressource auswählt, gehen wir davon aus, dass die folgenden Drawable-Verzeichnisse jeweils unterschiedliche Versionen derselben Bilder enthalten:
drawable/ drawable-en/ drawable-fr-rCA/ drawable-en-port/ drawable-en-notouch-12key/ drawable-port-ldpi/ drawable-port-notouch-12key/
Gehen wir von der Gerätekonfiguration aus:
Sprache = en-GB
Bildschirmausrichtung = port
Pixeldichte des Bildschirms = hdpi
Touchscreen-Typ = notouch
Primäre Texteingabemethode = 12key
Durch einen Vergleich der Gerätekonfiguration mit den verfügbaren alternativen Ressourcen wählt Android Drawables aus drawable-en-port
aus.
Das System trifft die Entscheidung, welche Ressourcen verwendet werden sollen, anhand der folgenden Logik:
![](https://developer.android.com/static/images/resources/res-selection-flowchart.png?authuser=6&hl=de)
Abbildung 2: Flussdiagramm dazu, wie Android die am besten übereinstimmende Ressource findet.
- Entfernen Sie Ressourcendateien, die der Gerätekonfiguration widersprechen.
Das Verzeichnis
drawable-fr-rCA/
wird entfernt, da es der Spracheen-GB
widerspricht.drawable/ drawable-en/
drawable-fr-rCA/drawable-en-port/ drawable-en-notouch-12key/ drawable-port-ldpi/ drawable-port-notouch-12key/Ausnahme:Die Bildschirmpixeldichte ist der einzige Kennzeichner, der nicht aufgrund eines Widerspruchs beseitigt wird. Obwohl die Bildschirmdichte des Geräts HDPI ist, wird
drawable-port-ldpi/
nicht ausgeschlossen, da jede Bildschirmdichte an diesem Punkt als übereinstimmend angesehen wird. Weitere Informationen finden Sie unter Bildschirmkompatibilität – Übersicht. - Suchen Sie in der Liste nach dem Qualifier mit der nächsthöheren Priorität (Tabelle 2). (Beginnen Sie mit dem Kundencenter.)
- Enthält eines der Ressourcenverzeichnisse diesen Qualifier?
- Falls nicht, kehren Sie zu Schritt 2 zurück und sehen Sie sich den nächsten Qualifier an. In diesem Beispiel lautet die Antwort „Nein“, bis der Sprachqualifizierer erreicht ist.
- Wenn ja, fahren Sie mit Schritt 4 fort.
- Entfernen Sie Ressourcenverzeichnisse, die diesen Qualifier nicht enthalten. In diesem Beispiel löscht das System als Nächstes alle Verzeichnisse, die keinen Sprachqualifizierer enthalten:
drawable/drawable-en/ drawable-en-port/ drawable-en-notouch-12key/drawable-port-ldpi/drawable-port-notouch-12key/Ausnahme:Wenn es sich bei dem betreffenden Qualifier um die Bildschirmpixeldichte handelt, wählt Android die Option aus, die der Bildschirmdichte des Geräts am ehesten entspricht. Im Allgemeinen bevorzugt Android ein größeres Originalbild anstelle eines kleineren Originalbilds. Weitere Informationen finden Sie unter Bildschirmkompatibilität – Übersicht.
- Wiederholen Sie die Schritte zwei, drei und vier, bis nur noch ein Verzeichnis übrig ist. In diesem Beispiel ist die Bildschirmausrichtung der nächste Qualifizierer, für den Übereinstimmungen vorliegen.
Daher werden Ressourcen eliminiert, die keine Bildschirmausrichtung angeben:
drawable-en/drawable-en-port/drawable-en-notouch-12key/Das verbleibende Verzeichnis ist
drawable-en-port
.
Obwohl dieses Verfahren für jede angeforderte Ressource ausgeführt wird, optimiert das System einige Aspekte. Eine dieser Optimierungsmöglichkeiten besteht darin, dass, sobald die Gerätekonfiguration bekannt ist, alternative Ressourcen beseitigt werden können, die nie abgeglichen werden können. Wenn die Konfigurationssprache beispielsweise Englisch ist, wird jedes Ressourcenverzeichnis, für das ein Sprachqualifizierer auf einen anderen Wert als Englisch festgelegt ist, nie in den Pool der geprüften Ressourcen aufgenommen. Ein Ressourcenverzeichnis ohne den Sprachqualifizierer ist jedoch weiterhin enthalten.
Bei der Auswahl von Ressourcen basierend auf den Bildschirmgrößenkennzeichnern verwendet das System Ressourcen, die für einen Bildschirm kleiner als der aktuelle Bildschirm vorgesehen sind, wenn keine besser passenden Ressourcen vorhanden sind. Auf einem großen Bildschirm werden beispielsweise bei Bedarf normal große Bildschirmressourcen verwendet.
Wenn die einzigen verfügbaren Ressourcen jedoch größer als der aktuelle Bildschirm sind, werden sie vom System nicht verwendet und Ihre App stürzt ab, wenn keine anderen Ressourcen der Gerätekonfiguration entsprechen. Das passiert beispielsweise, wenn alle Layoutressourcen mit dem Qualifier xlarge
getaggt sind, das Gerät aber einen normalen Bildschirm hat.
Hinweis:Der Vorrang des Qualifiers (in Tabelle 2) ist wichtiger als die Anzahl der Qualifier, die genau mit dem Gerät übereinstimmen. Im vorherigen Beispiel enthält in Schritt 4 die letzte Auswahl auf der Liste drei Qualifier, die genau mit dem Gerät übereinstimmen (Ausrichtung, Touchscreen-Typ und Eingabemethode), während drawable-en
nur einen Parameter hat, der mit (Sprache) übereinstimmt. Da die Sprache jedoch eine höhere Priorität als diese anderen Qualifier hat, wurde drawable-port-notouch-12key
eliminiert.