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.

Habilitando o VNDK

O VNDK requer várias alterações em uma base de código para separar as preocupações entre o fornecedor e o sistema. Use o guia a seguir para habilitar o VNDK em uma base de código de fornecedor/OEM.

Crie bibliotecas do sistema

O sistema de compilação contém vários tipos de objetos, incluindo bibliotecas (compartilhadas, estáticas ou de cabeçalho) e binários.

Figura 1. Construir bibliotecas do sistema

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

bibliotecas vendor-only (ou proprietary ) são usadas pela imagem do fornecedor, 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, na imagem do fornecedor (pode conter duplicatas do 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 é construída duas vezes:

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

As versões do fornecedor de libs são construídas com -D__ANDROID_VNDK__ . Os componentes do sistema privado que podem mudar significativamente em versões futuras do Android são desabilitados com esse sinalizador. Além disso, bibliotecas diferentes exportam um conjunto diferente de cabeçalhos (como liblog ). As opções específicas de uma variante de fornecedor de um destino podem ser especificadas em um arquivo Android.bp em:

target: { vendor: { … } }

Habilitando o VNDK para uma base de código

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

Determine a elegibilidade calculando os tamanhos necessários das partições vendor.img e system.img .
Ative BOARD_VNDK_VERSION=current . Você pode adicionar ao BoardConfig.mk ou construir componentes diretamente com ele (por exemplo, m -j BOARD_VNDK_VERSION=current MY-LIB ).

Depois de habilitar BOARD_VNDK_VERSION=current , o sistema de compilação impõe os seguintes requisitos de dependência e cabeçalho.

Gerenciando dependências

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

A dependência pode ser removida.
Se o componente core for de propriedade do vendor , ele poderá ser marcado como vendor_available ou vendor .
Uma alteração que torna o objeto principal parte do vndk pode ser enviada para o Google.

Além disso, se um componente core tiver dependências de um componente do vendor , o componente do vendor deve ser transformado em um componente core ou a dependência deve ser removida de outra forma (por exemplo, removendo a dependência ou movendo a dependência para um componente do vendor ).

Gerenciando cabeçalhos

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

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

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

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