Android SDK

As of March 2015, the SDK is not available on Android itself, but software development is possible by using specialized Android applications.

Until around the end of 2014, the officially-supported integrated development environment (IDE) was Eclipse using the Android Development Tools (ADT) Plugin. As of 2015, Android Studio is the official IDE; however, developers are free to use others, but Google made it clear that ADT was officially deprecated since the end of 2015 to focus on Android Studio as the official Android IDE. Additionally, developers may use any text editor to edit Java and XML files, then use command line tools (Java Development Kit and Apache Ant are required) to create, build and debug Android applications as well as control attached Android devices (e.g., triggering a reboot, installing software package(s) remotely).

Enhancements to Android's SDK go hand-in-hand with the overall Android platform development. The SDK also supports older versions of the Android platform in case developers wish to target their applications at older devices. Development tools are downloadable components, so after one has downloaded the latest version and platform, older platforms and tools can also be downloaded for compatibility testing.

Android applications are packaged in .apk format and stored under /data/app folder on the Android OS (the folder is accessible only to the root user for security reasons). APK package contains .dex files (compiled byte code files called Dalvik executables), resource files, etc.

The Android SDK Platform Tools are a separately downloadable subset of the full SDK, consisting of command-line tools such as Android Debug Bridge and fastboot.

In 2011, a vulnerability was found in the dexdump utility as it did not validate structures, leading to crashes or possible exploitation. The vulnerability was registered as CVE-2011-1001.

Another vulnerability was found in the host client implementation of ADB in 2014. A malicious user could gain access to the account of another user on the same system when that user executed an ADB command that connected to the malicious user's ADB server. The client had a buffer overflow vulnerability and wasn't compiled with any hardening options like a non-executable stack or ASLR.