Q. Does the screen takeover (overlay) permission need to be manually granted by the user?
Yes. The screen takeover/overlay permission must be granted by the user.
-
The overlay (pop-up, screen-takeover) permission is requested when the user opens the app for the first time.
-
The notification permission (the push note that shows up in the tray) does not need to be granted by the user.
The app must be opened at least once so that:
-
The overlay permission can be requested and granted.
-
The app can retrieve the Institution ID from Google Admin (MDM).
-
The first check-in can occur.
After that first check-in, the app will run as expected, including on reboot (subject to your deployment/configuration in Google Admin).
Q. When will Chromebooks appear in the Portal?
Once deployed, a Chromebook will appear in the Portal after:
-
The user has opened the app at least once.
-
The overlay permission has been requested (and, ideally, granted).
-
The first check-in has completed and the Institution ID has been retrieved from Google Admin MDM.
If the Google Admin configuration is correct, the device should show up in the Portal after that first successful check-in. It is not dependent on ongoing user interaction after that initial open/permission step.
Q: How does Wi-Fi scanning work?
-
The Chromebook scans for nearby Wi-Fi access points about every 60 minutes.
-
It automatically selects the strongest signal as the device’s current access point (BSSID).
-
If that BSSID matches an entry in your institution’s data, the correct Security Zone is applied.
-
If it doesn’t match, the SecurityZoneId remains null until a new BSSID is recognized.
-
-
When the device encounters a new BSSID (e.g., moves to a different AP/area), the app does a background check-in.
-
If it stays on the same BSSID, it won’t re-check-in—so the dashboard might show an older “last check-in” even though the app is active and listening for messages.
Q: What if the device hasn’t checked in for a while?
A device might appear inactive in reporting if it hasn’t encountered a new access point recently.
This doesn’t mean it’s offline — it just hasn’t detected a new BSSID to trigger an update.
The Chromebook only “checks in” when it moves to a new Wi-Fi access point, not while it’s sitting on the same one.
Q. What happens if a Chromebook is panic-enabled but no incident types are configured for the institution?
Q. Do Chromebooks need to be on a whitelisted SSID to successfully activate a panic?
No. Chromebooks do not have to be on a specific “whitelisted SSID” to activate a panic.
When a panic is activated, EducationShield Chrome sends the BSSID (the unique identifier for the access point) through the pipeline. The system then checks that BSSID against the institution’s configured locations.
-
If the BSSID matches a configured location, the panic is processed and routed using that location data.
-
If the BSSID does not match any configured location, the panic still goes through, but location details may be limited or fall back to the default behavior configured for the institution.
Q. How does the EducationShield Chromebook app use BSSID information?
The Chromebook’s Wi-Fi scanning process happens about every 60 minutes and detects multiple access points.The strongest signal is always used for the device’s current BSSID.
If panic is enabled for the device, the user can activate a panic from the app whether or not the device is connected to a known access point. If a panic alert is sent while the SecurityZoneId is null, the panic pipeline assigns the alert to the top-level zone of the institution.
-
If that BSSID matches an entry in your institution’s data, the correct Security Zone is applied.
-
If it doesn’t match, the SecurityZoneId remains null until a new BSSID is recognized.