Affiliate links on Android Authority may earn us a commission. Learn more.
Android Q to improve security on entry-level devices
![Google I/O 2019 Android Q Logo Google I/O 2019 Android Q Logo](https://www.androidauthority.com/wp-content/uploads/2019/05/google-io-19-android-q-logo.jpg)
Security and privacy are more important than ever, and Google knows it. The company pivoted big time with respect to both at its Google I/O developer conference this week in Mountain View. Google’s renewed focus on security and privacy is highlighted in Android Q, where the company incorporated a range of protective layers.
The basics include more widely available encryption, new authentication behaviors, and strengthened code.
![android security os framework - Google 2019 security framework](https://www.androidauthority.com/wp-content/uploads/2019/05/android-security-os-framework-Google-2019.jpg)
Adiantum, not adamantium
Wolverine’s bones are grafted with a fictional super metal that Marvel calls adamantium. Similarly, Google is protecting Android’s core on low-end phones with a real-world encryption profile called adiantum.
The majority of today’s mid-range and high-end phones are mandated to run AES encryption. AES requires hardware acceleration, which is why it only works properly on well-spec’d devices. AES cannot run on the majority of phones in the sub-$100 price point, not to mention Wear OS or Android TV devices, and that’s a problem as far as Google is concerned. Enter adiantum.
Google will require encryption for all devices starting with Android Q.
Adiantum is based on an open-source Linux kernel. Google has worked with the Android Go and Android One teams to adopt adiantum in Android Q. The Android Go and Android One teams have, in turn, coordinated with silicon providers such as Qualcomm and MediaTek to make this a reality. Adiantum is a software-based alternative to hardware-accelerated AES. Even the least-powerful devices can handle it, meaning everything from wearables to medical devices can enjoy the security offered via encryption.
Google will require encryption for all devices starting with Q, and adiantum is how low-end devices will deploy it. Mid- and high-end devices that can run AES will continue to run AES.
Adiantum is in alpha status right now, but will be ready by the time Android Q is finalized later this year.
![android security rating - Google 2019 security rating](https://www.androidauthority.com/wp-content/uploads/2019/05/android-security-rating-Google-2019.jpg)
The other half
Encrypting devices is one part of the story, encrypting the link from the device to the network is the second part.
Android Q adopts TLS 1.3, a revision to the IETF standard that was completed last year. TLS 1.3 encrypts and secures the traffic from your phone to whatever internet-based service to which you are connecting. In other words, that purchase you want to make while surfing the Wi-Fi at Starbucks is now forcibly protected.
Google says TLS 1.3 is cleaner and more stable than TLS 1.2, and it provides the strong handshake between entities needed for security. Speed is a side benefit. TLS 1.3 can reduce connection times by about 40%. TLS 1.3 will be enabled b default in Android Q.
Biometrics abound
Biometrics will play a more prominent role in security as you interact with your Android Q-based device. Android Q updates the BiometricPrompt API in order to help developers tap into biometrics for authentication purposes. Moving forward, developers will be able to enforce explicit or implicit actions.
With explicit actions, users must perform a direct action for authentication by touching the fingerprint sensor or scanning their face. This type of authentication would be required for making payments or money transfers.
With implicit actions, users won’t have to take such a direct approach. Apps can automatically scan the user’s face upon open, for example, allowing the user to jump right to the app in question. Google envisions implicit actions authenticating app logins or form fill behaviors.
Users must perform a direct action for authentication.
Developers will be able to allow users to default to PIN, pattern, or password backups for either explicit or implicit actions if they wish, as sometimes it is not always possible for a phone to scan a face due to lighting. It will be up to individual apps to adopt this type of behavior.
Cleaner code
![Google Chrome app Pixel 2 XL AA 3 Google Chrome on the Pixel 2 XL.](https://www.androidauthority.com/wp-content/uploads/2018/04/Google-Chrome-app-Pixel-2-XL-AA-3.jpg)
Google isn’t placing all the onus of security and privacy on developers and end users. It worked to harden its own code in various parts of the operating system to better protect everyone. Google says it focused on key weaknesses, such as media, Bluetooth, and, believe it or not, the core kernel.
It used fancy processes such as “process isolation,” “attach surface reduction,” and “architectural decomposition” to find vulnerabilities and exploit them. Once the holes were found, Google patched them up.
Much of this work focuses on automating everything. Google wants end users to know that their phones and other devices are secure by default. This is a significant step forward. Combined with the new privacy and security tools available to developers, Android Q add a fine layer of armor (alas, not vibranium) over the platform.