Ativar o VNDK

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

Criar bibliotecas do sistema

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

Figura 1. Crie bibliotecas do sistema.

• As bibliotecas core são usadas pela imagem do sistema. Essas bibliotecas não podem ser usadas pelas bibliotecas vendor, vendor_available, vndk ou vndk-sp.

  cc_library {
      name: "libThatIsCore",
      ...
  }

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

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

• As bibliotecas vendor_available são usadas na imagem do fornecedor, que pode 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 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 biblioteca é marcada como vendor_available:true, ela é criada duas vezes:

• Uma vez por 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 criadas com -D__ANDROID_VNDK__. Os componentes privados do sistema que podem mudar significativamente em versões futuras do Android são desativados com essa flag. Além disso, bibliotecas diferentes exportam um conjunto diferente de cabeçalhos, como liblog. As opções específicas de uma variante do fornecedor de uma meta podem ser especificadas em um arquivo Android.bp em:

target: { vendor: { … } }

Ativar o VNDK para uma base de código

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

1. Calcule os tamanhos necessários das partições vendor.img e system.img para determinar a qualificação.
2. Ativar BOARD_VNDK_VERSION=current. Você pode adicionar ao BoardConfig.mk ou criar componentes diretamente com ele (por exemplo, m -j BOARD_VNDK_VERSION=current MY-LIB).

Depois de ativar o BOARD_VNDK_VERSION=current, o sistema de build vai aplicar 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 precisa ser resolvido usando uma das seguintes opções:

• A dependência pode ser removida.
• Se o componente core for de propriedade de vendor, ele poderá ser marcado como vendor_available ou vendor.
• Uma mudança que torna 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 precisará ser transformado em um componente core ou a dependência precisará ser removida de outra forma (por exemplo, removendo a dependência ou movendo-a para um componente vendor).

Gerenciar cabeçalhos

As dependências de cabeçalho global precisam ser removidas para permitir que o sistema de build saiba se os cabeçalhos devem ser criados com ou sem -D__ANDROID_VNDK__. Por exemplo, os cabeçalhos libutils, como utils/StrongPointer.h, 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 movida para cutils/android_filesystem_config.h. Para gerenciar esses cabeçalhos, faça o seguinte:

• 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 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 AIS codificados, inclua cutils/android_filesystem_config.h.