One Android phone, two theft detection locks, no conflict.

No, and that is the whole confusion inside this keyword. Android's Theft Detection Lock is a device-side feature on Android 10 and above that fuses accelerometer motion, Wi-Fi, and Bluetooth signals to notice a snatch-and-run, then locks the phone's screen. It protects the asset in your hand. A property manager also holds an Android phone, but the asset they are trying to protect is a mailroom, a condenser pad, a conex, a loading dock, or a parking lot — none of which have an accelerometer, and none of which get snatched. The device-side lock cannot see any of those. What a property manager actually needs is a second theft detection lock: one that watches camera tiles, fuses zone + dwell + time, and lands the event on the same Android phone via WhatsApp. Both locks are worth running. They cover different assets and they never conflict.

It lands as a single WhatsApp message in the property's ops thread. Message body: a 480 by 270 pixel tile thumbnail (cropped from the exact camera tile on the DVR mosaic), a zone label like 'mail_alcove_after_1900', a dwell counter in seconds, a timestamp inside the armed schedule, the camera name, the DVR layout id, and a latency number — typically around 5,120 milliseconds from capture to delivery. On the Android notification shade, WhatsApp renders the thumbnail as the big-picture preview and the zone label + dwell count as the collapsed text. The whole thing reads in under two seconds while the staff member is walking between units.

No, because WhatsApp holds one of the system FCM high-priority messaging slots on Android. High-priority FCM messages bypass Doze for the wake-up window, the notification posts, and the phone vibrates or rings per the user's channel settings. That is why the default delivery channel is WhatsApp rather than a custom app: building another Android app that is reliably exempt from Doze, App Standby, and manufacturer battery managers (Samsung's Device Care, Xiaomi's MIUI cleaner, OnePlus's auto-sleep) is a never-ending cat-and-mouse. WhatsApp is already whitelisted across every OEM because users would complain if it were not. Ride that rail.

No. They do not touch each other. The device-side lock runs inside Android's system services (under Settings > Google > All services > Theft protection on Android 10+) and only fires on sensor readings from the phone itself. The property-side lock runs on a Cyrano edge unit sitting next to the property's DVR, detects on the DVR's HDMI multiview output, and delivers through WhatsApp. Nothing on the phone makes an inference. Nothing on the edge unit touches the phone's accelerometer. One phone can carry both alerts without interference.

Three reasons, all of them operational. First, a dedicated app adds a second place a property manager has to open, and the manager already lives inside WhatsApp (vendors, residents, maintenance, staff are all there). Second, a dedicated app needs to hold background priority across every OEM's power-saver scheme, and getting whitelisted on Samsung, Xiaomi, OPPO, Vivo, and Huawei is a constantly moving target that an infrastructure vendor should not be fighting. Third, the alert has to read in two seconds. A WhatsApp message with a tile thumbnail and a one-line caption reads faster than any app's notification, lockscreen widget, or in-app feed. If the property wants a dashboard too, that is fine, but the default channel is the one that gets read, and on Android that is WhatsApp.

No, and this is where most of the confusion in this keyword comes from. Android's Theft Detection Lock runs inference on the phone (that is the whole point, the phone is both the asset and the sensor). The property-side lock is the opposite: inference runs on a Cyrano edge unit next to the DVR, not on the phone. The phone is the delivery endpoint only. That separation is what lets the pipeline watch 16 to 25 camera tiles in parallel at full framerate without melting a phone battery, and it is also what lets the alert survive even when the staff Android phone is asleep on a desk.

Three signals have to agree on the same subject on the same tile in the same second. One: a person enters a drawn polygon on a specific camera tile (for example, the package shelf area on camera 4 of a 4x4 DVR mosaic). Two: their dwell time inside the polygon crosses a per-zone threshold, usually 10 to 20 seconds, which filters residents walking through. Three: the current timestamp is inside that zone's armed schedule (for example, 19:00 to 06:00 for a mailroom after hours). All three filters agreeing is rare (a handful of events per day per property). Any one filter alone is noise (hundreds per day).

Any Android version that runs WhatsApp, which is Android 5.1 and higher at the time of writing. This is important because the device-side Theft Detection Lock requires Android 10+, and some property portfolios still issue staff phones on older Android versions with long OEM update tails. Staff on Android 6 or 7 cannot enable the device-side lock, but they can receive every property-side lock event the same way as someone on Android 15. The two locks do not have the same version floor.

A smart camera app typically pushes a notification every time any camera detects motion. That is one signal. Three hundred raw motion events per day at a 16-camera property get muted inside a week because the ratio of signal to noise is wrong. The property-side lock described here runs three independent filters (zone, dwell, time) that all have to agree before anything gets shipped to the Android notification tray. A typical 16-camera apartment property sees roughly 200 raw person detections per day and delivers 3 to 8 alerts after the three filters. That 50 to 1 reduction is the difference between a channel that stays in service and one that gets silenced.

The incoming WhatsApp notification still posts to the lockscreen. The thumbnail is visible if the user has allowed sensitive notifications on the lockscreen; otherwise the collapsed text (zone label + dwell seconds + timestamp) posts and the thumbnail is hidden until unlock. Either way, the staff member hears the alert and can act. The device lock does not block incoming notifications; it blocks outbound data access from the locked phone. That is the whole point of the two locks being independent: a locked personal device still functions as a property alert endpoint.