The code behind the permission prompts.

Feature capability map

Every remote-control action XimosKid supports, exactly what it does on the child device, and which billing bucket it draws from. This is the complete list of 13 shipped features — nothing here is simplified for marketing, and nothing is left out because it's less flattering.

Camera cast — Smart Zoom & Smart Focus

Camera casting is more than a passthrough video feed. The parent viewer gets two interactive camera controls — Smart Zoom and Smart Focus — that both read the actual camera capability of the child device rather than assuming a fixed limit.

Smart Zoom system

• • 6-step percentage slider — 0%, 20%, 40%, 60%, 80%, 100%. Designed for intuitive use on any device.
• • Per-device capability detection — the parent app reads CONTROL_ZOOM_RATIO_RANGE and SCALER_AVAILABLE_MAX_DIGITAL_ZOOM at runtime instead of hardcoding a max, so each phone's actual zoom range is honored.
• • Exponential mapping — matches human perception of zoom. A 20% step is a natural increment, not a jarring jump.
• • Dual-API support — Android 11+ uses CONTROL_ZOOM_RATIO (hardware zoom). Android 10 and below uses SCALER_CROP_REGION (digital crop). Both paths are handled transparently.
• • Auto re-detect on camera flip — front and rear cameras may have different max zoom, so the capability is re-read when the parent flips cameras mid-session.
• • 1.5-second capability cache — smooth performance without sacrificing accuracy. A zoomAck message tells the viewer when zoom was clamped to the device max.

Smart Focus system

• • Tap-to-focus — tapping anywhere on the video focuses on that exact point on the child device. Orientation-aware (sensor 90°/270° handled), with a proportional focus box sized to the sensor (minimum 60px).
• • Soft focus lock — long-press triggers a lock that freezes autofocus at the current converged position. The UI shows honest labels: 🔒 LOCKED for a real hardware lock, 🔓 HOLD for a soft lock.
• • Auto-unlock on next tap — no stuck-focus states.
• • Graceful fallback — devices with fixed-focus cameras skip lock entirely rather than showing a broken control.
• • Capability detection — CONTROL_AF_AVAILABLE_MODES, CONTROL_MAX_REGIONS_AF, and AF trigger support are all pushed to the viewer when the channel opens.

WebRTC Data Channel — low-latency commands

All interactive camera commands — zoom, focus, focus lock/unlock, reset, capability queries — travel over a P2P WebRTC data channel named control rather than through Firebase. Latency is 50–150 ms vs. Firebase's 300–500 ms, which makes the whole experience feel native. Delivery is ordered and reliable, and the protocol is JSON-based and bidirectional so it can be extended without breaking changes.

Surrounding Audio Listening — internals

Surrounding Audio is a standalone one-way live audio streaming feature — it is not the two-way audio that travels inside the Camera Cast stream. It runs on its own WebRTC media channel and can be started independently of any camera or screen session. It turns the kid device into a remote microphone the parent can listen through.

Transport & codec

• • Channel type: WebRTC media channel, not a voice call
• • Sample rate: 48 kHz full-band
• • Codec: Opus, adaptive bitrate
• • Latency: ~100–200 ms end-to-end
• • Routing: STREAM_MUSIC on both sides — bypasses voice-call DSP for clean playback

5-tier adaptive bitrate

Quality is re-evaluated every 2 seconds and the badge in the UI updates live — for example, "HIGH · 64 kbps" → "MEDIUM · 32 kbps".

Audio pipeline

Session behavior & user controls

• • One-tap start; live status chip — Connecting → Listening → Reconnecting
• • Session timer in MM:SS; heartbeat every 10 seconds; automatic ICE restart within ~3 s on disconnect
• • Remote stop from the listener side; billing auto-charged per second
• • Mute toggle — remoteAudioTrack.setEnabled(false); stream continues, playback silences
• • Volume Boost toggle — non-destructive, sets 85% of max, saves the previous volume, restores on untoggle
• • Earbud / Bluetooth auto-routing — routes to wired or BT headset when connected; re-routes on plug/unplug; prioritizes external devices over speaker; requests audio focus to pause other apps during the session

UI

Three concentric pulse rings around the mic icon (2000–2800 ms cycles, escalating opacity). A live PCM-driven waveform (triple-layer sine, Violet → Cyan gradient) with fast attack (0.40x) and slow release (0.06x) so it reacts to real audio energy rather than a canned animation. Quality badge (e.g., "HIGH · 64 kbps") updates live. Auto-responsive layout from small phones through tablets.

Location Tracking — internals

Remote live location tracking, parent-triggered only. When the parent taps refresh in the Ximos app or web dashboard, the kid device enters a multi-stage location flow. There is no continuous background collection — location is fetched only on parent trigger.

GPS auto-enable via Accessibility Service

If GPS is off, the child device shows the standard Android location-enable dialog. The XimosKid Accessibility Service auto-clicks the accept button using a three-layer strategy:

1. Direct text match on the accessibility tree (fastest)
2. Deep manual tree walk when text matching misses
3. Heuristic fallback on the positive dialog button

Supported dialog texts include English ("Turn on", "Agree", "Allow"), Bengali ("চালু করুন", "অনুমতি দিন"), Hindi ("चालू करें", "अनुमति दें"), and other supported languages.

Multi-stage fetch

Two stages run in parallel so the parent gets an answer as fast as possible:

• • Stage 1 — last-known cached location uploaded immediately (may be slightly stale)
• • Stage 2 — fresh high-accuracy GPS fix requested in parallel

Both are sent to the server, which uses the freshest timestamp.

Fallback chain

If GPS is unavailable, the tracker degrades gracefully through multiple sources in priority order:

Each uploaded location is tagged with its provider and an isFallback boolean so the parent app can visually indicate how reliable the data is (accurate marker vs. approximate marker).

Delivery

Location data is relayed from the XimosKid device to the connected parent over the same encrypted Cloudflare Workers WebSocket used for stream signaling and usage data, using a Durable Object room keyed to uid + deviceKey for strict multi-tenant isolation. The parent app listens on a single WebSocket and distinguishes location payloads by type: "accurate_location". Location payloads are not retained server-side beyond the in-flight relay.

Parent app map

• • Free OpenStreetMap-based map with three switchable styles: Street (Esri World Street), Satellite (Esri World Imagery), OSM (classic OpenStreetMap)
• • No Google Maps API key required — the whole map stack is free
• • Overlay panel shows latitude, longitude, accuracy, provider, and last-update timestamp
• • Custom marker with a multi-line info window
• • One-tap "Open in Google Maps" button (falls back to the browser version if Google Maps isn't installed)
• • Most recent location cached in SharedPreferences so the map paints instantly on open and works offline

Trigger order

The parent app establishes the WebSocket connection first; only on onOpen does it write the get_location command to Firebase. This ensures the listener is already listening when the kid device uploads, so no broadcast is missed.

Usage monitoring, in full

The Usages Report screen in the parent dashboard shows exactly this, and nothing more:

Permission request flow

Every dangerous permission goes through the same three-step gate before the Android system dialog even appears. This is the same flow for all sensitive permissions XimosKid requests.

Disclosure text, per permission

This is the literal string shown to the user for each permission type, straight from BackgroundService.showPermissionDisclosure().

// exact disclosure copy shown before each system permission dialog
case TYPE_CAMERA:
  details = "• Camera Access: Enables parents to perform live camera streaming or capture environmental photos during active safety monitoring sessions to ensure child physical security.";

case TYPE_AUDIO:
  details = "• Microphone Access: Allows parents to listen to ambient audio during real-time emergency or monitoring sessions for immediate safety verification.";

case TYPE_OVERLAY:
  details = "• Display Over Other Apps: Allows the app to display critical parental alerts, screen time limits, and safety warnings directly over other active applications.";

case TYPE_BATTERY:
  details = "• Battery Optimization Exclusion: Keeps background safety services, real-time sync, and emergency 
             alerts active continuously, even when the device enters sleep mode.";

case TYPE_ACCESSIBILITY:
  details = "• Accessibility Service: Used exclusively for parental control features to support remote device management,
            app restriction, and safety session execution. Ximos does NOT use this service to alter
            system settings without authorization or collect private personal data.";

case TYPE_STORAGE:
  details = "• Usage Access: Required to monitor app usage and track the child's behavior,
             including which apps are used and how much time is spent on them.";

case TYPE_INSTALL:
  details = "• Install Packages: Used strictly to update internal security modules and child safety components to the latest protected version.";

case TYPE_ADMIN:
  details = "• Device Admin Permission: Used to support parental control features by helping
             prevent children from removing the app without parental awareness. This
             ensures that app settings and protections remain active unless a parent
             explicitly allows changes. The app does not lock the device or erase any data.";
             
             
tvDetails.setText(details);
if (!isAvailable.equals("1p0p")) {
  new CountDownTimer(1000, 1000) {
    @Override
    public void onTick(long millis) {
      int sec = (int) (millis / 1000);
      btnGrant.setText("Grant (" + sec + ")");
      btnGrant.setEnabled(false);
      btnGrant.setAlpha(0.5f);
    }

    @Override
    public void onFinish() {
      btnGrant.setText("Grant Permission");
      btnGrant.setEnabled(true);
      btnGrant.setAlpha(1.0f);
      tvCountdownInfo.setText("Please review and proceed.");
    }
  }.start();
} else {
  btnGrant.setText("Grant Permission");
  btnGrant.setEnabled(true);
  btnGrant.setAlpha(1.0f);
  tvCountdownInfo.setText("Please review and proceed.");
}

btnDeny.setOnClickListener(v -> dialog.dismiss());

btn_unlock_settings.setOnClickListener(
  v -> openAppListSettings(this)
);            
             

Requesting the permission

After disclosure and the countdown, each permission type routes to the standard Android API for that permission — nothing custom, nothing hidden.

private void executeActualPermissionRequest(int type) {
  switch (type) {
    case TYPE_CAMERA:
      ActivityCompat.requestPermissions(this,
        new String[]{Manifest.permission.CAMERA}, 101);
      break;

    case TYPE_AUDIO:
      ActivityCompat.requestPermissions(this,
        new String[]{Manifest.permission.RECORD_AUDIO}, 102);
      break;

    case TYPE_LOCATION:
      // requested only when a parent triggers a location fetch
      ActivityCompat.requestPermissions(this,
        new String[]{
          Manifest.permission.ACCESS_FINE_LOCATION,
          Manifest.permission.ACCESS_COARSE_LOCATION
        }, 103);
      break;

    case TYPE_ACCESSIBILITY:
      Intent intentAcc = new Intent(Settings.ACTION_ACCESSIBILITY_SETTINGS);
      startActivity(intentAcc);
      break;

    case TYPE_STORAGE:
      UsageStatsManager usageStatsManager =
        (UsageStatsManager) getSystemService(Context.USAGE_STATS_SERVICE);
      long endTime = System.currentTimeMillis();
      long startTime = endTime - 1000 * 60 * 60 * 24;
      if (usageStatsManager.queryUsageStats(
            UsageStatsManager.INTERVAL_DAILY, startTime, endTime).isEmpty()) {
        Intent intent = new Intent(Settings.ACTION_USAGE_ACCESS_SETTINGS);
        startActivity(intent);
      }
      break;

    case TYPE_ADMIN:
      DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
      ComponentName adminComponent = new ComponentName(this, XimosAdminReceiver.class);
      if (!dpm.isAdminActive(adminComponent)) {
        Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);
        intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, adminComponent);
        intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
          "This permission helps protect parental control settings from being removed
           without parental approval.");
        startActivity(intent);
      }
      break;
  }
}

Full file: github.com/ximexa/ximos-offical-releases

How a stream session starts and stops

Every stream type (camera, screen, recording, surrounding audio) listens on a single Firebase Realtime Database flag. Turning it off from either side tears the session down immediately — there's no separate "force stop" path an attacker could bypass.

// simplified from BackgroundService — screen cast listener
Boolean isScreenCast = snapshot.getValue(Boolean.class);
if (!Boolean.TRUE.equals(isScreenCast)) {
  safeHandler.removeCallbacksAndMessages(null);
  AdminMonitor.getInstance().stopMonitoring();
  stopAllActiveServices();  // same teardown path for every feature
  return;
}

// debounce guards against rapid duplicate Firebase events
long currentTime = System.currentTimeMillis();
if (currentTime - lastScreenCastStateTime < DEBOUNCE_TIME) { return; }
lastScreenCastStateTime = currentTime;

// overlay permission is re-checked at session start, every time —
// not cached from a previous grant
if (!Settings.canDrawOverlays(getApplicationContext())) {
  dbRef.child("isScreenCast").setValue(false);
  dbRef.child("action").setValue("missing_permission_overlay");
  return;
}

// cooldown prevents rapid session re-triggering / command flooding
long now = System.currentTimeMillis();
if (now - lastMediaCommandTime < MEDIA_COMMAND_COOLDOWN) {
  dbRef.child("action").setValue("Cooling..");
  safeHandler.postDelayed(() -> dbRef.child("action").setValue("idle"), 3500);
  return;
}
lastMediaCommandTime = now;
stopAllActiveServices();  // only one stream type runs at a time

Accessibility service scope

The Accessibility Service is the permission most worth being precise about, since it's powerful by design. In XimosKid it backs exactly three behaviors:

All three behaviors are scoped to MyAccessibilityService and are only exercised while a screen-cast session is active or during a parent-triggered location fetch — not continuously, and not to read content from unrelated apps in the background.

Connection & presence handling

XimosKid tracks whether the parent is actually connected, and reacts if that connection drops mid-session — this prevents a stream from being left silently running if the parent's app crashes or loses network.

// admin (parent) session-state listener
if ("offline".equals(state)) {
  if (sessionStateRef != null) {
    sessionStateRef.setValue("disconnected");
  }
  stopAllActiveServices();  // no session survives an offline parent
  safeHandler.postDelayed(() -> { if (!isRefreshing) stopSelf(); }, 1000);
}

// Firebase's own ".info/connected" hook — fires on any network change
if (connected) {
  userRef.child("sessionState").onDisconnect().setValue("disconnected");
  userRef.child("last_active").onDisconnect().setValue(ServerValue.TIMESTAMP);
  userRef.child("sessionState").setValue("connected");
}

The onDisconnect() hooks are registered with Firebase itself, so the "disconnected" state gets written even if the child device loses network ungracefully — it doesn't rely on a clean app shutdown to happen.

API security

Every request to an endpoint like /device/{id}, /camera/{id}, or /relay/location answers one question server-side: is this parent actually the authorized guardian of this device? That check is layered, not single-factor:

Location relay requests additionally verify the Firebase ID token server-side using Google's public JWKS before allowing any Durable Object broadcast — the same treatment as the signaling path.

Endpoint map

A representative view of how endpoints are namespaced — every one below requires the full authentication stack above, not just a valid login token.

Web dashboard security headers

Content-Security-Policy:   restricts script/style/frame sources
Strict-Transport-Security: forces HTTPS on every future request
X-Content-Type-Options:    nosniff
Referrer-Policy:           strict-origin-when-cross-origin
Permissions-Policy:        disables unused browser APIs
Frame-Ancestors:           'none' — blocks clickjacking via iframe

Key dependencies

Full SBOM and dependency vulnerability scanning results are tracked alongside each release on GitHub.

Changelog

App UI Guide

A complete screen-by-screen reference for the XimosKid child app — every button label, dialog text, permission flow, and setup step with exact wording, written for both users and AI assistants.