| Android-Entwickler

Syntax:

enthalten in: keine muss enthalten:<application>kann enthalten:<compatible-screens>
<instrumentation>
<permission>
<permission-group>
<permission-tree>
<supports-gl-texture>
<supports-screens>
<uses-configuration>
<uses-feature>
<uses-permission>
<uses-permission-sdk-23>
<uses-sdk>Beschreibung: Das Root-Element der Datei AndroidManifest.xml. Es muss ein<application>Element enthalten und die Attributexmlns:androidundpackageangeben:xmlns:androidDefiniert den Android-Namespace. Dieses Attribut sollte immer auf „“ gesetzt werden.packageEin vollständiger Paketname im Stil der Java-Sprache für die Android-App. Der Name kann Groß- und Kleinbuchstaben („A“ bis „Z“), Zahlen und Unterstriche („_“) enthalten. Einzelne Teile des Paketnamens dürfen jedoch nur mit Buchstaben beginnen.

Bei der Erstellung Ihrer App in ein Anwendungspaket (APK) verwendet das Build-System das package-Attribut für zwei Dinge:

• Es wendet diesen Namen als Namespace für die generierte R.java-Klasse Ihrer App an (die für den Zugriff auf Ihre App-Ressourcen verwendet wird).

  Wenn zum Beispiel package auf "com.example.myapp" gesetzt wird, wird die R-Klasse auf com.example.myapp.R erstellt.

• Dieser Name wird verwendet, um alle relativen Klassennamen aufzulösen, die in der Manifestdatei deklariert sind.

  Wenn zum Beispiel package auf "com.example.myapp" gesetzt ist, wird eine Aktivität, die als <activity android:name=".MainActivity"> deklariert ist, als com.example.myapp.MainActivity aufgelöst.

Dieser Name ist auch der Standardname für Ihren App-Prozess (siehe das <application>Attribut des processElements). Und es ist die Standard-Task-Affinität für Ihre Aktivitäten (siehe das<activity>Attribut des ElementstaskAffinity).

Dieser Name stellt auch die Anwendungs-ID dar, die universell eindeutig sein muss, um Ihre App in Google Play zu veröffentlichen. Gegen Ende des APK-Build-Prozesses überschreiben die Build-Tools jedoch den package-Namen mit derapplicationId-Eigenschaft aus der build.gradle-Datei (wird von Android Studioprojekten verwendet). Solange Sie den Namen des Manifests package mit dem Namen der Build-Datei applicationId gleich halten, ist dies kein Problem. Wenn sich diese beiden Werte jedoch unterscheiden, sollten Sie die Unterschiede zwischen dem „Paketnamen“ und der „Anwendungs-ID“ verstehen, indem Sie lesen, wie die Anwendungs-ID gesetzt wird.

Um Konflikte mit anderen Entwicklern zu vermeiden, sollten Sie den Besitz von Internet-Domänen als Basis für Ihre Paketnamen verwenden (in umgekehrter Reihenfolge). Von Google veröffentlichte Apps beginnen zum Beispiel mitcom.google.

Hinweis: Sowohl der com.example als auch der com.androidNamensraum sind von Google Play verboten.

Wenn Sie Ihren Paketnamen nach der Veröffentlichung Ihrer App ändern möchten, können Sie das tun, aber Sie müssen das applicationId beibehalten. Das applicationId definiert die eindeutige Identität für Ihre App bei Google Play. Wenn Sie es also ändern, wird die APK als eine andere App betrachtet und Benutzer der vorherigen Version erhalten kein Update. Weitere Informationen finden Sie unter Festlegen der Anwendungs-ID.

android:sharedUserId

Diese Konstante wurde in API-Level 29 veraltet.
Gemeinsame Benutzer-IDs verursachen ein nicht-deterministisches Verhalten innerhalb des Paketmanagers. Daher wird von ihrer Verwendung dringend abgeraten und sie wird möglicherweise in einer zukünftigen Version von Android entfernt. Stattdessen sollten Apps geeignete Kommunikationsmechanismen, wie Dienste und Inhaltsanbieter, verwenden, um die Interoperabilität zwischen gemeinsam genutzten Komponenten zu erleichtern. Beachten Sie, dass bestehende Apps diesen Wert nicht entfernen können, da die Migration von einer gemeinsamen Benutzer-ID nicht unterstützt wird.

Der Name einer Linux-Benutzer-ID, die mit anderen Apps geteilt wird.

Standardmäßig weist Android jeder App eine eigene eindeutige Benutzer-ID zu.

Wenn dieses Attribut jedoch für zwei oder mehr Apps auf denselben Wert gesetzt ist, teilen sie sich alle dieselbe ID – vorausgesetzt, ihreZertifikatsätze sind identisch. Apps mit der gleichen Benutzer-ID können auf die Daten der anderen zugreifen und, falls gewünscht, im gleichen Prozess laufen.

android:targetSandboxVersionDie Ziel-Sandbox, die diese App verwenden soll. Der Standardwert ist1; Sie können es auch auf2setzen.Wenn Sie dieses Attribut auf2setzen, wechselt die Anwendung in eine andere SELinux-Sandbox.

Die folgenden Einschränkungen gelten für eine Level-2-Sandbox:

• Der Standardwert vonusesCleartextTraffic in der Netzwerksicherheitskonfiguration ist false.
• Uid-Sharing ist nicht erlaubt.

Für Android Instant Apps, die auf Android 8.0 (API-Level 26) oder höher abzielen, muss dieses Attribut auf 2 gesetzt werden. Sie können den Sandbox-Level in der installierten Version Ihrer App auf den weniger restriktiven Level 1 setzen, aber wenn Sie dies tun, bleiben die App-Daten von der Instant App nicht in der installierten Version Ihrer App erhalten. Sie müssen den Sandbox-Wert der installierten App auf 2 setzen, damit die Daten von der Instant-App auf die installierte Version übertragen werden können.

Nach der Installation einer App können Sie den Ziel-Sandbox-Wert nur auf einen höheren Wert aktualisieren.Um den Ziel-Sandbox-Wert herabzustufen, müssen Sie die App deinstallieren und durch eine Version ersetzen, deren Manifest einen niedrigeren Wert für dieses Attribut enthält.

android:sharedUserLabel

Diese Konstante wurde in API-Level 29 veraltet.
Gemeinsame Benutzer-IDs verursachen ein nicht-deterministisches Verhalten im Paketmanager. Daher wird von ihrer Verwendung dringend abgeraten und sie wird möglicherweise in einer zukünftigen Version von Android entfernt. Stattdessen sollten Apps geeignete Kommunikationsmechanismen, wie Dienste und Inhaltsanbieter, verwenden, um die Interoperabilität zwischen gemeinsam genutzten Komponenten zu erleichtern. Beachten Sie, dass bestehende Apps diesen Wert nicht entfernen können, da das Abwandern einer gemeinsamen Benutzer-ID nicht unterstützt wird.

Ein vom Benutzer lesbares Label für die gemeinsame Benutzer-ID. Die Beschriftung muss als Verweis auf eine String-Ressource gesetzt werden; sie kann kein roher String sein.

Dieses Attribut wurde in API Level 3 eingeführt. Es ist nur sinnvoll, wenn das Attribut sharedUserId ebenfalls gesetzt ist.

android:versionCodeEine interne Versionsnummer. Diese Nummer wird nur verwendet, um festzustellen, ob eine Version aktueller ist als eine andere, wobei höhere Nummern für neuere Versionen stehen. Dies ist nicht die Versionsnummer, die dem Benutzer angezeigt wird; diese Nummer wird mit dem AttributversionNamefestgelegt.

Der Wert muss als Ganzzahl gesetzt werden, z. B. „100“. Sie können ihn beliebig definieren, solange jede aufeinanderfolgende Version eine höhere Zahl hat. Es könnte zum Beispiel eine Build-Nummer sein. Oder Sie könnten eine Versionsnummer im Format „x.y“ in eine Ganzzahl übersetzen, indem Sie „x“ und „y“ getrennt in den unteren und oberen 16 Bits kodieren. Oder Sie könnten die Nummer einfach jedes Mal um eins erhöhen, wenn eine neue Version veröffentlicht wird.

android:versionNameDie Versionsnummer, die dem Benutzer angezeigt wird. Dieses Attribut kann als rawstring oder als Referenz auf eine String-Ressource gesetzt werden. Der String hat keinen anderen Zweck, als dem Benutzer angezeigt zu werden. DasversionCode-Attribut enthält die intern verwendete signifikante Versionsnummer.android:installLocationDer Standardinstallationsort für die App.

Die folgenden Schlüsselwort-Strings werden akzeptiert:

Wert	Beschreibung
„internalOnly„	Die App darf nur auf dem internen Gerätespeicher installiert werden. Wenn dies eingestellt ist, wird die App niemals auf dem externen Speicher installiert. Wenn der interne Speicher voll ist, installiert das System die App nicht. Dies ist auch das Standardverhalten, wenn Sie android:installLocation nicht definieren.
„auto„	Die App kann auf dem externen Speicher installiert werden, aber das System installiert die App standardmäßig auf dem internen Speicher. Wenn der interne Speicher voll ist, installiert das System die App auf dem externen Speicher. Nach der Installation kann der Benutzer die App über die Systemeinstellungen entweder auf den internen oder den externen Speicher verschieben.
„preferExternal„	Die App wird bevorzugt auf dem externen Speicher (SD-Karte) installiert. Es gibt keine Garantie dafür, dass das System diese Anforderung erfüllt. Die App kann auf dem internen Speicher installiert werden, wenn das externe Medium nicht verfügbar oder voll ist. Nach der Installation kann der Benutzer die App über die Systemeinstellungen entweder auf den internen oder externen Speicher verschieben.

Hinweis: Standardmäßig wird Ihre App auf dem internen Speicher installiert und kann nicht auf dem externen Speicher installiert werden, es sei denn, Sie definieren dieses Attribut entweder als „auto“ oder „preferExternal„.

Wenn eine App auf dem externen Speicher installiert wird:

• Die .apk-Datei wird auf dem externen Speicher gespeichert, aber alle App-Daten (z. B. Datenbanken) werden weiterhin im internen Gerätespeicher gespeichert.
• Der Container, in dem die .apk-Datei gespeichert wird, ist mit einem Schlüssel verschlüsselt, der es der App ermöglicht, nur auf dem Gerät zu funktionieren, auf dem sie installiert wurde. (Ein Benutzer kann die SD-Karte nicht auf ein anderes Gerät übertragen und die auf der Karte installierten Apps verwenden). Es können jedoch mehrere SD-Karten mit demselben Gerät verwendet werden.
• Auf Wunsch des Benutzers kann die App in den internen Speicher verschoben werden.

Der Benutzer kann auch beantragen, eine App vom internen Speicher auf den externen Speicher zu verschieben. Das System erlaubt dem Benutzer jedoch nicht, die App in den externen Speicher zu verschieben, wenn dieses Attribut auf internalOnly gesetzt ist, was die Standardeinstellung ist.

Lesen Sie App-Installationsort für weitere Informationen zur Verwendung dieses Attributs (einschließlich der Aufrechterhaltung der Abwärtskompatibilität).

Eingeführt in: API Level 8.

Eingeführt in: API Level 1 für alle Attribute, sofern in der Attributbeschreibung nicht anders angegeben. siehe auch:<application>