Hey all. My daughter is 12 and has an Android phone. She has been staying up way too late on it and ignoring homework time. I want to be able to lock it from my phone without having to walk into her room every night and have the same argument. Is there a way to do this remotely? Preferably something that works even if she has turned off Wi-Fi. Any help appreciated.
There are two broad approaches to locking a child’s phone remotely. The first is using the built-in parental tools that come with Android or iOS. The second is using a third-party family management app that gives you more granular control. Which one is right depends on your child’s device and how much visibility you actually need.
For Android: Built-In Parental Controls
Android’s native solution is Google Family Link, which is free and reasonably capable. Setup involves linking a Google account for your daughter to your own through the Family Link app, after which you can issue an instant lock from your phone, or set a scheduled Downtime that triggers automatically every night. Lock commands are delivered over mobile data as a fallback if Wi-Fi is off, though airplane mode can interrupt delivery until connectivity is restored. You can restrict network setting changes inside the app to close that gap.
That said, Family Link has real limitations worth knowing upfront. It does not give you content-level visibility, you can see which apps were used and for how long, but not what was said or viewed. Once your daughter’s Google account turns 13, Google prompts her to take over account management herself, which effectively removes Family Link supervision unless she agrees to keep it voluntarily. The controls are also fairly binary: you lock the phone or you don’t, with limited granularity between those two states.
For iPhone: Screen Time with Downtime
On iOS, the equivalent is Screen Time, built into Settings. You set a Screen Time passcode your child doesn’t know, configure Downtime hours, and the phone becomes restricted to only the apps you explicitly allow during those hours. Remote adjustment is possible from your own iPhone through Family Sharing. One practical note: make sure you tie the Screen Time passcode to your Apple ID for recovery, otherwise a motivated teenager who resets the phone could clear the restrictions.
Where Third-Party Apps Fill the Gap
For parents who need more than scheduled locks, particularly around content monitoring, cross-platform management, or detailed activity logs, third-party monitoring apps are worth considering. They operate independently of the built-in tools and often offer capabilities those tools don’t expose, such as keyword alerts, message monitoring, and remote control that persists across device resets. Whether that level of oversight is appropriate depends on your child’s age, maturity, and what specific problems you’re trying to solve. For a 12-year-old with a bedtime problem, the built-in tools are a reasonable starting point, but it’s worth knowing that more capable options exist if you find the native controls insufficient after a few weeks.
GorillaBlink covered the two-route split well. I want to add specifics about the bedtime scheduling side since that’s the core of what JoelSanders is actually dealing with.
A few settings that trip parents up when first configuring scheduled Downtime:
Always Allowed apps persist through any lock. By default the Phone app is always allowed so emergency calls still work, which is correct. But check this list carefully, some parents accidentally add other apps here without realising it, and those remain accessible during Downtime regardless of any other settings.
App Limits and Downtime are separate mechanisms. You can set a daily cap for a specific app say, two hours of YouTube that triggers independently of your bedtime schedule. If the issue is partly about social media or video apps during homework hours rather than just at night, Daily App Limits handles that without requiring a full device lock.
The Request More Time feature is underused. Your daughter can send a time extension request that you approve or deny from your phone. This is worth leaving on rather than disabling. It turns a hard cutoff into a conversation channel, which tends to reduce workaround-seeking behaviour. Kids who feel they have a legitimate path to ask for more time are less motivated to find technical ways around the restriction.
On the Wi-Fi concern specifically: scheduled locks are delivered over mobile data as a fallback, so turning off Wi-Fi doesn’t help. Airplane mode is the only reliable user-level workaround, and that can be addressed by disabling the ability to change network settings from within the parental control app settings. With that restriction in place, the main remaining bypass at the software level would be a factory reset and a supervised account can be set to require your credentials to complete a reset and re-link the device.
The Wi-Fi and airplane mode question deserves a more technical answer because it comes up constantly and the actual mechanism is reassuring once you understand it.
Parental control lock commands on Android travel through Google Play Services, which is a system-level process rather than a regular app. This means it runs at a privilege level below what the user can interact with, and it uses whatever data connection is currently active Wi-Fi, mobile data, or either. A child cannot selectively block that traffic without rooting the device, because regular user-space actions don’t reach that layer.
Airplane mode cuts all radio connections simultaneously, which does interrupt the lock command delivery. However, the command is queued server-side and executes the moment any connection resumes. So airplane mode delays execution but doesn’t prevent it. The practical fix is restricting the ability to toggle airplane mode or mobile data from the parental app’s device settings once that’s locked, the user-accessible bypass options narrow considerably.
The one remaining hardware-level path is a factory reset. On a supervised account this is addressed by requiring the linked account credentials during the Android setup wizard after a reset. Since you hold those credentials, even a factory reset doesn’t free the device from supervision it just brings the phone back to a state where it can’t be used at all without your account.
For parents worried about technical circumvention: stock Android on a standard device with a properly configured supervised account is genuinely difficult to bypass through normal user actions. The attack surface mostly exists at the physical layer (SIM swaps, new device) or requires technical knowledge well beyond a typical 12-year-old.
GlassTech’s point about system-level integration is worth extending for Samsung users specifically, since Samsung devices introduce a few additional variables.
Samsung runs One UI on top of Android, and One UI includes its own Digital Wellbeing layer that overlaps with but doesn’t replace Android’s native parental controls. Samsung also has a Bedtime Mode under Digital Wellbeing that goes beyond a standard lock it greyscales the screen, reduces brightness, and suppresses all non-critical notifications. This is separate from a hard lock and works as a friction layer rather than a restriction.
For a Samsung device, a practical layered setup looks like this: configure your supervised account and remote lock capability through the Android-level parental controls for the hard lock functionality, then add Samsung Bedtime Mode on top to make the phone genuinely unpleasant to use even if the lock hasn’t triggered yet or a minor gap exists. Both systems run simultaneously without conflicting.
One thing to be aware of with Samsung specifically: Knox, Samsung’s security framework, adds its own layer of access controls that some third-party monitoring apps interact with differently than on stock Android. If you end up moving beyond built-in controls to a third-party app later, check its compatibility with One UI specifically rather than just checking for generic Android support.
Adding a perspective from running this for 18 months across two kids, one on Android and one on an older iPhone.
The Android bedtime lock has been running on my son’s phone for about 18 months. He pushed back hard for the first two weeks, then accepted it as just how things are. The variable that made the biggest difference wasn’t the technical setup it was how the initial conversation went. I sat down with him, showed him the parental app, explained what I could see and what I could do, and we set the bedtime together. He wanted 10pm, I wanted 9:30pm, we landed on 9:45pm. That negotiation made a significant difference in how he received the restriction. He’s not fighting me, he’s living with a system we agreed on.
The iPhone situation for my daughter was slightly trickier. Screen Time is solid but has one practical vulnerability: if your child learns or guesses the Screen Time passcode, they can modify or disable restrictions directly from the device. The fix is two steps: make the passcode genuinely unguessable, and enable Apple ID-based passcode recovery so that even if the passcode is forgotten, it cannot be reset by someone who doesn’t control the Apple ID. With those two things in place, Screen Time is quite resistant to user-side tampering.
The broader point: the framing of the initial conversation affects how hard kids push against these systems. A unilateral setup that the child discovers later tends to produce a lot more workaround-seeking than a setup they know about and had some input into. The technical configuration is the same either way the response to it isn’t.
DroidPro’s negotiation point is worth highlighting separately because it doesn’t come up enough in these conversations.
Remote device control is a tool, and like any tool its effectiveness partly depends on context. A child who understands what the system does, why it exists, and what recourse they have tends to engage with it very differently from a child who runs into a mysterious lock and starts looking for ways around it. The technical setup handles the mechanical problem. The conversation around it affects whether that setup actually produces the outcome you want.
My daughter is 14 and knows exactly what I have configured. She also knows she can send a time extension request if something specific is happening, a group project running late, something going on socially that she needs to respond to. That request pathway matters. It gives her a legitimate option other than circumvention, which means she uses it instead of trying to find workarounds.
From a purely practical standpoint: a child who believes the system is fair, or at least predictable and explainable, has less motivation to route around it. The layered technical controls matter and you should set them up properly. But they work better in an environment where the child understands the reasoning rather than just encountering an unexplained restriction. Setting the bedtime together, as DroidPro described, is probably the most effective single thing you can do alongside the technical setup.
#Third-Party Options and When They Apply
Built-in parental controls handle scheduled locks and basic app management reasonably well. The gaps parents commonly encounter are around visibility, you can see which apps were used and for how long, but not what was communicated or searched and around consistency across devices, since Android and iOS controls don’t talk to each other if you have multiple devices in the family. There’s also the age transition issue on Android where supervision can be opted out of at 13.
Third-party apps approach this differently. Rather than sitting on top of the OS, the better ones integrate at a deeper level and give parents a unified view across devices, along with capabilities the built-in tools don’t expose.
Third-Party Options Worth Knowing
Xnspy is one of the more capable options for detailed monitoring. It runs as a background service on the child’s device and logs app usage, web history, location, and call and message activity into a parent-facing dashboard. It also supports remote screen time management, so you can lock the device or set usage limits from the parent app independently of the device’s built-in controls. The monitoring component gives it more depth than native tools; you’re not just seeing app names and usage durations, you’re seeing enough context to understand what the device was being used for. It’s particularly relevant for parents who’ve found that built-in activity reports are too surface-level to be actionable. Setup requires installing the app on the child’s device, which is straightforward on Android.
Qustodio is another option that sits between pure monitoring and full control. It offers app blocking, time scheduling, content filtering, and a parent dashboard with usage reports across multiple devices. It handles both Android and iOS from a single parent account, which helps in mixed-device households.
Bark takes a different approach entirely. It doesn’t give parents direct device control, no remote lock, no app blocking. Instead it connects to the child’s accounts and scans for patterns that suggest something concerning: signs of bullying in messages, depression indicators, exposure to inappropriate content. You receive alerts rather than raw access. It’s less relevant for the screen time problem JoelSanders described but fills a different gap for parents of older teenagers who’ve moved past blanket restriction into awareness-based oversight.
The Right Starting Point
For a 12-year-old with a bedtime and homework focus issue, the built-in controls with proper configuration particularly the network restriction settings are a sensible starting point at no cost. Third-party apps become more relevant if you find the native visibility insufficient after a few weeks, or if you need consistent management across multiple devices with different operating systems.
The distinction LinkRead drew between monitoring and restriction is worth being precise about because the two serve fundamentally different purposes and the choice between them reflects what problem you’re actually trying to solve.
Restriction tools, scheduled locks, app limits, device downtime… address access. They prevent the phone from being used in certain ways during certain hours. They don’t tell you anything about what the child is doing during the hours the phone is unlocked and accessible.
Monitoring tools address visibility. They tell you what the device was used for, what content was accessed, what was communicated. They don’t necessarily stop anything, but they give you information that lets you have more informed conversations and catch things before they escalate.
For a 12-year-old with a homework and bedtime problem, restriction is the right primary tool. You’re solving an access problem: the phone is accessible when it shouldn’t be. Locking it during those windows directly addresses that. Monitoring is supplementary at this stage, useful context, not the main mechanism.
As kids get older and blanket restriction becomes less appropriate, that balance tends to shift. A 16-year-old who needs to be reachable but whose judgment isn’t fully formed is a different problem than a 12-year-old who just needs the phone off at night. Tools like Bark make more sense at that stage because you’re not trying to restrict access, you’re trying to maintain enough visibility to catch something serious if it develops.
One practical note on the Android age transition: the supervised account setup on Android prompts the child to take control of their own account at 13. It’s worth knowing about and discussing in advance. Some families use that transition as a point to shift from restriction-focused to monitoring-focused oversight rather than going from full supervision to nothing, the gradual handover tends to go better for everyone.
The 13-year-old transition on Android caught me completely off guard so I want to add more detail on what actually happens.
When a child’s linked Google account approaches its 13th birthday, Google sends a notification to the child (not the parent) explaining that they’re now old enough to manage their own account. The child can agree to transition, which removes the supervision association and with it the remote lock and monitoring capabilities on the parent’s side. This is Google’s privacy policy implementation, they treat 13 as the age of digital consent in most jurisdictions.
The way to handle this is to be ahead of it. Talk to your child before the notification arrives. Explain what the transition means, what it changes, and what you expect from them once it happens. Many kids are fine with voluntarily keeping monitoring active if it’s framed as a trust arrangement rather than a restriction “I’m giving you more control, and I’m keeping this visibility as part of the agreement” lands differently than “I’m keeping this because I don’t trust you.”
Some families use this transition as a deliberate moment to restructure the oversight setup. The Android-level supervision comes off, and something like a third-party monitoring app takes its place less restrictive in terms of hard locks, more focused on visibility and alerts. The monitoring happens in the background rather than as an active control layer. That shift from explicit restriction to ambient monitoring tracks reasonably well with the actual change in what’s appropriate for a 13-year-old versus a 12-year-old.
Slightly different scenario worth covering: what if the child has a device that isn’t set up under an account you control?
This came up for a friend whose stepson arrived with an Android phone already linked to an account they had no access to. The built-in parental controls require account-level access to configure, so the options in that situation are more limited.
Factory reset and supervised setup is the cleanest fix. Reset the device, go through Android setup fresh, and link it to a Google account you control from the beginning. This is the right approach if you have the ability to have that conversation. It does require cooperation or at least acceptance from the child.
Router-level controls are an alternative that doesn’t require touching the device. Modern mesh routers Eero, Google Nest WiFi, and others have scheduling features that let you pause internet access for a specific device by MAC address. You can cut home Wi-Fi access on a schedule without any software on the phone at all. The limitation is mobile data, which bypasses the router entirely. Carrier-level data restrictions through your family plan can address that, if the line is on your account.
Third-party monitoring apps with device-level installs don’t require account-level access in the same way the built-in tools do you install the app on the device and configure from there. This is worth knowing if you’re in a situation where account access isn’t an option but physical access to the device is.
The router approach is underrated and I use it as a deliberate backup layer even with device-level controls already running.
We use an Eero mesh system at home. The Eero app has a Schedules feature per device where you can set a specific device to lose internet access after a set time. I have my son’s phone set to go offline at 9:30pm through Eero, and also have the device-level bedtime set for the same time. Two separate systems, both pointing at the same cutoff.
The reason I kept both rather than relying on one is that they address different things. The device-level lock prevents app usage even offline games, cached content, anything that works without a connection. The router block stops all internet-dependent activity. Together they close both gaps.
On mobile data bypassing the router: that’s a real limitation. The way I handled it was setting a mobile data usage cap within the parental app. Once the cap is hit, further mobile data use is restricted. It’s not a precise bedtime mechanism on its own but combined with the router block and the device bedtime, getting online after 9:30pm requires enough effort that it just doesn’t happen.
The general principle is that each control layer has a gap and each layer covers another’s gap. Device-level lock has the offline content gap, router covers that. Router has the mobile data gap, a data cap covers that. No single control is complete, but stacked correctly they make circumvention non-trivial for a 12-year-old.
The layered approach is the right framing, and I want to extend it into the homework versus bedtime distinction because JoelSanders mentioned two separate problems that actually have slightly different solutions.
Bedtime is an access-off problem. After a certain hour the phone should be unusable. The full device lock handles this cleanly.
Homework time is more nuanced. A blanket lock during homework hours creates conflict if your daughter needs the phone for school materials, and a lot of kids legitimately do Google Classroom, group chats with classmates, school-specific apps. Locking everything during those hours removes legitimate tools alongside the distracting ones.
A more targeted approach for homework time is blocking specific apps rather than the whole device. Social media, video apps, and games can be blocked between 4pm and 7pm while the browser, Classroom, and communication apps remain accessible. The phone is still usable for school purposes; the distracting parts aren’t.
App Limits handles this with per-app or per-category limits. Setting a daily limit of zero minutes for apps in the Social and Entertainment categories effectively blocks them for the day or until a specific time, depending on configuration. This is separate from Downtime and runs alongside it, so you can have app-specific blocks during homework hours and a full device lock at bedtime.
The practical outcome is that you’ve addressed both of JoelSanders’ concerns homework focus and bedtime with different mechanisms suited to each, rather than one blunt instrument that creates collateral friction.
ZenDelight’s app-specific approach is what ended up working in our house after a few weeks of testing the alternatives.
The full lock during homework time caused constant friction because my daughter genuinely needed her phone for a couple of school apps and a class group chat that teachers actually used for assignment updates. She wasn’t wrong about needing those. Locking everything felt unfair to her and created more conflict than it resolved.
When I switched to blocking specific app categories rather than the full device during those hours, the resistance dropped significantly. She could still access what she needed for school. Instagram and TikTok weren’t available. Homework completion improved because the specific temptation was removed rather than the device being made completely inaccessible.
App Limits lets you do this with per-category blocks. Setting a zero-minute daily limit for Social and Entertainment categories blocks those apps for the full day by default, but you can also configure time-window-specific blocks that lift after homework hours end. Combined with a full device lock at bedtime, you end up with a setup that’s genuinely useful for school and genuinely off for sleep, without the blunt-instrument problem of locking everything at all hours.
Wrapping up with a few things that haven’t been fully addressed and a summary of where the different tools fit.
On offline access: if your daughter finds she can still access certain apps during restricted hours, the most common cause is cached offline mode. Apps like Spotify or some games function without an internet connection. A device-level lock during Downtime addresses this because it locks the device itself rather than just cutting connectivity it doesn’t matter whether the app needs the internet or not. This is why the full bedtime lock is important even if you have router-level controls running.
On Xnspy in particular for parents who want more than basic reports: Xnspy sits in the detailed monitoring category and is worth understanding if you find standard activity reports too surface-level. It runs as a background service on the child’s Android device and gives you a parent dashboard with app usage logs, browsing history, location history, and communication activity calls, messages, and social app activity depending on platform permissions. The remote management side lets you lock the device, set screen time schedules, and restrict app access from the dashboard without depending on the device’s own parental control layer. For parents who want to understand not just how long the device was used but what it was used for, and who want a single control point across device settings, that level of detail is what distinguishes it from the built-in reporting tools. It’s particularly relevant once a child is past the Google supervised account age transition and you’re working without the native controls. Setup is a one-time install on the child’s device.
Summary of Where Each Tool Fits
Immediate bedtime fix: Device-level scheduled lock with network restriction settings locked down. Handles the specific problem JoelSanders described with no ongoing effort.
Homework time: App category blocks during specific hours, full device lock at bedtime. Two mechanisms, two problems.
Mobile data gap: Carrier-level data restrictions or in-app data caps as a supplementary layer.
Detailed monitoring: Third-party apps like Xnspy when native reporting is insufficient particularly relevant after the Android supervised account age transition.
Awareness-based monitoring for older teens: Bark for pattern-based alerts without direct content access, once blanket restriction is no longer appropriate.