Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
AOSP bietet die folgenden Optionen zum Speichern von Konfigurationsinformationen auf einem Gerät:
Systemeigenschaften
Eigenschaften der Hardwareabstraktionsschicht (HAL)
XML-Dateien der Systemkonfiguration
Ressourcen-Overlays (statisch und Laufzeit)
Systemeigenschaften
Systemeigenschaften sind String-Schlüssel/Wert-Paare, die im globalen Wörterbuch build.prop gespeichert sind. Systemeigenschaften sind systemweite Ressourcen, die einfach zu verwenden sind und einen geringen Leistungsoverhead haben. Wenn Sie Systemeigenschaften verwenden, müssen Sie keine Inter-Process-Kommunikation (IPC) verwenden, auch wenn eine Systemeigenschaft für mehrere Prozesse freigegeben wird. Systemeigenschaften ähneln jedoch globalen Variablen und können bei Missbrauch schädlich sein. Der Missbrauch von Systemeigenschaften kann zu Problemen wie Sicherheitslücken und der Unzugänglichkeit von Apps für Nutzer führen. Bevor Sie Konfigurationsinformationen in Systemeigenschaften speichern, sollten Sie die anderen Konfigurationsoptionen in Betracht ziehen.
Wenn die „Source of Truth“ für eine Konfiguration von einer Hardwarekomponente auf einem Gerät stammt, muss die HAL für die Hardware die Informationen für diese Komponente bereitstellen. Definieren Sie in der vorhandenen HAL eine neue HAL-Methode für den Zugriff auf die Konfiguration. Weitere Informationen zur Entwicklung einer HAL finden Sie unter AIDL für HALs.
XML-Dateien der Systemkonfiguration
Wenn die Konfigurationsdaten statisch, aber kompliziert (strukturiert) sind, sollten Sie XML oder andere ähnliche Formate für die Konfigurationsdaten verwenden. Achten Sie darauf, dass das Dateischema stabil bleibt. Für XML-Dateien können Sie xsd_config verwenden, um das Schema stabil zu halten und einen automatisch generierten XML-Parser zu nutzen.
Ressourcen-Overlay
Mithilfe von Ressourcen-Overlays können Sie ein Produkt anpassen. Es gibt zwei Arten von Ressourcen-Overlays:
Standard-Ressourcen-Overlay, mit dem ein Produkt zur Buildzeit angepasst wird. Informationen zu Standard-Ressourcen-Overlays finden Sie unter Build mit Ressourcen-Overlays anpassen.
Mit einem Runtime Resource Overlay (RRO) können die Ressourcenwerte eines Zielpakets zur Laufzeit geändert werden. So kann beispielsweise das Verhalten einer App, die auf dem System-Image installiert ist, je nach Wert einer Ressource variieren. Anstatt den Ressourcenwert zur Buildzeit hartzucodieren, kann ein auf einer anderen Partition installiertes RRO die Werte der App-Ressourcen zur Laufzeit ändern. Weitere Informationen zu RROs finden Sie unter Wert der Ressourcen einer App zur Laufzeit ändern.
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2025-07-27 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-07-27 (UTC)."],[],[],null,["# Configuration overview\n\nAOSP offers the following options for storing configuration information on a\ndevice:\n\n- System properties\n- Hardware abstraction layer (HAL) properties\n- System config XML files\n- Resource overlays (static and runtime)\n\nSystem properties\n-----------------\n\n*System properties* are string key/value pairs stored in the `build.prop`\nglobal dictionary. System properties are system-wide resources that are easy to\nuse and have a low performance overhead. When using system properties, you don't\nneed to use interprocess communication (IPC) even if a system property is shared\nacross multiple processes. However, system properties are similar to global\nvariables and can be harmful when misused. The misuse of system properties can\nresult in issues such as security vulnerabilities and apps becoming inaccessible\nto users. Before using system properties to store configuration information,\nconsider the other configuration options.\n\nFor further information on system properties, see\n[Add system properties](/docs/core/architecture/configuration/add-system-properties)\n| **Note:** Previous to Android 10, AOSP used a ConfigStore HAL to store system properties. ConfigStore HAL is deprecated and should no longer be used. For information on the ConfigStore HAL, refer to [ConfigStore HAL](/docs/core/architecture/configuration/archive).\n\nHAL properties\n--------------\n\nWhen the source of truth for a configuration is from a hardware component on a\ndevice, the HAL for the hardware must provide the information for that\ncomponent. Define a new HAL method in the existing HAL for accessing the\nconfiguration. For further information on developing a HAL, see\n[AIDL for HALs](/docs/core/architecture/aidl/aidl-hals).\n| **Note:** Don't configure the HAL to use system properties as a side-channel communication mechanism for HALs.\n\nSystem config XML files\n-----------------------\n\nWhen the configuration data is static but complicated (structured), consider\nusing XML or other such formats for the configuration data. Ensure that the\nfile schema remains stable. For XML files, you can use\n[`xsd_config`](/docs/core/architecture/config-file-schema-api#config-build-rule)\nto keep the schema stable, and to take advantage of an autogenerated XML\nparser.\n\nResource overlay\n----------------\n\nYou can use resource overlays to customize a product. There are two types of\nresource overlays:\n\n- *Standard resource overlay* used to customize a product at build time. Foris\n information on standard resource overlays, see\n [Customizing the build with resource overlays](/docs/setup/create/new-device#use-resource-overlays).\n\n- *Runtime resource overlay (RRO)* is used to change the resource values\n of a target package at runtime. For example, an app installed on the system\n image might change its behavior based upon the value of a resource. Rather than\n hardcoding the resource value at build time, an RRO installed on a different\n partition can change the values of the app's resources at runtime. For more\n information on RROs, see\n [Change the value of an app's resources at runtime](/docs/core/runtime/rros)."]]
