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

Esta página foi traduzida pela API Cloud Translation.

Ativar o VNDK

O Kit de desenvolvimento nativo do fornecedor (VNDK) requer várias mudanças em uma base de código para separar as preocupações entre o fornecedor e o sistema. Use o guia a seguir para ativar o VNDK em um fornecedor/OEM de código aberto.

Bibliotecas do sistema de build

O sistema de build tem vários tipos de objetos, incluindo bibliotecas (compartilhado, estático ou cabeçalho) e binários.

Figura 1. Bibliotecas do sistema de build.

As bibliotecas core são usadas pela imagem do sistema. Esses as bibliotecas não podem ser usadas por vendor, vendor_available, vndk ou vndk-sp.
```
cc_library {
    name: "libThatIsCore",
    ...
}
```

As bibliotecas vendor-only (ou proprietary) são usadas pelas na imagem do fornecedor.

cc_library {
    name: "libThatIsVendorOnly",
    proprietary: true,
    # or: vendor: true, # (for things in AOSP)
    ...
}

As bibliotecas vendor_available são usadas pela imagem do fornecedor, no próprio fornecedor imagem (pode conter cópias de core).
```
cc_library {
    name: "libThatIsVendorAvailable",
    vendor_available: true,
    ...
}
```

As bibliotecas vndk são usadas pela imagem do fornecedor na imagem do sistema.

cc_library {
    name: "libThatIsVndk",
    vendor_available: true,
    vndk: {
        enabled: true,
    }
    ...
}

As bibliotecas vndk-sp são usadas pela imagem do fornecedor e também pela imagem do sistema indiretamente.

cc_library {
    name: "libThatIsVndkSp",
    vendor_available: true,
    vndk: {
        enabled: true,
        support_system_process: true,
    }
    ...
}

As bibliotecas llndk são usadas pelas imagens do sistema e do fornecedor.

cc_library {
    name: "libThatIsLlndk",
    llndk: {
        symbol_file: "libthatisllndk.map.txt"
    }
    ...
}

Quando uma lib é marcada como vendor_available:true, ela é criada duas vezes:

Uma vez para a plataforma (e, portanto, instalada em /system/lib)
Uma vez para o fornecedor (e, portanto, instalado em /vendor/lib ou VNDK APEX)

As versões de fornecedor das bibliotecas são criadas com -D__ANDROID_VNDK__. Componentes de sistema particular que podem mudar significativamente em versões futuras do Android são desativados com essa sinalização. Além disso, diferentes bibliotecas exportam um conjunto diferente de cabeçalhos (como liblog). Opções específicas para um A variante de fornecedor de um destino pode ser especificada em um arquivo Android.bp. em:

target: { vendor: { … } }

Ativar o VNDK para uma base de código

Para ativar o VNDK para uma base de código:

Determinar a qualificação calculando os tamanhos necessários de Partições vendor.img e system.img.
Ativar BOARD_VNDK_VERSION=current. Você pode adicionar a BoardConfig.mk ou crie componentes diretamente com ele (por exemplo, m -j BOARD_VNDK_VERSION=current MY-LIB).

Depois de ativar BOARD_VNDK_VERSION=current, o sistema de build aplica os seguintes requisitos de dependência e cabeçalho.

Gerenciar dependências

Um objeto vendor que depende de um componente core. que não existe em vndk ou como um objeto vendor deve ser resolvido usando uma das seguintes opções:

A dependência pode ser removida.
Se o componente core pertencer a vendor, ele pode marcado como vendor_available ou vendor.
Uma mudança que torna o objeto principal parte do vndk pode ser enviados ao Google.

Além disso, se um componente core tiver dependências em um componente vendor, o componente vendor precisa ser criado em um componente core ou a dependência precisa ser removidas de outra forma (por exemplo, removendo a dependência ou movendo o dependência em um componente vendor).

Gerenciar cabeçalhos

As dependências de cabeçalho globais precisam ser removidas para permitir que o sistema de build saiba se os cabeçalhos serão criados com ou sem -D__ANDROID_VNDK__. Por exemplo, cabeçalhos de libutils como utils/StrongPointer.h podem ainda podem ser acessados usando a biblioteca de cabeçalho libutils_headers.

Alguns cabeçalhos (como unistd.h) não podem mais ser incluídos de forma transitiva mas podem ser incluídos localmente.

Por fim, a parte pública de private/android_filesystem_config.h foi movido para cutils/android_filesystem_config.h. Para gerenciar esses cabeçalhos, siga um destes procedimentos:

Remova a dependência private/android_filesystem_config.h substituindo todos AID_* macros com getgrnam/ getpwnam, se possível. Por exemplo:
- (uid_t)AID_WIFI se torna getpwnam("wifi")->pw_uid.
- (gid_t)AID_SDCARD_R se torna getgrnam("sdcard_r")->gr_gid.
. Para mais detalhes, consulte private/android_filesystem_config.h.
Para o AIS codificado, inclua cutils/android_filesystem_config.h: