As propriedades do sistema oferecem uma maneira conveniente de compartilhar informações, geralmente
configurações em todo o sistema. Cada partição pode usar as próprias propriedades do sistema
internamente. Um problema pode acontecer quando propriedades são acessadas em partições,
como o /vendor
, que acessa as propriedades definidas por /system
. Desde o Android 8.0,
algumas partições, como /system
, podem ser atualizadas, enquanto /vendor
permanece
inalterada. Como as propriedades do sistema são apenas um dicionário global de
pares de chave-valor sem esquema, é difícil estabilizar as propriedades. A partição
/system
pode mudar ou remover propriedades das quais a partição
/vendor
depende sem aviso prévio.
A partir da versão do Android 10, as propriedades do sistema
acessados entre partições são esquematizados em arquivos de descrição do Sysprop, e
As APIs para acessar propriedades são geradas como funções concretas para C++ e Rust,
e classes para Java. Essas APIs são mais convenientes de usar porque não há mágica
strings (como ro.build.date
) são necessárias para o acesso e porque elas podem ser
tipada estaticamente. A estabilidade da ABI também é verificada no tempo de build, e o build
falha em caso de alterações incompatíveis. Essa verificação atua como definido explicitamente
interfaces de rede entre partições. Essas APIs também podem fornecer consistência entre
Rust, Java e C++.
Definir propriedades do sistema como APIs
Defina as propriedades do sistema como APIs com arquivos de descrição Sysprop (.sysprop
),
que usam um TextFormat de protobuf, com o seguinte esquema:
// 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;
}
Um arquivo de descrição de Sysprop contém uma mensagem de propriedades, que descreve um conjunto de propriedades. O significado dos campos é o seguinte.
Campo | Significado |
---|---|
owner
|
Defina como a partição proprietária das propriedades: Platform ,
Vendor ou Odm .
|
module
|
Usado para criar um namespace (C++) ou uma classe final estática (Java) em que
APIs geradas são colocadas. Por exemplo:
com.android.sysprop.BuildProperties
será o namespace com::android::sysprop::BuildProperties em C++,
e a classe BuildProperties no pacote
com.android.sysprop em Java.
|
prop
|
Lista de propriedades. |
Os significados dos campos de mensagem Property
são os seguintes.
Campo | Significado |
---|---|
api_name
|
O nome da API gerada. |
type
|
O tipo dessa propriedade. |
access
|
Readonly : gera apenas a API getter
Writeonce , ReadWrite : gera APIs getter e setter
Observação: propriedades com o prefixo ro. não podem usar
ReadWrite .
|
scope
|
Internal : somente o proprietário pode acessar.
Public : todos podem acessar, exceto os módulos do NDK.
|
prop_name
|
O nome da propriedade subjacente do sistema, por exemplo
ro.build.date :
|
enum_values
|
(Enum , EnumList apenas) Uma string separada por barra (|)
que consiste em possíveis valores de tipo enumerado. Por exemplo, value1|value2 .
|
integer_as_bool
|
(Somente Boolean , BooleanList ) Fazer com que os setters usem
0 e 1 em vez de false e
true .
|
legacy_prop_name
|
(opcional, somente propriedades Readonly ) O nome legado do
propriedade do sistema subjacente. Ao chamar o getter, a API tenta ler
prop_name e usará legacy_prop_name se
prop_name não existe. Usar legacy_prop_name quando
descontinuar uma propriedade existente e movê-la para uma nova.
|
Cada tipo de propriedade é mapeado para os seguintes tipos em C++, Java e Rust.
Tipo | C++ | Java | Rust |
---|---|---|---|
Booleano | std::optional<bool>
|
Optional<Boolean>
|
bool
|
Número inteiro | std::optional<std::int32_t>
|
Optional<Integer>
|
i32
|
Interface | std::optional<std::uint32_t>
|
Optional<Integer>
|
u32
|
Longo | std::optional<std::int64_t>
|
Optional<Long>
|
i64
|
Longo | std::optional<std::uint64_t>
|
Optional<Long>
|
u64
|
Duplo | std::optional<double>
|
Optional<Double>
|
f64
|
String | std::optional<std::string>
|
Optional<String>
|
String
|
Enum | std::optional<{api_name}_values>
|
Optional<{api_name}_values>
|
{ApiName}Values
|
Lista T | std::vector<std::optional<T>>
|
List<T>
|
Vec<T>
|
Confira um exemplo de um arquivo de descrição de Sysprop que define três propriedades:
# 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
}
Definir bibliotecas de propriedades do sistema
Agora é possível definir módulos sysprop_library
com arquivos de descrição do Sysprop.
sysprop_library
serve como uma API para C++, Java e Rust. O sistema de build
gera internamente um rust_library
, um java_library
e um cc_library
.
para cada instância de sysprop_library
.
// File: Android.bp
sysprop_library {
name: "PlatformProperties",
srcs: ["android/sysprop/PlatformProperties.sysprop"],
property_owner: "Platform",
vendor_available: true,
}
Você precisa incluir arquivos de listas de API na origem para verificações de API. Para isso,
criar arquivos de API e um diretório api
. Coloque o diretório api
no mesmo
como Android.bp
. Os nomes dos arquivos da API são <module_name>-current.txt
,
<module_name>-latest.txt
. <module_name>-current.txt
contém as assinaturas da API.
dos códigos-fonte atuais, e <module_name>-latest.txt
contém os dados congelados mais recentes
assinaturas de API. O sistema de build verifica se as APIs são alteradas
comparando esses arquivos de API com os arquivos de API gerados no tempo de compilação e emite um
mensagem de erro e instruções para atualizar o arquivo current.txt
se current.txt
não corresponde aos códigos-fonte. Este é um exemplo de diretório e arquivo
organização:
├── api
│ ├── PlatformProperties-current.txt
│ └── PlatformProperties-latest.txt
└── Android.bp
Os módulos de cliente Rust, Java e C++ podem ser vinculados a sysprop_library
para uso.
APIs geradas. O sistema de build cria links de clientes para o C++ gerado,
Bibliotecas Java e Rust, permitindo que os clientes acessem APIs geradas.
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"],
}
O nome da biblioteca do Rust é gerado pela conversão do sysprop_library
.
nome em letras minúsculas, substituindo .
e -
por _
e, em seguida, adicionando lib
e
incluindo _rust
.
No exemplo anterior, era possível acessar as propriedades definidas da seguinte maneira.
Exemplo do 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);
}
…
}
Exemplo de 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
);
}
…
}
…
Exemplo de 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);
}
…
}
…