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 preocupações entre o fornecedor e o sistema. Use o guia a seguir para ativar o VNDK em uma base de código do 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. Bibliotecas do sistema de build.

• 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 (podem conter duplicados 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 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 de fornecedor das bibliotecas são criadas com -D__ANDROID_VNDK__. Os componentes do sistema particular 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 para uma variante de 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. Ative 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 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 precisa 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 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 em 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 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 codificados, inclua cutils/android_filesystem_config.h.