Artigo de Dan Albert, publicado originalmente pelo Android Security Team. A tradução foi feita pela Redação iMasters com autorização.

 

 

A versão mais recente do Android Native Development Kit (NDK), o Android NDK r14, está agora disponível para download. Ele também está disponível no gerenciador SDK via Android Studio.

Então, o que há de novo no r14? O changelog completo pode ser visto aqui, mas os destaques incluem o seguinte:

• Atualizados todos os headers da plataforma para heards unificados (detalhados abaixo)
• LTO com Clang agora funciona no Darwin e no Linux
• libc++ foi atualizado. Agora você pode usar thread_local para statics com destrutores não triviais (somente Clang)
• RenderScript está de volta!

Headers Unificados

Refizemos completamente a forma como enviamos arquivos de header de plataforma no NDK. Em vez de ter um conjunto de headers para cada nível de API de destino, existe agora um único conjunto. A disponibilidade de APIs para cada plataforma Android é guardada nesses headers por diretivas de pré-processador #if __ANDROID_API__> = __ANDROID_API_FOO__.

A abordagem prévia baseava-se em instantâneos capturados periodicamente dos headers da plataforma. Isso significava que sempre que corrigíamos um erro de header apenas, a correção só estava disponível na versão mais recente além do backport ocasional. Agora, as correções de erros estão disponíveis independentemente do nível da sua API NDK.

Aparte das correções de erros, isso também significa que você terá acesso a modernos headers Linux UAPI em cada versão de destino. Isso será principalmente importante para as pessoas que portam o código Linux existente (especialmente coisas de baixo nível). Algo importante a ter em mente: apenas porque você tem os headers não significa que você está executando em um dispositivo com um kernel novo o suficiente para suportar todos os syscall. Como sempre com syscalls, ENOSYS é uma possibilidade.

Além dos headers Linux, você também terá headers modernos para OpenGL, OpenSLES, etc. Isso deve facilitar a utilização condicional de novas APIs quando você tiver um nível de API de destino mais antigo. Os headers GLES3 agora estão acessíveis no Ice Cream Sandwich, embora essa biblioteca não estivesse disponível até KitKat. Você ainda precisará usar todas as chamadas de API via dlopen/dlsym, mas pelo menos terá acesso a todas as constantes e #defines que você precisa para invocar essas funções.

Observe que vamos remover os cabeçalhos antigos do NDK com r16. Portanto, quanto mais cedo você arquivar erros, mais suave será a transição.

Atenção

Os guardas API #ifdef não existem em headers de terceiros, como aqueles encontrados em OpenGL. Nesses casos, você receberá um erro de link time (referência não definida) em vez de um erro de tempo de compilação se você usar uma API que não esteja disponível no seu nível de API específico.

Toolchains independentes usando GCC não são suportadas fora da caixa (nem serão). Para usar GCC, passe -D__ANDROID_API __ = $ API ao compilar.

Ativando Headers Unificados em seu build

Para facilitar a transição dos headers legados para os unificados, não habilitamos os novos headers por padrão, embora o faremos em r15. Como você opta por headers unificados dependerá do seu sistema de compilação.

ndk-build

Em seu Application.mk:

    APP_UNIFIED_HEADERS := true

Você também pode definir esta propriedade a partir da linha de comando como este:

    $ ndk-build APP_UNIFIED_HEADERS=true

Se você estiver usando ndk-build via Gradle com externalNativeBuild, especifique as seguintes configurações em build.gradle:

 

    android {
      ...
      defaultConfig {
        ...
        externalNativeBuild {
          ndkBuild {
            ...
            arguments "APP_UNIFIED_HEADERS=true"
          }
        }
      }
    }

Mcake

Ao configurar sua compilação, defina ANDROID_UNIFIED_HEADERS = ON. Isso geralmente tomará a forma de invocar CMake com cmake -DANDROID_UNIFIED_HEADERS = ON $ OTHER_ARGS.

Se você estiver usando CMake via Gradle com externalNativeBuild, você pode usar:

    android {
      ...
      defaultConfig {
        ...
        externalNativeBuild {
          cmake {
            ...
            arguments "-DANDROID_UNIFIED_HEADERS=ON"
          }
        }
      }
    }

Toolchains Independentes

Ao criar seu toolchain independente, use –unified-headers. Observe que essa opção não está disponível atualmente no script legado, make-standalone-toolchain.sh, mas apenas em make_standalone_toolchain.py.

Plugin Gradle experimental

Em breve! Acompanhe aqui.

Build system personalizado?

Nós mostramos tudo de que você precisa. Instruções sobre como adicionar suporte para headers unificados ao seu build podem ser encontradas aqui.

Para obter informações adicionais sobre headers unificados, consulte nossos documentos e o bug de tracking. Se você está olhando para futuras versões, a versão mais atualizada da documentação está no master branch.

 

***

Este artigo é do Android Security Team. Ele foi escrito por Dan Albert. A tradução foi feita pela Redação iMasters com autorização. Você pode acessar o original em:  https://android-developers.googleblog.com/2017/03/introducing-android-native-development.html