Google looks to be building a system-level App Lock into Android 17, which would provide Pixel owners with an inaugural means of locking individual apps behind their biometrics or a PIN without having to turn to third-party utilities.
The latest Android Canary builds reveal hints of a new API that will allow the default home screen launcher to lock and unlock apps at the system level, stoking speculation that Google plans to add a built-in privacy layer that could blend right into Android’s core interface.
- Why a built-in app lock is important on Android phones
- How Google could implement a native app lock in Android
- Private Space is not a replacement for per-app locks
- Stronger than third-party app lockers at the system level
- What Pixel owners can expect next with Android 17 App Lock
- Open questions to watch as App Lock moves toward release
Why a built-in app lock is important on Android phones
Banking credentials, private messages, health records and work data are all jammed onto smartphones. Passing your device to a friend or kid can frequently entail maintaining a mental list of what not to click on. A native App Lock would provide fast, granular control — lock your banking and social media apps while keeping messaging and video ones accessible — rather than forcing you to juggle user profiles or cobble together clunky add-ons.
The demand is obvious. Data.ai has noted that people interact with about nine apps a day and over 30 monthly, so the friction of protecting your many apps can accumulate quickly. Delivering a first-party solution would eliminate the need for that task, especially since Pixel users have had to go without such a feature in a pure Android experience.
How Google could implement a native app lock in Android
Code found in the recent Android Canary builds suggests a system-managed permission to pin apps that’s limited to system components and the app with the HOME role (which is generally your default launcher).
In application terms, this would mean long-pressing an app icon and tapping a Lock option, then being prompted with a system dialog to confirm. Because this logic exists in the framework, it would not be removable or bypassed at will like any third-party lockers.
The implementation seems optimized for phones and tablets, with checks that filter out platforms like Wear OS, Android TV, and Android Automotive. Supervised profiles might also be locked down, ensuring that the feature is still all about the user. Although the enforcement code is not yet live, Android’s BiometricPrompt would presumably be used for authentication — giving fingerprint, face, or a fallback to PIN/pattern in a consistent, secure UI.
Android expert Mishaal Rahman has pointed out that flags governing the feature are still disabled, suggesting that Google is in the early days of rolling it out. With Android’s release schedule and Google holding back new APIs for major platform updates, the earliest it could appear is pretty much guaranteed to be Android 17.
Private Space is not a replacement for per-app locks
Android’s Private Space has an app-isolation feature that puts apps in a separate profile or other partition, but it is not designed primarily with convenience in mind. Apps cannot live on the main home screen, and every time the container is opened, it must be opened from the app drawer. The strict siloing is great for compartmentalization, but it makes routine workflow actions — like sharing files or quickly launching often-used apps — unnecessarily complicated. A per-app lock inside the main profile would hit that 80% use case with so, so much less friction.
Stronger than third-party app lockers at the system level
Most third-party lockers are essentially just normal apps. That way they can be uninstalled to disable protection, and a lot of those applications actually use the Accessibility service in order to monitor which app is in the foreground — which introduces privacy and performance issues as well as becoming increasingly blocked by Play policy changes. Some request Device Administrator access, which few people feel safe allowing. That missing App Lock at the system level would address those weaknesses and ensure some degree of protection is implemented within the OS itself.
It would also bring Pixels in line with OEM skins that already have them for the taking. Samsung users have Secure Folder, people with OnePlus can use App Locker, and Xiaomi has an App Lock built in. A native Android implementation would provide consistency across devices and launchers, reduce fragmentation, and make life easier for developers and IT administrators.
What Pixel owners can expect next with Android 17 App Lock
The feature isn’t live and the developer-facing bits are still behind flags, so it’s not on track for the quarterly platform updates we’re getting right now. Traditionally, Google introduces new platform APIs with a major release, so Android 17 is the soonest reasonable goal. If and when it does land, Pixel phones will probably show it off first before third-party launchers seize upon App Lock through the new permission if given the opportunity.
Open questions to watch as App Lock moves toward release
Notification management is the major variable: will previews of locked apps be hidden until unlocked, or left alone? There are enterprise scenarios to consider as well — what will be App Lock’s relationship with Work Profile policies being enforced via Android Enterprise? Also worth noting is how it behaves, backup/restore-wise, parental control integrations, and whether you’re going to support per-app PINs as well as biometrics.
Even with those open threads, the trajectory is clear. A built-in App Lock would provide a more straightforward, secure way to hand off your phone without revealing everything that’s on it — the type of nifty privacy bonus, really, that Pixel owners have been asking Google to bake into Android for ages.