Android sdk armeabi v7a

Android ABIs

Different Android devices use different CPUs, which in turn support different instruction sets. Each combination of CPU and instruction set has its own Application Binary Interface (ABI). An ABI includes the following information:

• The CPU instruction set (and extensions) that can be used.
• The endianness of memory stores and loads at runtime. Android is always little-endian.
• Conventions for passing data between applications and the system, including alignment constraints, and how the system uses the stack and registers when it calls functions.
• The format of executable binaries, such as programs and shared libraries, and the types of content they support. Android always uses ELF. For more information, see ELF System V Application Binary Interface.
• How C++ names are mangled. For more information, see Generic/Itanium C++ ABI.

This page enumerates the ABIs that the NDK supports, and provides information about how each ABI works.

ABI can also refer to the native API supported by the platform. For a list of those kinds of ABI issues affecting 32-bit systems, see 32-bit ABI bugs.

Supported ABIs

Table 1. ABIs and supported instruction sets.

ABI	Supported Instruction Sets	Notes
armeabi-v7a	armeabi Thumb-2 VFPv3-D16	Incompatible with ARMv5/v6 devices.
arm64-v8a	AArch64
x86	x86 (IA-32) MMX SSE/2/3 SSSE3	No support for MOVBE or SSE4.
x86_64	x86-64 MMX SSE/2/3 SSSE3 SSE4.1, 4.2 POPCNT

Note: Historically the NDK supported ARMv5 (armeabi), and 32-bit and 64-bit MIPS, but support for these ABIs was removed in NDK r17.

armeabi-v7a

This ABI is for 32-bit ARM-based CPUs. The Android variant includes Thumb-2 and the VFP hardware floating point instructions, specifically VFPv3-D16, which includes 16 dedicated 64-bit floating point registers.

For information about the parts of the ABI that aren’t Android-specific, see Application Binary Interface (ABI) for the ARM Architecture

The NDK’s build systems generate Thumb-2 code by default unless you use LOCAL_ARM_MODE in your Android.mk for ndk-build or ANDROID_ARM_MODE when configuring CMake.

Other extensions including Advanced SIMD (Neon) and VFPv3-D32 are optional. For more information, see Neon Support.

The armeabi-v7a ABI uses -mfloat-abi=softfp to enforce the rule that, although system can execute floating-point code, the compiler must pass all float values in integer registers and all double values in integer register pairs when making function calls.

arm64-v8a

This ABI is for ARMv8-A based CPUs, which support the 64-bit AArch64 architecture. It includes the Advanced SIMD (Neon) architecture extensions.

You can use Neon intrinsics in C and C++ code to take advantage of the Advanced SIMD extension. The Neon Programmer’s Guide for Armv8-A provides more information about Neon intrinsics and Neon programming in general.

See Arm’s Learn the Architecture for complete details of the parts of the ABI that aren’t Android-specific. Arm also offers some porting advice in 64-bit Android Development.

On Android, the platform-specific x18 register is reserved for ShadowCallStack and should not be touched by your code. Current versions of Clang default to using the -ffixed-x18 option on Android, so unless you have hand-written assembler (or a very old compiler) you shouldn’t need to worry about this.

This ABI is for CPUs supporting the instruction set commonly known as «x86», «i386», or «IA-32». Characteristics of this ABI include:

Instructions normally generated by GCC with compiler flags such as the following:

These flags target the Pentium Pro instruction set, along with the the MMX, SSE, SSE2, SSE3, and SSSE3 instruction set extensions. The generated code is an optimization balanced across the top Intel 32-bit CPUs.

For more information on compiler flags, particularly related to performance optimization, refer to GCC x86 Performance Hints.

Use of the standard Linux x86 32-bit calling convention, as opposed to the one for SVR. For more information, see section 6, «Register Usage», of Calling conventions for different C++ compilers and operating systems.

The ABI does not include any other optional IA-32 instruction set extensions, such as:

You can still use these extensions, as long as you use runtime feature-probing to enable them, and provide fallbacks for devices that do not support them.

The NDK toolchain assumes 16-byte stack alignment before a function call. The default tools and options enforce this rule. If you are writing assembly code, you must make sure to maintain stack alignment, and ensure that other compilers also obey this rule.

Refer to the following documents for more details:

x86_64

This ABI is for CPUs supporting the instruction set commonly referred to as «x86-64.» It supports instructions that GCC typically generates with the following compiler flags:

These flags target the x86-64 instruction set, according to the GCC documentation. along with the MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, and POPCNT instruction-set extensions. The generated code is an optimization balanced across the top Intel 64-bit CPUs.

For more information on compiler flags, particularly related to performance optimization, refer to GCC x86 Performance Hints.

This ABI does not include any other optional x86-64 instruction set extensions, such as:

You can still use these extensions, as long as you use runtime feature probing to enable them, and provide fallbacks for devices that do not support them.

Refer to the following documents for more details:

Generate code for a specific ABI

Gradle

Gradle (whether used via Android Studio or from the command line) builds for all non-deprecated ABIs by default. To restrict the set of ABIs that your application supports, use abiFilters . For example, to build for only 64-bit ABIs, set the following configuration in your build.gradle :

ndk-build

ndk-build builds for all non-deprecated ABIs by default. You can target a specific ABIs by setting APP_ABI in your Application.mk file. The following snippet shows a few examples of using APP_ABI :

For more information on the values you can specify for APP_ABI , see Application.mk.

CMake

With CMake, you build for a single ABI at a time and must specify your ABI explicitly. You do this with the ANDROID_ABI variable, which must be specified on the command line (cannot be set in your CMakeLists.txt). For example:

For the other flags that must be passed to CMake to build with the NDK, see the CMake guide.

The default behavior of the build system is to include the binaries for each ABI in a single APK, also known as a fat APK. A fat APK is significantly larger than one containing only the binaries for a single ABI; the tradeoff is gaining wider compatibility, but at the expense of a larger APK. It is strongly recommended that you take advantage of either App Bundles or APK Splits to reduce the size of your APKs while still maintaining maximum device compatibility.

At installation time, the package manager unpacks only the most appropriate machine code for the target device. For details, see Automatic extraction of native code at install time.

ABI management on the Android platform

This section provides details about how the Android platform manages native code in APKs.

Native code in app packages

Both the Play Store and Package Manager expect to find NDK-generated libraries on filepaths inside the APK matching the following pattern:

Here, is one of the ABI names listed under Supported ABIs, and is the name of the library as you defined it for the LOCAL_MODULE variable in the Android.mk file. Since APK files are just zip files, it is trivial to open them and confirm that the shared native libraries are where they belong.

If the system does not find the native shared libraries where it expects them, it cannot use them. In such a case, the app itself has to copy the libraries over, and then perform dlopen() .

In a fat APK, each library resides under a directory whose name matches a corresponding ABI. For example, a fat APK may contain:

Note: ARMv7-based Android devices running 4.0.3 or earlier install native libraries from the armeabi directory instead of the armeabi-v7a directory if both directories exist. This is because /lib/armeabi/ comes after /lib/armeabi-v7a/ in the APK. This issue is fixed from 4.0.4.

Android platform ABI support

The Android system knows at runtime which ABI(s) it supports, because build-specific system properties indicate:

• The primary ABI for the device, corresponding to the machine code used in the system image itself.
• Optionally, secondary ABIs, corresponding to other ABI that the system image also supports.

This mechanism ensures that the system extracts the best machine code from the package at installation time.

For best performance, you should compile directly for the primary ABI. For example, a typical ARMv5TE-based device would only define the primary ABI: armeabi . By contrast, a typical, ARMv7-based device would define the primary ABI as armeabi-v7a and the secondary one as armeabi , since it can run application native binaries generated for each of them.

64-bit devices also support their 32-bit variants. Using arm64-v8a devices as an example, the device can also run armeabi and armeabi-v7a code. Note, however, that your application will perform much better on 64-bit devices if it targets arm64-v8a rather than relying on the device running the armeabi-v7a version of your application.

Many x86-based devices can also run armeabi-v7a and armeabi NDK binaries. For such devices, the primary ABI would be x86 , and the second one, armeabi-v7a .

You can force install an apk for a specific ABI. This is useful for testing. Use the following command:

Automatic extraction of native code at install time

When installing an application, the package manager service scans the APK, and looks for any shared libraries of the form:

If none is found, and you have defined a secondary ABI, the service scans for shared libraries of the form:

When it finds the libraries that it’s looking for, the package manager copies them to /lib/lib .so , under the application’s native library directory ( / ). The following snippets retrieve the nativeLibraryDir :

Kotlin

If there is no shared-object file at all, the application builds and installs, but crashes at runtime.

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник

SDK Platform Tools release notes

Android SDK Platform-Tools is a component for the Android SDK. It includes tools that interface with the Android platform, such as adb , fastboot , and systrace . These tools are required for Android app development. They’re also needed if you want to unlock your device bootloader and flash it with a new system image.

Although some new features in these tools are available only for recent versions of Android, the tools are backward compatible, so you need only one version of the SDK Platform-Tools.

Downloads

If you’re an Android developer, you should get the latest SDK Platform-Tools from Android Studio’s SDK Manager or from the sdkmanager command-line tool. This ensures the tools are saved to the right place with the rest of your Android SDK tools and easily updated.

But if you want just these command-line tools, use the following links:

• Download SDK Platform-Tools for Windows
• Download SDK Platform-Tools for Mac
• Download SDK Platform-Tools for Linux

Although these links do not change, they always point to the most recent version of the tools.

Revisions

31.0.3 (August 2021)

• fastboot
  • Support flashing vbmeta_vendor.img for fastboot flashall / update.

31.0.2 (April 2021)

• adb
  • Support forwarding to vsock on linux.
  • Fix bug in adb track-devices where devices over wireless debugging wouldn’t immediately receive updates.
  • Implement preliminary support for mDNS device discovery without a separately installed mDNS service. This is currently disabled by default, and can be enabled by setting the environment variable ADB_MDNS_OPENSCREEN to 1 when starting the adb server.
• fastboot
  • Don’t fail when unable to get boot partition size.
  • Derive device locked state from property instead of parsing the kernel command line.

31.0.1 (March 2021)

• adb
  • Reduce TCP keepalive interval.
  • Improve incremental installation performance.
• fastboot
  • Add support for compressed snapshot merges.
  • Restore legacy A/B support.

31.0.0 (February 2021)

• adb
  • Disable compression on pull by default.

30.0.5 (November 2020)

• adb
  • Improve performance of adb push when pushing many files over a high-latency connection.
  • Improve adb push/pull performance on Windows.
  • Fix adb push —sync with multiple inputs.
  • Improve performance of incremental apk installation.
  • Improve error handling for incremental apk installation.

30.0.4 (July 2020)

• adb
  • Fix fallback to non-incremental apk installation on pre-Android 11 devices.
  • Fix adb install-multi-package .
  • Fix some more crashes related to adb wireless pairing.
  • Improve some error messages.
• fastboot
  • Improve console output on fastboot oem commands.
  • Fix fastboot flashall on older devices such as Nexus 7.

30.0.3 (June 2020)

• adb
  • Fix installation of APKs signed with v4 signature scheme on pre-Android 11 devices.
  • Fix crash when authenticating without ADB_VENDOR_KEYS .
  • Fix crash when using adb -H .

30.0.2 (June 2020)

• adb
  • Improve adb wireless pairing.
  • Fix hang in adb logcat when run before a device is connected.
  • Add adb transport-id to allow scripts to safely wait for a device to go away after root/unroot/reboot.

30.0.1 (May 2020)

• adb
  • Disable adb mdns auto-connection by default. This can be reenabled with the ADB_MDNS_AUTO_CONNECT environment variable.
  • Improve performance of adb install-multi on Android 10 or newer devices.
  • Fix timeout when using adb root/unroot on a device connected over TCP.
  • Update support for wireless pairing.

30.0.0 (April 2020)

• adb
  • Add initial support for wireless pairing.
  • Add support for incremental APK installation.
  • Implement client-side support for compression of adb when used with an Android 11 device.
  • Improve performance of adb push on high-latency connections.
  • Improve push/pull performance on Windows.

29.0.6 (February 2020)

• adb
  • 64-bit size/time support for adb ls when used with an Android 11 device.
  • Support listening on ::1 on POSIX.
  • Client support for WinUSB devices that publish a WinUSB descriptor (required for Android 11) should no longer require a USB driver to be installed.
  • Fix hang when using adb install on something that isn’t actually a file.

29.0.5 (October 2019)

• adb
  • Slight performance improvement on Linux when using many simultaneous connections.
  • Add —fastdeploy option to adb install , for incremental updates to APKs while developing.

29.0.4 (September 2019)

• adb
  • Hotfix for native debugging timeout with LLDB (see issue #134613180). This also fixes a related bug in the Android Studio Profilers that causes an AdbCommandRejectedException , which you can see in the idea.log file.

29.0.3 (September 2019)

• adb
  • adb forward —list works with multiple devices connected.
  • Fix devices going offline on Windows.
  • Improve adb install output and help text.
  • Restore previous behavior of adb connect without specifying port.

29.0.2 (July 2019)

• adb
  • Fixes a Windows heap integrity crash.
• fastboot
  • Adds support for partition layout of upcoming devices.

29.0.1 (June 2019)

• adb
  • Hotfix for Windows crashes (https://issuetracker.google.com/134613180)

29.0.0 (June 2019)

• adb
  • adb reconnect performs a USB reset on Linux.
  • On Linux, when connecting to a newer adb server, instead of killing the server and starting an older one, adb attempts to launch the newer version transparently.
  • adb root waits for the device to reconnect after disconnecting. Previously, adb root; adb wait-for-device could mistakenly return immediately if adb wait-for-device started before adb noticed that the device had disconnected.
• fastboot
  • Disables an error message that occurred when fastboot attempted to open the touch bar or keyboard on macOS.

28.0.2 (March 2019)

• adb
  • Fixes flakiness of adb shell port forwarding that leads to «Connection reset by peer» error message.
  • Fixes authentication via ADB_VENDOR_KEYS when reconnecting devices.
  • Fixes authentication—when the private key used for authentication does not match the public key—by calculating the public key from the private key, instead of assuming that they match.
• fastboot
  • Adds support for dynamic partitions.
• Updated Windows requirements
  • The platform tools now depend on the Windows Universal C Runtime, which is usually installed by default via Windows Update. If you see errors mentioning missing DLLs, you may need to manually fetch and install the runtime package.

28.0.1 (September 2018)

• adb
  • Add support for reconnection of TCP connections. Upon disconnection, adb will attempt to reconnect for up to 60 seconds before abandoning a connection.
  • Fix Unicode console output on Windows. (Thanks to external contributor Spencer Low!)
  • Fix a file descriptor double-close that can occur, resulting in connections being closed when an adb connect happens simultaneously.
  • Fix adb forward —list when used with more than one device connected.
• fastboot
  • Increase command timeout to 30 seconds, to better support some slow bootloader commands.

28.0.0 (June 2018)

• adb:
  • Add support for checksum-less operation with devices running Android P, which improves throughput by up to 40%.
  • Sort output of adb devices by connection type and device serial.
  • Increase the socket listen backlog to allow for more simulataneous adb commands.
  • Improve error output for adb connect .
• fastboot:
  • Improve output format, add a verbose output mode ( -v ).
  • Clean up help output.
  • Add product.img and odm.img to the list of partitions flashed by fastboot flashall .
  • Avoid bricking new devices when using a too-old version of fastboot by allowing factory image packages to require support for specific partitions.

27.0.1 (December 2017)

• adb: fixes an assertion failure on MacOS that occurred when connecting devices using USB 3.0.
• Fastboot: On Windows, adds support for wiping devices that use F2FS (Flash-Friendly File System).

27.0.0 (December 2017)

• Re-fixes the macOS 10.13 fastboot bug first fixed in 26.0.1, but re-introduced in 26.0.2.

26.0.2 (October 2017)

• Add fastboot support for Pixel 2 devices.

26.0.1 (September 2017)

• Fixed fastboot problems on macOS 10.13 High Sierra (bug 64292422).

26.0.0 (June 2017)

• Updated with the release of Android O final SDK (API level 26).

25.0.5 (April 24, 2017)

Fixed adb sideload of large updates on Windows, manifesting as «std::bad_alloc» (bug 37139736).

Fixed adb problems with some Windows firewalls, manifesting as «cannot open transport registration socketpair» (bug 37139725).

Both adb —version and fastboot —version now include the install path.

Changed adb to not resolve localhost to work around misconfigured VPN.

Changed adb to no longer reset USB devices on Linux, which could affect other attached USB devices.

25.0.4 (March 16, 2017)

• Added experimental libusb support to Linux and Mac adb

To use the libusb backend, set the environment variable ADB_LIBUSB=true before launching a new adb server. The new adb host-features command will tell you whether or not you’re using libusb.

To restart adb with libusb and check that it worked, use adb kill-server; ADB_LIBUSB=1 adb start-server; adb host-features . The output should include «libusb».

In this release, the old non-libusb implementation remains the default.

fastboot doesn’t hang 2016 MacBook Pros anymore (bug 231129)

Fixed Systrace command line capture on Mac

25.0.3 (December 16, 2016)

• Fixed fastboot bug causing Android Things devices to fail to flash

25.0.2 (December 12, 2016)

• Updated with the Android N MR1 Stable release (API 25)

25.0.1 (November 22, 2016)

• Updated with the release of Android N MR1 Developer Preview 2 release (API 25)

25.0.0 (October 19, 2016)

• Updated with the release of Android N MR1 Developer Preview 1 release (API 25)

24.0.4 (October 14, 2016)

• Updated to address issues in ADB and Mac OS Sierra

Download Android SDK Platform-Tools

Before downloading, you must agree to the following terms and conditions.

Terms and Conditions

1. Introduction

2. Accepting this License Agreement

3. SDK License from Google

4. Use of the SDK by You

5. Your Developer Credentials

6. Privacy and Information

7. Third Party Applications

8. Using Android APIs

9. Terminating this License Agreement

10. DISCLAIMER OF WARRANTIES

11. LIMITATION OF LIABILITY

12. Indemnification

13. Changes to the License Agreement

14. General Legal Terms

Download Android SDK Platform-Tools

Before downloading, you must agree to the following terms and conditions.

Terms and Conditions

1. Introduction

2. Accepting this License Agreement

3. SDK License from Google

4. Use of the SDK by You

5. Your Developer Credentials

6. Privacy and Information

7. Third Party Applications

8. Using Android APIs

9. Terminating this License Agreement

10. DISCLAIMER OF WARRANTIES

11. LIMITATION OF LIABILITY

12. Indemnification

13. Changes to the License Agreement

14. General Legal Terms

Download Android SDK Platform-Tools

Before downloading, you must agree to the following terms and conditions.

Источник