devxlogo

Android Development Security Best Practices

Android Development Security Best Practices

Android is ubiquitous and runs on a huge variety of devices for a vast number of different applications. It is typically found on mobile phones and tablets. This means that it is often used in public areas where the device itself can be lost or stolen, as well as attacked over public networks. Many people trust their digital identity to their Android device and store extremely sensitive information and/or use it for critical purposes. The Android designers are well aware of this reality and Android is chock-full of security features that allow you, the developer, to build safe and robust applications that protect your users’ data, and your own data as well, to interact and safely share the information you or your users choose to share in a controlled manner. In this article, I’ll review many of the security features built into Android.

Android Architecture

The Android architecture consists of four layers. At the very bottom is the Linux Kernel (yes, Android is built on top of Linux). That, in itself, has deep security implications, since all the security features of Linux are present (more on that later). The next layer is the Android runtime that runs your applications. The runtime is based on the Dalvik Virtual Machine, which is a Java VM. The runtime also contains core libraries and additional libraries such as libc, SSL, SQLite, FreeType and WebKit. Sitting on top of the Android runtime is the application framework. The application implements and exposes the Android application model based on activities, intents and all the other familiar elements. It provides various services and components to application developers such as the notification manager, the package manager, activity manager and content providers. Finally, the top layer is the application layer. Android provides its own applications such as phone, contacts, browser, etc. Your applications live in this layer side-by-side with the built-in applications. The cool thing about Android applications is that you can use features from other applications if the developer exposed them as activities with the right permissions.

Dalvik VM

The Dalvik VM is an implementation of the Java virtual machine. From a security point of view, it is different from most other implementations. The Dalvik VM doesn’t represent a security boundary. The Android security model is at the OS level. That means that Dalvik can easily interact with native code libraries. This has various advantages as far as performance goes. It also simplifies many things because Dalvik doesn’t have to deal with security at all, knowing it runs itself in a managed environment.

Application Sandbox

Applications are isolated from each other by default. Each application gets its own Linux user id and Linux group id and runs inside the Linux process sandbox. Applications are made of separate components that each have their own permissions assigned at installation time. The permissions are specified in the AndroidManifest.xml file

Permission Model

The permissions of an application control how other applications can interact with its activities. There are system-level permissions and you can define your own permissions for your application. The PackageManager and the ActivityManager enforce the permissions, so you can be sure no one can work around them. Note, that there are other types of components beyond applications such as services that run in the background and content providers that store data in a local database (SQLite).

Storage

Data storage is another key element to consider with your security hat on. Often the most important thing to protect is not access to your application, but rather, the data it creates and stores. You can have perfectly finely-tuned permissions, but if after the fact a random application can access your data then your application as a whole is not secure. External storage, can be detached and read both by other applications and detached and read elsewhere. In general, sensitive data on external storage should be encrypted. Internal storage provides a private area for each application for storing files. These file are protected by Unix-like permissions and can be shared by using world permissions. Content providers are local relational databases that are protected by the permission model and their content can be shared selectively (or not at all).

Other Security Features

There are many other security features available if you want to go beyond the defaults. You can use various secure networking facilities, utilize mature cryptography libraries and write secure native code. But, you should be aware that the level of security is determined by the weakest link.

Conclusion

It is extremely important to develop secure applications. Android gives you a secure design, lots of security features and good defaults out of the box. It is your responsibility to be aware and utilize these capabilities wisely. Familiarize yourself with the various elements of Android security, consider carefully the implications of your actions and employ security in depth.

devxblackblue

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist