Android 17, the app lock will be even more secure

The path toward the release of Android 17 continues at a slow but inexorable pace, and with every new Canary version of the operating system, details emerge that delineate what could be one of the most significant privacy updates for Google’s operating system.

Among the most anticipated and talked-about features there is undoubtedly a native solution for blocking apps, the so-called “App Lock“.

Although the idea of protecting access to specific apps via biometric authentication or a code isn’t new in the Android landscape, thanks largely to manufacturers’ customizations, the direct integration into the operating system’s source code represents a fundamental turning point.

App Lock will also block notifications from protected apps

Until recently, we only had a general idea of how this feature could operate.

However, a recent in-depth code review conducted on the Android Canary 2601 build has shed new light on one of the most critical aspects of user privacy, namely the handling of notifications coming from blocked apps.

These lines of text reveal Google’s intention to manage notifications in a much more granular way than in the past, especially when it comes to apps the user has decided to protect. The strings found, which read “New notification” and “New message“, suggest an approach that balances the need to be informed with the right to privacy.

In practical terms, this means that when a blocked application receives a notification, the system will no longer display the sensitive content in the notification shade or on the lock screen. Instead, the text of the message or the notification subject will be obscured.

For example, suppose a user has enabled the app lock for Google Messages or for WhatsApp; upon receiving a new text, the notification drawer will only display a generic “New message”, completely hiding the body of the text and the sender.

For all other alert types that do not fall under messaging, the system will opt for an even more generic “New notification”.

User experience and comparison with OEMs

This native implementation seems to follow the path already laid out by several OEMs that have long offered proprietary solutions to fill the gaps of the stock Android version.

Although there is currently no absolute certainty about every graphic detail, it is reasonable to assume that the name of the application and its icon will remain visible. This approach is standard in the industry because it allows the user to understand which service needs attention without exposing sensitive data to prying eyes, preserving the utility of the notification but eliminating the risk of privacy violation.

The integration of this feature directly in the core of Android 17 could standardize the user experience across all devices, irrespective of the manufacturer, ensuring a uniform level of security and potentially more optimized than third-party solutions or proprietary skins, which can sometimes impact performance or battery life.

The unknowns of software development

It is worth emphasizing, with the typical rigor that accompanies software analysis in development, that what has been discovered is not yet definitive. The information, as mentioned, comes from an APK teardown, a practice that allows to foresee future functionalities based on work-in-progress code snippets.

The history of Android development has taught us that not all tested features in Canary or Beta versions reach the final public version. Google might decide to radically modify how App Lock works, delay it, or, in the worst case, remove it entirely before the official release.

However, the presence of such specific strings is a strong indicator of the direction being taken by Mountain View. Privacy has become a central topic in today’s tech debate, and a native and intelligent app lock system would represent a response to users’ demands.