One of my favorite additions to Android in recent memory is the Quick Access Device Controls feature. This feature, first introduced in Android 11, lets you quickly view and control your smart home devices without having to open an app. With a quick tap of the Device Controls Quick Setting tile or lock screen shortcut, I can control the lights, fans, and thermostat in my home, or I can open a live camera feed from my Nest Doorbell. Unfortunately, the feature has one (in my opinion) major downside: it doesn’t work when my phone is locked.

For security and privacy reasons, I set my phone to timeout after a minute of inactivity, which means that I need to unlock my phone if I haven’t touched it in the past 60 seconds. I don’t have any issues unlocking my Pixel 6 Pro using its under-display fingerprint scanner as some others do, but I think it’s an unnecessary step to take just to change the brightness of my living room lights. That’s why when I saw that Android 13 added a new API to control whether or not authentication is required to interact with a smart home device, I got excited.

Thanks for signing up for The Android Edge newsletter. Every week, my Android Dessert Bites column will share the latest news about the Android platform that matters to system engineers, app developers, and power users.

Android 13 finally fixes the biggest problem with Android 11’s best feature

While poring over the new APIs added to Android 13, I discovered the isAuthRequired method in the Control class. According to the documentation, If the method returns “true”, then the associated Device Control can be interacted with even when the device is unlocked. Armed with this knowledge, I contacted my friend João Dias, the developer of the popular automation app Tasker and a speed demon when it comes to adopting new Android features. His app already makes use of the Device Control API, albeit in an unconventional way as Tasker isn’t a traditional smart home app. He quickly updated the Tasker app with the new API and added a toggle that users can enable when creating a custom Device Control. João recorded the following video demonstrating how to create a Device Control that works on a locked device, proving that the feature is already functional in the Android 13 developer preview builds.

Since this behavior can be set per-control, apps can block users from interacting with certain smart home devices when their phones are locked. I’d imagine that most smart home apps won’t let users view their security camera feeds when their devices are locked, for example. The Google Home app has yet to be updated to support this feature, sadly, so I’ll have to wait a bit longer before I can control my Assistant-enabled devices from my locked phone.

To be honest, I’d prefer if this feature could be managed through Android itself because letting me pick what I want to be able to control is better than relying on app devs to decide for me. That’s not how this feature works, though, and I’d love to hear why Google decided on this approach. I also hope they, and other smart home app developers, update their apps to take advantage of this feature as quickly as possible.


Thanks for reading this week’s edition of Android Dessert Bites. This week’s post is much shorter than usual because my hands are full with Android 13 Developer Preview 2. If you haven’t already, I highly recommend reading my deep dive on Android 13 — it covers almost every new feature, UI change, behavior change, platform change, and API update in great detail. I’m constantly updating it with new findings, and a few hours after this post goes out, I’ll have already highlighted several new discoveries that weren’t documented yesterday.

If you liked this post, then please subscribe to The Android Edge newsletter to get links to future editions of my Android Dessert Bites column. You can find previous editions on this page.