Android Security Evolution over the years
Authors: @Sweta Kumari and @PRATYUL KAPOOR
Android has evolved a lot over the years. With every major android release, there have been significant enhancements related to security for end users. This blog primarily focuses on how permissions have been made more transparent to end users and better controls have been added.
We will also touch upon how MaaS360 has evolved with these changes and made the devices more secure and transparent to the end users.
Android 6
Runtime Permissions
Android 6 introduced Runtime Permissions for the first time. This was pretty good for end users, though not so good for developers. Prior to Android 6, permissions were asked at install time and once granted, these permissions were never revoked. Android 6 moved to a model where permissions are asked only when they are required and can be revoked by end users later on.
MaaS360 also adopted these changes where appropriate permission checks were added before every API call. Further via Android Enterprise, it provided appropriated policies for admins to grant these permissions automatically via MDM APIs.
Programmatic Access to Device Hardware Identifier removed
Prior to Android 6 – any app installed on the device was able to access device identifiers like Wi-Fi MAC Address and Bluetooth MAC Address. These APIs were restricted in Android 6. MaaS360 as an MDM still had access to these APIs in Fully Managed (Device-Owner) mode. MaaS360 worked with customers to evolve their use cases based on new operating system requirements.
Android 7
Access to Private Files Restricted
In order to improve the security of private files, the private directory of apps from Android 7 has restricted access (0700). To share files between applications, applications were allowed to grant a temporary permission via Content URI.
Android 8
Control Installation from Unknown Sources
Prior to Android 8 there was no control about the source of app installation. This was a major security risk which allowed installation of malware apps. With Android 8, there were controls introduced for end users. These controls were also introduced for the IT Administrators (via MaaS360) to control whether installation from Unknown sources was allowed.
Removal of incorrect grant of other permissions in the same permission group
Android 8 introduced a pivotal change in permissions, requiring explicit user approval for each requested permission. Prior to Android 8, when an app obtained a permission at runtime, the system erroneously granted all permissions within the same permissions group listed in the manifest. This vulnerability jeopardized user data and privacy. For instance, if an app declared both read and write permissions for external storage in the manifest, and the app only requested read permission at runtime, the incorrect behaviour granted write permission as well. This allowed the app to manipulate data without user awareness or consent, posing a significant privacy risk.
Android 9
No More World Readable Files
Android 9 enhanced the data privacy by improving the integrity of the Android Application Sandbox ensuring an app's private data is inaccessible to others using world-accessible Unix permissions. MaaS360 core app use file sharing with its other first party apps through the use of content providers.
Android 10
Background Location Permission
Device location is considered a very important privacy factor. Many malicious apps used to show that they are requesting location permission for a genuine use case and then continued to use that permission in background to track end user’s movement. Android 10 tried to address this problem by introducing a new permission: ACCESS-BACKGROUND- LOCATION for apps which just want to access location for that point in time with request the original permission.
For MaaS360 use case, several IT Administrators wanted to use Geo-Fencing capabilities where they can change the policy based on device location. Further IT Administrators wanted to detect device location to track a lost device. For such use cases, MaaS360 adopted background location. This permission was also allowed to be granted via MaaS360 Policy directly.
Other Location Permission enhancement included the fact that location permission was essential for Wi-Fi, Bluetooth and telephony scanning APIs as well.
Scoped External Storage Permissions.
With Android 10, external storage access was scoped to the app specific directory and the data which app itself has created.
Android 11
One Time Permissions & Auto-Reset of Permissions
Though Runtime Permissions have been around for a while. There were few limitations with the same. First one was permissions once granted remained active unless end user explicitly revoked them. Second was that end users faced continual permission prompts, persisting even after multiple denials. Android 11 solved this in the following ways:
- One-Time Permissions: Users can now grant temporary access to vital permissions (e.g., location, camera) for a single use.
- Permissions Auto-Reset: Sensitive app permissions reset automatically if the user hasn't engaged with the app for several months.
- "Don't Ask Again" Mechanism: Multiple denials trigger this response, preventing further permission prompts.
Package Visibility Filtering
Android 11 also focussed on privacy improvement in the area of package visibility also i.e. better scoped access to the list of apps installed on a given device. Up to Android 10, any app could query a full list of installed packages on the system where as in most cases the app doesn’t need this broader access for its functionality. Starting Android 11, app developers were asked to add the package names of app they need to query in their application’s manifest file. If an application’s use case needed them to access all packages, they needed to fill a special form on google play store which clearly documents on play store as to why access to all packages is needed.
Android 12
Microphone and Camera Indicators/Toggles
Access to Camera and Microphone is one of the main factors for end user's privacy. Many malicious apps used to take pictures or record voices without proper communication to end users. This was probably because they would have been granted these permissions sometime back. Android 12 did two major changes related to this. First one was a clear indicator in status bar when camera/microphone is accessed. Second one was an easy way for end user to toggle these in settings. 
Approximate Location Permissions
Android 12 allows users to grant location permission without sharing the exact location. This allows users to choose between sharing approximate or precise location. MaaS360 adopted these features and the permission dialog prompt appears as follows:
Safer Component Exporting
This change was not impactful to end users but it was extremely important for security of applications. Every application has components which are added in application manifest file. Many of these components are added for communication within the application but were sometimes exported accidentally. Android 12 enforced clearly declaring exported components. Unless they were declared exported, they were assumed to be within the application.
Android 13
Runtime Permissions for Notifications
Android 13 focussed on specific permission requirement for the specific functionality and not giving broader permission access enhancing the user privacy at next level. The introduction of runtime notification permission allows users to focus solely on essential notifications, streamlining their attention. MaaS360 utilises this permission to bring user attention towards highly critical notifications to end users. IT administrators can control these permissions like any other permission via MaaS360 policies.
Granular Media Permissions
Android 13 introduced Granular media permissions. This allowed users to specify access based on media type rather than requiring full external storage permission. MaaS360 adopted these changes and stopped all READ_EXTERNAL_STORAGE access. MaaS360 required only Read Media Images.
Android 12 Android 13
What Google can bring in future OS
In future OS, we expect there will be more restrictions added to device identifiers and more granular control to end users. The expected features making buzz around in future OS is as follows:
Samsung Secure Folder-like 'Private Space'
Google can come up with the concept of 'Private Space' in Android 15 or later. This could be similar to the ‘Secure Folder’ concept already being present on Samsung Galaxy Smartphone where a secure space on the device is created to encrypt and store users private data and apps. Apps and data in Secure Folder are sandboxed separately on the device and gain an additional layer of security and privacy, thus further protecting them from malicious attacks.
It would be interesting to see how device owner can leverage this concept more for device security.
Turning NFC into a Project Mainline module
Like with Wi-Fi and Bluetooth, Google would likely make NFC also a Project Mainline module in Android 15 or later, allowing for it to be updated outside of normal Android version updates. It would be more easily updatable through Google Play System Updates, hence improving quality and interoperability.
Conclusion
Given the privacy enhancements introduced through OS upgrades and the increasing user concern for privacy, MaaS360 constantly adopts the latest android APIs and changes. This has ensured IT administrators have enough control while ensuring most advanced privacy features and security measures available to the end users. Users are strongly encouraged to keep their devices updated to the latest OS version, ensuring access to the latest features and heightened privacy safeguards.