Android security: Everything you need to know

Although mobile users are slowly seeing their choice of operating systems expand, Android and iOS still hold the lion's share of the market and are present on the devices of users who want access to the majority of applications being developed.

According to data published in February 2021 by research department Statista, as of the second quarter of 2020, Google Play gave Android users access to 2,7 million apps, while Apple's App Store had nearly 1,82 million apps .

Android, Google's open platform, is loved for its flexibility and customizability. With great potential, however, comes great headaches, as the same flexibility and access afforded to both developers and users provides opportunities for malicious hackers to exploit vulnerabilities and undermine the security of more than 2,5 billion active devices (as of May 2019).



Why think about Android security?

Smartphones and tablets are now an integral part of people's lives, providing a means of accessing and using sensitive information (banking and other financial data, personal documents, videos, photos, contacts, PINS and passwords). Although Google's Android operating system is based on the Linux kernel, users often worry about whether the platform is truly secure.

Recently, for example, Checkpoint researchers found that one billion smartphones were affected by a set of 400 security flaws in tested DSP chips, the digital signal processor units made by Qualcomm Technologies and used in phones sold by companies such as Google, Samsung , LG and Xiaomi, affecting 40% of Android phones and 90% of the US market. Because of this problem, malicious hackers could access photos, location data, calls, videos and also make the phone unresponsive and essentially useless.

It's no surprise, then, that Google makes it a priority to integrate more and more security into its operating system, as well as timely release of security fixes in the latest version of Android to ensure customer loyalty and trust.

Android problems

Exiting an application's sandbox

This is only possible if the security of the Linux kernel is compromised. Android relies on protections to enforce application sandboxing and makes efforts to prevent individual vulnerabilities from compromising the operating system and other applications.

Security features have been added to every version of Android. Android 5.0 introduced mandatory SELinux access control (MAC) separation between system and applications. Restrictions were introduced in Android 10, where apps had a limited raw view of the file system and no direct access to paths like /sdcard/DCIM.

Memory security issues

This problem represents 59% of all critical and high-severity Android security vulnerabilities and includes memory corruption and overflows. A quick look at the CVE list shows that of the 414 Android vulnerabilities found in 2019, 150 are related to memory corruption and the ability for a hacker to be able to execute code remotely and gain access to files and data without privileges.

Android provides Address Space Layout Randomization (ASLR), a memory protection process to minimize problems, and also uses “NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc, and Linux mmap_min_addr to mitigate the risks associated with common errors memory management".

One of the efforts Google is focusing on is the progressive transition to memory-safe languages, namely Java, the JVM-compatible Kotlin, and Rust. C and C++ languages ​​are often used for their flexibility, especially when writing kernels and drivers - unfortunately, they don't offer reliable garbage collection, and manual memory management can lead to problems such as buffer overflows and overreads. Mozilla Rust proves to be "the golden intersection between the low-level power of C and the memory safety found in higher-level languages ​​like Java."

Rights issues

These issues accounted for 21% of the issues Google security engineers encountered in 2019. The Android permissions system is a key element that protects data and users through access control mechanisms. This important part of the security measures that Google has devised is often the target of changes and improvements in each new version of Android.

Every application running on the Android platform must be signed by the developer. By default, no application is allowed to perform operations that could adversely affect other applications, the operating system, or the user. This includes reading or writing the user's personal data (such as contacts or emails), reading or writing another application's files, performing network access, and more.

Because the kernel protects applications from each other, applications must explicitly share resources and data. They do this by declaring the permissions they need and asking users for consent when installing the app. Some apps ask for more permissions than are necessary to function properly - some are just data collection functions. Unfortunately, users often grant permissions without really understanding the consequences of their choices.

Google is constantly dealing with permission issues. For example, while with Android 10 users could restrict access to location information and had the option to “only allow while using the app”, Android 11 went further by allowing users to restrict access to location, microphones and cameras also on a temporary basis, for single use only. Additionally, apps that haven't been used for long periods of time will see their rights revoked. In Android 11, an app will only be able to ask a user for permissions twice and be denied—after that, the operating system automatically denies further requests.

Developers can do a lot to ensure that applications have secure access to system resources, as well as to ensure that third-party applications are granted the appropriate permissions. They can limit data storage to internal apps only or, if sharing data between two apps owned by the same developer, they can use a signing key. This ensures that applications can automatically check for legitimate access without user interaction and without the possibility of errors.

Overlay attack

This has always been a serious issue and has allowed credentials to be leaked by tricking users into typing them into fake online services. In Android 11, the overlay must be allowed by the user, who is not taken directly to the authentication screen but to a step before, where they can choose to proceed.

Data storage problems

Data storage is always a concern. Android users see their data placed on internal and external storage as well as content providers.

External storage is useful for large, non-sensitive files as well as data intended to be shared with other applications. Data on external storage such as SD cards, however, is removable and can be accessed in other contexts. Sensitive information should instead be encrypted on internal storage so that it can only be accessed by the application that created that data.

For sharing with other applications, rather than using functions such as MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE, which provide no control over data access, it is better to use content providers where access can be granted on an as-needed basis and permissions can be to change based on the actual need of the applications. Access to content provider objects should be disallowed if a developer does not intend to share data with other third-party applications.

Of course, it is also important to ensure that the storage and transmission of sensitive data is kept to a minimum for security and compliance reasons. To prevent data exposure, developers can first consider alternatives (transmitting the hash of an email instead of the actual address). The developer can also ensure that privacy-sensitive data is not unnecessarily transmitted to a server if it could be processed on the client. Log files are also a potential source of leaks with data that could be inadvertently stored there and then made available to any application with READ_LOGS permission.

Issues related to dynamically loading code

One of the frequently cited issues concerns the ability of applications to load code dynamically. This is a process that is often used for legitimate purposes, but can also be exploited by malicious hackers. The advantage is the ability to not have to load all the libraries at once but only when needed during the use of the application. The downside is that a remote code can easily avoid being caught by static analysis tools and may not be detected through the verification process, since it doesn't actually exist in the app's published APK package but in the DEX.


This is a process that users often use to gain more control over their devices and get rid of operating system limitations. Unfortunately, it's also a way to render some of Android's built-in security features ineffective at the risk of exposing data that was previously stored safely behind layers of protective restrictions. Rooting can lead not only to security issues but also to other problems, such as the incompatibility of some legitimate apps and the inability to upgrade or update Android.

Maintaining the security of the Android platform and ecosystem

Android takes advantage of Linux kernel security and security features, including a user-based permission model, application signing, and process isolation. What else has been introduced to keep this ecosystem safe?


An important feature in Android 11 is the ability to choose the category of biometrics that developers can request to use their app. Accessing highly sensitive medical or financial data, for example, may require “strong” level biometrics, which would include iris or fingerprint scanning as well as 3D secure face unlock. Other options would be weaker biometrics (like regular facial recognition) or device credentials (like PINs and passwords). Developers can use the BiometricPrompt API to select the type of biometrics necessary to guarantee maximum protection of user data.

Limited scale storage

When limited storage was introduced with Android 10 to limit access to files and folders as needed, it created problems for many apps. Android 11 refined the feature and apps with storage access will have a read-only option set until the user manually changes it to “access all files”. Scoped access further separates the files owned by each application, and while it makes it more difficult for developers to regulate legitimate data access between applications, it gives users more security and control over what is accessed and shared.

Collection of background information

With Android 11, apps are no longer allowed to collect information in the background. The only time an app will be allowed to collect information is when it is running. This puts users in control of when an app can collect data and information.

The flaws of Android devices

Many operating system flaws still pose a risk to potentially millions of Android devices. However, new developments of Android have added important features for the security of users' data and devices.

Fixes for publicly known bugs are released directly by Google's security team, which has applicable fixes available continuously in the monthly Android security bulletins as well. It is important for users and developers alike to take advantage of the latest security updates to minimize issues and contribute to safer Android environments. The Best Technology Site in Greecefgns

Android, security

Written by Anastasis Vasileiadis

Translations are like women. When they are beautiful they are not faithful and when they are faithful they are not beautiful.

Leave a reply

Your email address is not published. Required fields are mentioned with *

Your message will not be published if:
1. Contains insulting, defamatory, racist, offensive or inappropriate comments.
2. Causes harm to minors.
3. It interferes with the privacy and individual and social rights of other users.
4. Advertises products or services or websites.
5. Contains personal information (address, phone, etc.).