Habilitando o VNDK

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

Crie bibliotecas de 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 de 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 (podem conter duplicatas 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 indiretamente pela imagem do sistema.

  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 o fornecedor (e, portanto, instalado em /vendor/lib ou VNDK APEX)

As versões de fornecedor das bibliotecas são construídas com -D__ANDROID_VNDK__ . Os componentes privados do sistema que podem mudar significativamente em versões futuras do Android são desativados com este sinalizador. Além disso, diferentes bibliotecas exportam um conjunto diferente de cabeçalhos (como liblog ). Opções específicas para 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 ativar o VNDK para uma base de código:

1. Determine a elegibilidade calculando os tamanhos necessários das partições vendor.img e system.img .
2. Habilite 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 ativar 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 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 poderá ser marcado como vendor_available ou vendor .
• Uma alteração que torne o objeto principal parte do vndk pode ser enviada ao Google.

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

Gerenciando cabeçalhos

As dependências de cabeçalho globais 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 transitivamente, 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("sdcard_r")->gr_gid .
  Para obter detalhes, consulte private/android_filesystem_config.h .
• Para AIS codificado, inclua cutils/android_filesystem_config.h .