Android changes for NDK developers

Posted by Dmitry Malykhanov, Developer Advocate

Related to other improvements to the Android platform, the dynamic linker in
Android M and N has stricter requirements for writing clean, cross-platform
compatible native code in order to load. It is necessary that an application’s
native code follows the rules and recommendations in order to ensure a smooth
transition to recent Android releases.

Below we outline in detail each individual change related to native code
loading, the consequences and steps you can take to avoid issues.

Required tools: there is an <arch>-linux-android-readelf binary (e.g.
arm-linux-androideabi-readelf or i686-linux-android-readelf) for each
architecture in the NDK (under toolchains/), but you can use readelf for any
architecture, as we will be doing basic inspection only. On Linux you need to
have the “binutils” package installed for readelf, and “pax-utils” for scanelf.

Private API (Enforced since API 24)

Native libraries must use only to ensure they are protected from known vulnerabilities.

Missing Section Headers (Enforced since API 24)

Each ELF file has additional information contained in the section headers. These
headers must be present now, because the dynamic linker uses them for sanity
checking. Some developers try to strip them in an attempt to obfuscate the
binary and prevent reverse engineering. (This doesn’t really help because it is
possible to reconstruct the stripped information using widely-available tools.)

$ readelf --header libBroken.so | grep 'section headers'

  Start of section headers:          0 (bytes into file)

  Size of section headers:           0 (bytes)

  Number of section headers:         0

$

Resolution: remove the extra steps from your build that strip section headers.

Text Relocations (Enforced since API 23)

Starting with API 23, shared objects must not contain text relocations. That is,
the code must be loaded as is and must not be modified. Such an approach reduces
load time and improves security.

The usual reason for text relocations is non-position independent hand-written
assembler. This is not common. Use the for further diagnostics:

$ scanelf -qT libTextRel.so

  libTextRel.so: (memory/data?) [0x15E0E2] in (optimized out: previous simd_broken_op1) [0x15E0E0]

  libTextRel.so: (memory/data?) [0x15E3B2] in (optimized out: previous simd_broken_op2) [0x15E3B0]

[skipped the rest]

If you have no scanelf tool available, it is possible to do a basic check with
readelf instead, look for either a TEXTREL entry or the TEXTREL flag. Either
alone is sufficient. (The value corresponding to the TEXTREL entry is irrelevant
and typically 0 --- simply the presence of the TEXTREL entry declares that the
.so contains text relocations). This example has both indicators present:

$ readelf --dynamic libTextRel.so | grep TEXTREL

 0x00000016 (TEXTREL)                    0x0

 0x0000001e (FLAGS)                      SYMBOLIC TEXTREL BIND_NOW

$

Note: it is technically possible to have a shared object with the TEXTREL
entry/flag but without any actual text relocations. This doesn’t happen with the
NDK, but if you’re generating ELF files yourself make sure you’re not generating
ELF files that claim to have text relocations, because the Android dynamic
linker trusts the entry/flag.

Potential problems: Relocations enforce code pages being writable, and
wastefully increase the number of dirty pages in memory. The dynamic linker has
issued warnings about text relocations since Android K (API 19), but on API 23
and above it refuses to load code with text relocations.

Resolution: rewrite assembler to be position independent to ensure no text
relocations are necessary. Check the