O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Implementando Propriedades do Sistema como APIs

As propriedades do sistema fornecem uma maneira conveniente de compartilhar informações, geralmente configurações, em todo o sistema. Cada partição pode usar suas próprias propriedades de sistema internamente. Um problema pode acontecer quando as propriedades são acessados através de partições, como /vendor acessando /system propriedades -definida. Desde Android 8.0, algumas partições, como /system , pode ser atualizado, enquanto /vendor é deixado inalterado. Como as propriedades do sistema são apenas um dicionário global de pares de chave / valor de string sem esquema, é difícil estabilizar as propriedades. O /system partição poderia mudar ou propriedades de remover essa a /vendor partição depende, sem qualquer aviso prévio.

A partir da versão Android 10, as propriedades do sistema acessadas através das partições são esquematizadas em arquivos de descrição Sysprop, e APIs para acessar as propriedades são geradas como funções concretas para C ++ e classes para Java. Essas APIs são mais convenientes de usar, porque sem cordas mágicas (como ro.build.date são necessários) para o acesso, e porque eles podem ser tipagem estática. A estabilidade da ABI também é verificada no momento da construção, e a construção será interrompida se ocorrerem alterações incompatíveis. Esta verificação atua como interfaces definidas explicitamente entre as partições. Essas APIs também podem fornecer consistência entre Java e C ++.

Definindo propriedades do sistema como APIs

Definir as propriedades do sistema como APIs com arquivos Sysprop Inscrição ( .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 Sysprop contém uma mensagem de propriedades, que descreve um conjunto de propriedades. O significado de seus campos são os seguintes.

Campo Significado
owner Definido para a partição que possui as propriedades: Platform , Vendor , ou Odm .
module Usado para criar um namespace (C ++) ou classe final estática (Java) na qual as APIs geradas são colocadas. Por exemplo, com.android.sysprop.BuildProperties será namespace com::android::sysprop::BuildProperties em C ++, ea BuildProperties classe no pacote em com.android.sysprop em Java.
prop Lista de propriedades.

Os significados dos Property campos da mensagem são os seguintes.

Campo Significado
api_name O nome da API gerada.
type O tipo desta propriedade.
access Readonly : gera apenas API getter

Writeonce , ReadWrite : Gera APIs get e set

Nota: As propriedades com o prefixo ro. não pode usar ReadWrite acesso.

scope Internal : Somente o proprietário pode acessar.

Public : todos podem acessar, exceto para módulos NDK.

prop_name O nome da propriedade do sistema subjacente, por exemplo ro.build.date .
enum_values ( Enum , EnumList apenas) A barra (|) Cadeia -separated que consiste em possíveis valores enum. Por exemplo, value1|value2 .
integer_as_bool ( Boolean , BooleanList apenas) setters fazer uso 0 e 1 em vez de false e true .
legacy_prop_name (opcional, Readonly propriedades só) O nome legado da propriedade do sistema subjacente. Ao chamar getter, as tentativas getter API para ler prop_name e usos legacy_prop_name se prop_name não existe. Use legacy_prop_name quando depreciativo uma propriedade existente e se mudar para uma nova propriedade.

Cada tipo de propriedade mapeia para os seguintes tipos em C ++ e Java.

Modelo C ++ Java
boleano std::optional<bool> Optional<Boolean>
Inteiro std::optional<std::int32_t> Optional<Integer>
UInt std::optional<std::uint32_t> Optional<Integer>
Grande std::optional<std::int64_t> Optional<Long>
ULong std::optional<std::uint64_t> Optional<Long>
Dobro std::optional<double> Optional<Double>
Fragmento std::optional<std::string> Optional<String>
Enum std::optional<{api_name}_values> Optional<{api_name}_values>
Lista T std::vector<std::optional<T>> List<T>

Aqui está um exemplo de um arquivo de descrição Sysprop definindo 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
}

Definindo bibliotecas de propriedades do sistema

Agora você pode definir sysprop_library módulos com Sysprop Inscrição arquivos. sysprop_library serve como uma API para ambos C ++ e Java. O sistema de construção gera internamente um java_library e um cc_library para cada instância do sysprop_library .

// File: Android.bp
sysprop_library {
    name: "PlatformProperties",
    srcs: ["android/sysprop/PlatformProperties.sysprop"],
    property_owner: "Platform",
    vendor_available: true,
}

Você deve incluir arquivos de listas de API na fonte para verificações de API. Para fazer isso, criar arquivos de API e uma api diretório. Coloque a api diretório no mesmo diretório que Android.bp . Os nomes de arquivos API são <module_name>-current.txt , <module_name>-latest.txt . <module_name>-current.txt detém as assinaturas de API de códigos de fonte de corrente, e <module_name>-latest.txt detém as últimas assinaturas de API congelados. O sistema verifica se a construção APIs são alteradas, comparando esses arquivos API com arquivos API geradas em tempo de compilação e emite uma mensagem de erro e instruções para atualizar current.txt arquivo se current.txt não coincide com os códigos fonte. Aqui está um exemplo de diretório e organização de arquivos:

├── api
│   ├── PlatformProperties-current.txt
│   └── PlatformProperties-latest.txt
└── Android.bp

Java e módulos de cliente C ++ pode ligar contra sysprop_library usar APIs gerados. O sistema de construção cria links de clientes para bibliotecas C ++ e Java geradas, dando aos clientes acesso às APIs geradas.

java_library {
    name: "JavaClient",
    srcs: ["foo/bar.java"],
    libs: ["PlatformProperties"],
}

cc_binary {
    name: "cc_client",
    srcs: ["baz.cpp"],
    shared_libs: ["PlatformProperties"],
}

No exemplo acima, você pode acessar as propriedades definidas a seguir.

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 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);
    }
    …
}
…