For years, Android users seeking to protect sensitive apps have navigated a landscape of imperfect solutions: manufacturer-specific features, cumbersome workarounds, or risky third-party applications. This long-standing gap in Google's mobile operating system may finally be closing. Evidence discovered in a recent Android Canary build suggests that Google is developing a native, system-level App Lock feature, potentially for release with Android 17. This development promises to deliver a secure, convenient, and integrated method for locking individual applications, a feature many users have been requesting for years.
Evidence Points to a System-Level App Lock API
The discovery was made by Android Authority within the code of the latest Android Canary release (build 2512). The code references a new App Lock API, accessible through a permission named LOCK_APPS. This permission is restricted to internal system apps and, crucially, the application that holds the HOME role—typically the user's default launcher. This design means the feature would be available to any launcher that chooses to implement it, not just Google's stock Pixel Launcher. The API is invoked by launching an Android system activity via the SET_APP_LOCK intent action, which then presents the user with a confirmation dialog to lock or unlock a selected application.
Feature Discovery & Technical Details
- Source: Code in Android Canary build 2512.
- Key API: New App Lock API gated by
LOCK_APPSpermission. - Access: Granted to system apps and the app holding the
HOMErole (default launcher). - Activation: Launcher starts system activity via
SET_APP_LOCKintent. - Device Restrictions: Excludes Wear OS, Android Automotive, Android TV, and supervised user profiles.
The Shortcomings of Current Android Security Options
Android's existing privacy tools have proven inadequate for daily, convenient use. The Private Space feature, while secure, creates a completely siloed environment. Apps moved into Private Space run in a separate user profile, cannot be placed on the home screen, and have difficulty accessing files from the main profile. This makes it impractical for frequently used applications. On the other hand, third-party app lockers available on the Google Play Store are fundamentally flawed. As standard apps, they can often be bypassed by simply being uninstalled. To counter this, many request intrusive Device Administrator privileges, posing a significant security and privacy risk, or rely on hacky methods using the Accessibility API that can impact performance.
Comparison of Android App Security Methods
| Feature | Native App Lock (Planned) | Private Space | Third-Party App Lockers |
|---|---|---|---|
| Convenience | High (apps remain on home screen) | Low (siloed, no shortcuts) | Varies |
| Security Level | System-level, high | Very high (separate profile) | Low (can be uninstalled) |
| System Integration | Native, seamless | Native but isolated | None, requires workarounds |
| Trust Model | Inherent (from OS) | Inherent (from OS) | Requires trust in developer |
| Performance Impact | Negligible (system API) | Negligible | Often high (background monitoring) |
How a Native Feature Solves Long-Standing Problems
A system-level App Lock, built directly into the Android framework, would elegantly resolve these issues. It would be impossible to bypass by uninstalling an app, as the locking mechanism would be part of the operating system itself. This grants it inherent trustworthiness over unknown third-party developers. Furthermore, it would not need to rely on performance-draining background monitoring. While the specific locking mechanism is not yet implemented in the discovered code, it is highly likely Google will leverage its existing Biometric Prompt API, offering users a choice of fingerprint, face unlock, or their device PIN/pattern to access locked apps seamlessly.
Anticipated Implementation and Release Timeline
The user interface for triggering the lock will be left to launcher developers. The most logical implementation would be a new "Lock app" option in the context menu that appears when a user long-presses an app icon on their home screen or in the app drawer. As for a release date, the feature is not active in the current Canary build and is controlled by disabled flags. It is also unlikely to appear in the upcoming Android 16 QPR3 update, as those quarterly releases typically do not introduce new developer APIs. Therefore, the earliest plausible launch window is with the major Android 17 update expected in the second half of 2026, though Google's plans could always change.
Remaining Questions and Future Development
As development continues, key questions remain about how the feature will behave in practice. A major point of interest is how notifications from locked apps will be handled. To be truly effective, the content of notifications from a secured app should likely be hidden or redacted until the user authenticates. While no code pertaining to notification modification has been found yet, this is a logical enhancement Google could add before the final release. This potential addition of a native App Lock represents Google catching up to a basic security convenience that has been offered by other OEMs and even Apple with iOS 18, finally providing a robust, built-in solution for all Android users.