Ativar o VNDK

O kit de desenvolvimento nativo do fornecedor (VNDK, na sigla em inglês) 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 repositório 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 pela imagem do fornecedor, na imagem do fornecedor (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 de forma indireta.

  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 é gerada duas vezes:

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

As versões do fornecedor das bibliotecas são criadas com -D__ANDROID_VNDK__. Componentes de sistema particulares 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 um destino podem ser especificadas 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:

1. Determine a qualificação calculando os tamanhos necessários das partições vendor.img e system.img.
2. Ativar BOARD_VNDK_VERSION=current. É possível adicionar ao BoardConfig.mk ou criar componentes com ele diretamente (por exemplo, m -j BOARD_VNDK_VERSION=current MY-LIB).

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

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 encaminhada para o Google.

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

Gerenciar cabeçalhos

As dependências de cabeçalho globais precisam ser removidas para que o sistema de build saiba se deve criar 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.

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, 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 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 codificado, inclua cutils/android_filesystem_config.h.