Właściwości systemowe pozwalają w wygodny sposób udostępniać informacje, zwykle
w całym systemie. Każda partycja może używać wewnętrznie własnych właściwości systemowych. Problem może wystąpić, gdy dostęp do usług jest uzyskiwany na różnych partycjach, np. gdy /vendor
uzyskuje dostęp do właściwości zdefiniowanych przez /system
. Od Androida 8.0 niektóre partycje, takie jak /system
, można uaktualnić, podczas gdy element /vendor
pozostaje bez zmian. Właściwości systemu są tylko globalnym słownikiem par klucz-wartość ciągu
bez schematu, więc trudno jest je ustabilizować. 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 systemowe dostępne na partycjach są przedstawione w formie plików opisu Sysprop, a interfejsy API umożliwiające dostęp do właściwości są generowane jako konkretne funkcje w językach C++ i Rust oraz w klasach dla Javy. Te interfejsy API są wygodniejsze w użyciu, ponieważ dostęp do nich nie wymaga żadnych magicznych ciągów znaków (takich jak ro.build.date
) i można je wpisywać statycznie. Stabilność ABI jest także sprawdzana w czasie kompilacji, a kompilacja ulega awarii w przypadku niezgodnych zmian. Ta kontrola działa jako jawnie zdefiniowane interfejsy między partycjami. Te interfejsy API mogą też zapewnić spójność między
Rust, Java i C++.
Zdefiniuj właściwości systemu jako interfejsy API
Definiuj właściwości systemu jako interfejsy API z plikami opisu Sysprop (.sysprop
), które korzystają z metody TextFormat protokołu protobuf, zgodnie z tym 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 zbiór właściwości. Jego pola mają następujące znaczenie.
Pole | Znaczenie |
---|---|
owner
|
Ustaw na partycję, do której należą 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 to przestrzeń nazw com::android::sysprop::BuildProperties w języku C++, a klasa BuildProperties w pakiecie w com.android.sysprop w języku Java.
|
prop
|
Lista usług. |
Poniżej przedstawiono znaczenie pól komunikatu Property
.
Pole | Znaczenie |
---|---|
api_name
|
Nazwa wygenerowanego interfejsu API. |
type
|
Typ właściwości. |
access
|
Readonly : generuje tylko interfejs API getter
Writeonce , ReadWrite : generuje interfejsy API pobierania i ustawiania
Uwaga: usługi z prefiksem ro. nie mogą korzystać z dostępu ReadWrite .
|
scope
|
Internal : ma dostęp tylko właściciel.
Public : wszyscy mają dostęp, z wyjątkiem modułów NDK.
|
prop_name
|
Nazwa bazowej właściwości systemu, np. ro.build.date .
|
enum_values
|
(Enum , tylko EnumList ) Ciąg znaków rozdzielony słupkiem (-), który składa się z możliwych wartości wyliczeniowych. Na przykład: value1|value2 .
|
integer_as_bool
|
(Boolean , tylko BooleanList ) Konfigurujący mogą używać właściwości 0 i 1 zamiast false i true .
|
legacy_prop_name
|
(opcjonalnie, tylko: Readonly ) Starsza nazwa bazowej właściwości systemowej. Podczas wywoływania metody getter API próbuje odczytać zasadę prop_name , a jeśli prop_name nie istnieje, używa metody legacy_prop_name . Użyj legacy_prop_name podczas wycofywania istniejącej usługi i przenoszenia jej do nowej.
|
Każdy typ właściwości jest mapowany na następujące typy w językach C++, Java i Rust.
Typ | C++ | Java | Rust |
---|---|---|---|
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
|
Ulong | std::optional<std::uint64_t>
|
Optional<Long>
|
u64
|
Podwójny | std::optional<double>
|
Optional<Double>
|
f64
|
Ciąg znaków | 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ładowy plik z opisem tworzony przez Sysprop zawierający 3 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
}
Zdefiniuj biblioteki właściwości systemu
Teraz możesz definiować moduły sysprop_library
za pomocą plików opisu Sysprop.
sysprop_library
służy jako interfejs API dla C++, Java i Rust. System kompilacji wewnętrznie generuje 1 rust_library
, 1 java_library
i 1 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,
}
W źródle musisz uwzględnić pliki z listami interfejsów API na potrzeby kontroli interfejsu API. W tym celu utwórz pliki interfejsu API i katalog api
. Umieść katalog api
w tym samym katalogu co Android.bp
. Nazwy plików interfejsu API to <module_name>-current.txt
, <module_name>-latest.txt
. <module_name>-current.txt
zawiera podpisy interfejsów API bieżących kodów źródłowych, a <module_name>-latest.txt
zawiera najnowsze zablokowane podpisy interfejsów API. System kompilacji sprawdza, czy interfejsy API nie uległy zmianie, porównując te pliki interfejsu API z wygenerowanymi plikami API w czasie kompilacji i wysyła komunikat o błędzie oraz instrukcje aktualizacji pliku current.txt
, jeśli current.txt
nie pasuje do kodów źródłowych. Oto przykładowy katalog i organizacja plików:
├── api
│ ├── PlatformProperties-current.txt
│ └── PlatformProperties-latest.txt
└── Android.bp
Moduły klienckie Rust, Java i C++ można łączyć z sysprop_library
, aby używać wygenerowanych interfejsów API. System kompilacji tworzy połączenia klientów z wygenerowanymi bibliotekami C++, Java i Rust, dzięki czemu klienci mają 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"],
}
Nazwa biblioteki Rust jest generowana przez przekształcenie nazwy sysprop_library
w małe litery, zastąpienie .
i -
ciągiem _
, a następnie dodanie na początku lib
i _rust
.
W poprzednim przykładzie dostęp do zdefiniowanych właściwości można było uzyskać w ten sposób.
Przykład Rust:
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 w Javie:
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 w 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);
}
…
}
…