Android 17 may finally add the native App Lock feature Pixel users have been waiting for

People store a lot of sensitive data on their Android phones, so it’s no wonder they are reluctant to hand them over to anyone they don’t trust. Even if you are comfortable letting a friend or family member borrow your device, you probably still have data you don’t want them to see. Locking down specific apps is a great way to protect your privacy, but the core Android OS still lacks a native way to do this, forcing many users — especially of Pixel devices — to rely on third-party tools. Fortunately, Google may finally address this in next year’s Android 17 update by adding a new App Lock feature.

Apart from Private Space, Android lacks a native way to secure apps behind your screen lock or biometrics. The issue with Private Space is that it isn’t designed for convenience. When you move an app there, it is sequestered; that works fine for apps you rarely open, but it quickly becomes a hassle for apps you open daily. Apps inside Private Space cannot be placed on your home screen, and the container itself lacks a shortcut. To access these apps, you are forced to unlock the space by opening the app drawer then and scrolling or searching every single time.

Furthermore, apps within the Private Space are completely siloed from the rest of your system because they run in a separate user profile. This isolation prevents them from easily accessing files in your main profile — great for privacy, but a headache for productivity. While you can manually move files back and forth, it is not a workflow you want to be doing daily.

This is why many OEMs developed their own App Lock solutions for their specific Android skins. Without a native option in the core OS, however, Pixel users are forced to rely on third-party app lockers, which are fundamentally flawed. Since these tools are just standard apps, they can be easily bypassed by simply uninstalling them. The developers of these apps often try to plug this hole by requesting Device Administrator privileges, but granting that level of control to a third-party app requires a massive amount of trust. Furthermore, the detection methods are often hacky, relying on the Accessibility API to monitor your screen for specific window openings — which poses both privacy and performance problems.

A native, system-level App Lock would solve all of these problems. It would be impossible to uninstall, inherently more trustworthy, and wouldn’t rely on janky workarounds to detect when a protected app is launched. The good news is that there is strong evidence Google is working on a native App Lock for Android, and it appears it will be accessible to all launchers, not just the stock one.

While digging through the latest 2512 Android Canary release, I discovered code within the Android framework package hinting at a new App Lock API. Access to this API is gated behind the new LOCK_APPS permission, which is restricted to internal system apps and the app holding the HOME role. Since the user’s default launcher is automatically granted the HOME role, it is eligible to hold this permission.

With this permission, the default launcher can invoke the API by starting Android’s App Lock activity via the SET_APP_LOCK intent action. The system then validates the request by checking if the target app has a launcher entry, isn’t on a system exemption list, and checks its current lock status. If the app is eligible to be locked, the user sees a prompt asking, “Lock [App Name]?” Conversely, if the launcher requests an unlock, the dialog asks, “Remove App Lock from [App Name]?” Once the user confirms the action, the system displays a toast message verifying the change.

Here are the relevant strings pertaining to these dialogs:

Android also includes several checks to ensure the App Lock feature is used as intended. First, it verifies the device type to exclude Wear OS, Android Automotive, and Android TV, as the feature is intended for handhelds. Second, it checks that the current user isn’t a supervised profile, restricting app locking to the main user.

You might be wondering how you actually trigger the lock. Since the API is exposed to the launcher, the specific UI implementation is left to the launcher’s developer. I suspect most launchers will simply add a new lock button or action to the context menu that appears when you long-press an app icon.

As for the locking mechanism itself, the code hasn’t actually been implemented yet, at least not in this Canary release. However, I would be surprised if Google doesn’t leverage Android’s existing Biometric Prompt API. This would provide a standardized way to secure apps using biometrics, with a seamless fallback to the device PIN or pattern.

As for the feature’s expected release date, we don’t know for certain. The feature is not live in the current Canary release, as the flags controlling it are disabled. We also don’t expect it to land in Android 16’s third quarterly release (QPR3), given that it won’t introduce new developer APIs. Thus, the earliest we expect to see the App Lock feature appear is in next year’s Android 17 update, though there are no guarantees.

Android Authority will keep a close eye on this feature as it develops. We are particularly interested in how App Lock will handle notifications from secured apps. Specifically, whether they will be fully visible or if their content will be redacted. While the latter is the logical choice for this feature, I haven’t found any code suggesting notifications will be modified, though Google could certainly add that functionality before launch.