Właściwości systemu zapewniają wygodny sposób udostępniania informacji, zwykle konfiguracji, w całym systemie. Każda partycja może wewnętrznie używać własnych właściwości systemowych. Problem może wystąpić, gdy dostęp do właściwości jest uzyskiwany z różnych partycji, np. /vendor
uzyskuje dostęp /system
. Od wersji Androida 8.0 niektóre partycje, takie jak /system
, można zaktualizować, podczas gdy /vendor
pozostaje niezmieniony. Ponieważ właściwości systemu są po prostu globalnym słownikiem par klucz/wartość ciągu bez schematu, trudno jest ustabilizować właściwości. Partycja /system
może bez powiadomienia zmienić lub usunąć właściwości, od których zależy partycja /vendor
.
Począwszy od wersji Androida 10, właściwości systemu, do których można uzyskać dostęp między partycjami, są schematycznie przedstawiane w plikach opisu Sysprop, a interfejsy API umożliwiające dostęp do właściwości są generowane jako konkretne funkcje dla C++ i Rust oraz klasy dla Javy. Te interfejsy API są wygodniejsze w użyciu, ponieważ do uzyskania dostępu nie są potrzebne żadne magiczne ciągi znaków (takie jak ro.build.date
) i ponieważ można je wpisywać statycznie. Stabilność ABI jest również sprawdzana w czasie kompilacji, a kompilacja ulega awarii, jeśli nastąpią niezgodne zmiany. To sprawdzenie działa jak jawnie zdefiniowane interfejsy pomiędzy partycjami. Te interfejsy API mogą również zapewnić spójność pomiędzy Rust, Java i C++.
Definiowanie właściwości systemu jako API
Zdefiniuj właściwości systemu jako interfejsy API za pomocą plików opisu Sysprop ( .sysprop
), które używają formatu TextFormat protobuf, z następującym schematem:
// File: sysprop.proto
syntax = "proto3";
package sysprop;
enum Access {
Readonly = 0;
Writeonce = 1;
ReadWrite = 2;
}
enum Owner {
Platform = 0;
Vendor = 1;
Odm = 2;
}
enum Scope {
Public = 0;
Internal = 2;
}
enum Type {
Boolean = 0;
Integer = 1;
Long = 2;
Double = 3;
String = 4;
Enum = 5;
UInt = 6;
ULong = 7;
BooleanList = 20;
IntegerList = 21;
LongList = 22;
DoubleList = 23;
StringList = 24;
EnumList = 25;
UIntList = 26;
ULongList = 27;
}
message Property {
string api_name = 1;
Type type = 2;
Access access = 3;
Scope scope = 4;
string prop_name = 5;
string enum_values = 6;
bool integer_as_bool = 7;
string legacy_prop_name = 8;
}
message Properties {
Owner owner = 1;
string module = 2;
repeated Property prop = 3;
}
Jeden plik opisu Sysprop zawiera jeden komunikat właściwości, który opisuje zestaw właściwości. Znaczenie jego pól jest następujące.
Pole | Oznaczający |
---|---|
owner | Ustaw partycję posiadającą właściwości: Platform , Vendor lub Odm . |
module | Służy do tworzenia przestrzeni nazw (C++) lub statycznej klasy końcowej (Java), w której umieszczane są wygenerowane interfejsy API. Na przykład com.android.sysprop.BuildProperties będzie przestrzenią nazw com::android::sysprop::BuildProperties w C++, a klasa BuildProperties w pakiecie w com.android.sysprop w Javie. |
prop | Lista nieruchomości. |
Znaczenie pól komunikatów Property
jest następujące.
Pole | Oznaczający |
---|---|
api_name | Nazwa wygenerowanego interfejsu API. |
type | Typ tej właściwości. |
access | Readonly : generuje tylko API modułu pobierającego Uwaga: Właściwości z przedrostkiem |
scope | Internal : dostęp ma tylko właściciel. |
prop_name | Nazwa podstawowej właściwości systemowej, na przykład ro.build.date . |
enum_values | (Tylko Enum , EnumList ) Łańcuch rozdzielony kreskami(|) składający się z możliwych wartości wyliczeniowych. Na przykład value1|value2 . |
integer_as_bool | (Tylko Boolean , BooleanList ) Spraw, aby ustawiacze używali 0 i 1 zamiast false i true . |
legacy_prop_name | (opcjonalne, tylko właściwości tylko Readonly ) Starsza nazwa podstawowej właściwości systemowej. Podczas wywoływania modułu pobierającego interfejs API pobierającego próbuje odczytać prop_name i używa legacy_prop_name , jeśli prop_name nie istnieje. Użyj legacy_prop_name podczas wycofywania istniejącej usługi i przenoszenia się do nowej usługi. |
Każdy typ właściwości jest mapowany na następujące typy w językach C++, Java i Rust.
Typ | C++ | Jawa | Rdza |
---|---|---|---|
Wartość logiczna | std::optional<bool> | Optional<Boolean> | bool |
Liczba całkowita | std::optional<std::int32_t> | Optional<Integer> | i32 |
UInt | std::optional<std::uint32_t> | Optional<Integer> | u32 |
Długi | std::optional<std::int64_t> | Optional<Long> | i64 |
UDługa | std::optional<std::uint64_t> | Optional<Long> | u64 |
Podwójnie | std::optional<double> | Optional<Double> | f64 |
Strunowy | std::optional<std::string> | Optional<String> | String |
Wyliczenie | std::optional<{api_name}_values> | Optional<{api_name}_values> | {ApiName}Values |
Lista T | std::vector<std::optional<T>> | List<T> | Vec<T> |
Oto przykład pliku opisu Sysprop definiującego trzy właściwości:
# File: android/sysprop/PlatformProperties.sysprop
owner: Platform
module: "android.sysprop.PlatformProperties"
prop {
api_name: "build_date"
type: String
prop_name: "ro.build.date"
scope: Public
access: Readonly
}
prop {
api_name: "date_utc"
type: Integer
prop_name: "ro.build.date_utc"
scope: Internal
access: Readonly
}
prop {
api_name: "device_status"
type: Enum
enum_values: "on|off|unknown"
prop_name: "device.status"
scope: Public
access: ReadWrite
}
Definiowanie bibliotek właściwości systemu
Można teraz definiować moduły sysprop_library
za pomocą plików opisu Sysprop. sysprop_library
służy jako API dla C++, Java i Rust. System kompilacji generuje wewnętrznie jedną rust_library
, jedną java_library
i jedną cc_library
dla każdej instancji sysprop_library
.
// File: Android.bp
sysprop_library {
name: "PlatformProperties",
srcs: ["android/sysprop/PlatformProperties.sysprop"],
property_owner: "Platform",
vendor_available: true,
}
Aby umożliwić sprawdzenie interfejsu API, w źródle należy uwzględnić pliki z listami API. Aby to zrobić, utwórz pliki API i katalog api
. Umieść katalog api
w tym samym katalogu co Android.bp
. Nazwy plików API to <module_name>-current.txt
, <module_name>-latest.txt
. <module_name>-current.txt
zawiera podpisy API bieżących kodów źródłowych, a <module_name>-latest.txt
zawiera najnowsze zamrożone podpisy API. System kompilacji sprawdza, czy interfejsy API zostały zmienione, porównując te pliki API z wygenerowanymi plikami API w czasie kompilacji i generuje komunikat o błędzie oraz instrukcje dotyczące aktualizacji pliku current.txt
, jeśli current.txt
nie jest zgodny z kodami źródłowymi. Oto przykładowa organizacja katalogów i plików:
├── api
│ ├── PlatformProperties-current.txt
│ └── PlatformProperties-latest.txt
└── Android.bp
Moduły klienta Rust, Java i C++ mogą łączyć się z sysprop_library
, aby korzystać z wygenerowanych interfejsów API. System kompilacji tworzy łącza od klientów do wygenerowanych bibliotek C++, Java i Rust, zapewniając w ten sposób klientom dostęp do wygenerowanych interfejsów API.
java_library {
name: "JavaClient",
srcs: ["foo/bar.java"],
libs: ["PlatformProperties"],
}
cc_binary {
name: "cc_client",
srcs: ["baz.cpp"],
shared_libs: ["PlatformProperties"],
}
rust_binary {
name: "rust_client",
srcs: ["src/main.rs"],
rustlibs: ["libplatformproperties_rust"],
}
Zauważ, że nazwa biblioteki Rust jest generowana poprzez konwersję nazwy sysprop_library
na małe litery, zastępując .
i -
z _
, a następnie poprzedzając lib
i dodając _rust
.
W powyższym przykładzie można uzyskać dostęp do zdefiniowanych właściwości w następujący sposób.
Przykład rdzy:
use platformproperties::DeviceStatusValues;
fn foo() -> Result<(), Error> {
// Read "ro.build.date_utc". default value is -1.
let date_utc = platformproperties::date_utc()?.unwrap_or_else(-1);
// set "device.status" to "unknown" if "ro.build.date" is not set.
if platformproperties::build_date()?.is_none() {
platformproperties::set_device_status(DeviceStatusValues::UNKNOWN);
}
…
}
Przykład Java:
import android.sysprop.PlatformProperties;
…
static void foo() {
…
// read "ro.build.date_utc". default value is -1
Integer dateUtc = PlatformProperties.date_utc().orElse(-1);
// set "device.status" to "unknown" if "ro.build.date" is not set
if (!PlatformProperties.build_date().isPresent()) {
PlatformProperties.device_status(
PlatformProperties.device_status_values.UNKNOWN
);
}
…
}
…
Przykład C++:
#include <android/sysprop/PlatformProperties.sysprop.h>
using namespace android::sysprop;
…
void bar() {
…
// read "ro.build.date". default value is "(unknown)"
std::string build_date = PlatformProperties::build_date().value_or("(unknown)");
// set "device.status" to "on" if it's "unknown" or not set
using PlatformProperties::device_status_values;
auto status = PlatformProperties::device_status();
if (!status.has_value() || status.value() == device_status_values::UNKNOWN) {
PlatformProperties::device_status(device_status_values::ON);
}
…
}
…