Menu
Android powers more than 2 billion devices, and over the course of 2017, 82 billion apps were installed on Google Play. In short, that’s a lot of personal data at risk. It’s no wonder that Google has made the protection of all application data a top priority.
Even though Google has employed a long-term, holistic approach to app security, scanners don’t catch everything. Users still have to be cautious of compromised apps, spyware, and distributed malware. In response to these digital threats, Google recently issued an advanced notice of the security and performance enhancements in the works for 2018. Here’s how Google plans to improve Android app security in the future.
Developers can expect changes to be made to how apps access user accounts. Apps will no longer be able access a user’s system data or device features without explicit permission. This requirement will enforce stricter protection from malware and promote enhanced overall security.
Each Android application operates within what is called a process sandbox. These silos give Android apps a unique advantage because malicious software can be contained and detected more efficiently. If the app requires data resources outside of its unique sandbox, use permission is required.
An Android app in its most fundamental form has no default permissions, and cannot do anything to harmfully impact the user experience. For access to protected device data, permission tags must be written into the app manifest.
As of today, applications which are compatible with older Android operating systems – Android Lollipop and lower – use permissions are requested at installation. If a new permission is added, the user isn’t notified until they update the application, and once the software is installed, permission cannot be revoked unless the app is uninstalled entirely.
However, by the second half of 2018, Android will require new apps to operate at most recent API level. This requirement will ensure apps are built to accommodate improved security and performance functionality. After this change, use permissions will be delivered to the user at run-time and can be revoked at the user’s leisure. This enhancement gives users complete control over what private data is accessed by their most used apps.
The restrictions Android is imposing on system permissions is aimed to limit an apps access to potentially dangerous permissions. Android categorizes system permissions into a number of protection levels, but the most familiar protection levels are what Android labels normal and dangerous.
Requests for a user’s calendar, camera, contacts, location, microphone, SMS, or storage are classified under the dangerous permissions group. If an app gains access to a particular function that is labeled under a dangerous permissions category, the system automatically grants access to any other function within that group – for now. For example, if an app obtains permission to read a user’s contacts data, and subsequently requests to then write a user’s contacts data, the system will automatically award permission. However, by 2019 developers will be required to release and update apps to be compatible with every new Android dessert release (e.g Oreo), and as a result, every call for private data will rely on user authorization.
While this decision does limit major security risks, it could potentially insight backlash regarding reduced functionality and experience interference.
Building software on Android has allowed developers to use data permission to manipulate, tweak, and enhance functionality for the sake of user experience. Developers could use these permissions, which were originally used to make a particular function or feature easier for people with disabilities to use, to improve the universal user experience. Functional details like remembering passwords, capturing text, simplified copy-and-paste, and even the personalization of colors, graphics and animations will all be subject to limitations under Android’s new security limitations.
Another component of Android’s security overhaul is the function that prevents the OS from trusting user-added certificate authorities (CAs) by default. The goal for changing how Android treats CAs is to provide secure app traffic. Starting with Android Nougat, this safe-by-default setting was implemented to promote consistency when managing file-based application data. Android now offers a standardized protocol for integrating trusted system CAs.
Developers have always had the choice to customize which CAs are trusted within their app as they’d like, but Android is now implementing improved APIs for defining trust. User-added CAs can still be customized for trust across the whole application or within specified parameters.
Here are a few examples for programming custom CAs for trust and security.
Include this code if you want your app to trust custom CAs for local debugging. The CAs will only be trusted if your app is flagged as debuggable.
Similarly, the following code will permit your app to trust user-added CAs for a particular domain.
This code will let your app trust custom CAs for any secure connection.
Services are long-running operations that work in the background – or foreground – of an app. Services will continue to run until you stop them, even if a user switches between apps. Multiple components can attach themselves to services and interact with them to perform network transactions, play music, interact with content providers, and perform interprocess communication (IPC).
There are 3 types of services: foreground, background, and bound. By late 2018, Android will be enforcing new requirements for executing bound services.
A bound service allows app components to bind to particular services. A bound service can send requests, receive responses and initiate IPC. As of right now, developers can call bindService() without stating an explicit intent, but that is set to change. Developers will soon be required to state an explicit intent when calling bindService() to prevent apps from overusing device resources and to promote overall app security.
It’s important to note that services have no user-facing interface, and therefore users are unable to see what service starts. When an app uses an implicit intent to start a bound service, it poses a significant security hazard because you can’t be certain what service will respond to the intent. To specify an explicit intent, developers will have to identify the required component by its fully qualified class name. This requirement will drastically reduce the use of shared data between applications. Developers can expect to receive throwback exceptions from the system anytime an implicit intent is called in the future.
2017 was a year of tremendous growth for Google Play. Google’s efforts to proactively reduce risk within the Android app ecosystem has not gone unnoticed. And although Google can’t predict what kinds of attacks are looming, we can expect to see security performance improve over 2018 as Google addresses the ever-expanding range digital threats.
Clearbridge Mobile is an award-winning, full-stack mobile app development company dedicated to helping companies strategize, develop, and scale dynamic mobile app solutions that enhance business performance and enable innovative growth opportunities.
