Calls & recording issues#

Calls are missing from the CRM, or recordings are missing from the calls that did arrive. The Android app is capability-first: it reports what the phone can actually do (some devices simply cannot record calls) and never fakes a recording. So the fix usually starts with reading the phone's own capability state, then the phone's permissions, then the CRM.

Who this is for: agents who use the dialer, and admins supporting them.

Problem#

After a phone call you expect a call record in the CRM, a recording (or a recording link), and the call mapped to the right lead. One or more of those is missing.

What you see#

Likely causes#

• The phone cannot record. Android 10+ and many OEMs block call recording entirely; some allow it only with a specific dialer/SIM. This is a device fact, not a CRM bug.
• Play-distributed build limitations: call-log access (READ_CALL_LOG) is a restricted permission — the Play build cannot use it the way a sideloaded build may, so call-log scanning is limited.
• Permissions not granted: phone/SIM/call-log permissions, plus notification permission on Android 13+ (miss it and background work is quietly degraded).
• Battery optimisation killed or throttled the background call-log scan (it runs roughly every 15 minutes).
• Call tracking settings wrong: Monitored SIMs not set, or the recordings folder not pointed at where the phone actually writes files (Settings → Call tracking: Monitored SIMs, Additional recordings folder, Excluded numbers).
• The number is excluded — excluded numbers produce no tracked call by design.
• Retention purge removed the audio: leadhub:purge-recordings (daily, 03:15) deletes recording files and marks the rows expired, while keeping the call metadata.

Quick fix#

1. Open More → Device health on the phone. Read three things: the recording capability mode, the tracking level, and which rows are not "Registered".
2. Grant whatever is denied, then set the app's battery usage to Allow unrestricted (the Device Health battery row names the exact setting on that device).
3. In Settings → Call tracking, check Monitored SIMs (the right SIM is on), the Additional recordings folder (points at where the phone saves recordings), and Excluded numbers (the number is not excluded).
4. Place a real test call and check Sync queue ("N waiting · N retrying") — then Sync now.

Step-by-step fix#

1. Establish what the phone supports. The app classifies the device: NATIVE_RECORDING (the app can record), IMPORTABLE_RECORDING (a recorder writes files the app can import), METADATA_ONLY (call data only — no audio), UNKNOWN (capability not yet probed). METADATA_ONLY on a device that supposedly records usually means permissions or an unavailable recorder — recheck permissions and the recordings folder. Some devices will stay METADATA_ONLY no matter what; that is the honest answer, not a bug.
2. Tracking level LIMITED is the expected outcome on many modern devices — the app reports how much of the call lifecycle it can see rather than pretending. Limited tracking can still deliver call records; it may miss fine detail.
3. Fix permissions. Missing phone-account/SIM access breaks SIM attribution; missing call-log access breaks call detection. On Android 13+, the notification permission is also required — without it, background scanning and sync degrade.
4. Battery. Set the app to Allow unrestricted. On aggressive OEM skins (Xiaomi, Oppo, Vivo, Samsung), also allow autostart/background activity if the device offers it.
5. Call tracking settings. Monitored SIMs: only monitored SIMs produce calls. Additional recordings folder: without the correct folder, IMPORTABLE_RECORDING devices cannot find files. Excluded numbers: calls to/from these are ignored by design.
6. Background scan and sync. Call logs are scanned roughly every 15 minutes; results enter the offline queue (Room) and sync with retry/backoff, so a call can legitimately take a few minutes to appear. Force it with Sync now on the Sync queue page; use Retry failed for stuck items.
7. Check the CRM record. A call record with no audio on a METADATA_ONLY device is correct behavior; on a recording-capable device, the recording arrives as an upload after sync — allow extra time on slow connections.
8. Old audio missing? Check the retention window before assuming data loss — the nightly purge deletes only audio, marks rows expired and nulls the stored path, keeping the call history intact. See Data retention & privacy (GDPR).

Admin fix#

• There is no server-side switch that turns recording on for a device — capability is determined on the phone. An admin's job is to read Device Health with the agent, fix permissions/settings with them, and set expectations.
• Check the agent's calls appear under the right lead: call records link to leads; open the lead's timeline. Deep links (crm://lead/{id}) in notifications jump straight to the record.
• If a specific agent's calls never arrive while others work, compare their Device Health rows — the difference is usually a permission or battery setting on that one phone.

Developer fix#

• Recording modes (NATIVE_RECORDING, IMPORTABLE_RECORDING, METADATA_ONLY, UNKNOWN) and tracking levels (FULL, LIMITED) come from device capability probes; UNAVAILABLE is deliberately not used for tracking.
• Call-log background scan cadence: ~15 minutes; offline queue is Room-backed; uploads retry via WorkManager with backoff and are idempotent (a retried upload does not duplicate the call).
• The Play-store build's READ_CALL_LOG restriction explains call-log limitations on distributed builds — do not chase parity with sideloaded builds.
• Recording retention: leadhub:purge-recordings {--dry} — audio deleted, row status = expired, path nulled, metadata kept.

Logs to check#

• Device Health screen on the phone (first stop, always) and the Sync queue page's counts.
• The agent's call list in the CRM and the lead timeline.
• Server side: storage/logs/laravel.log for mobile upload errors; Super Admin → Android App → Devices for the device registration.

When to escalate#

• Calls syncing from one phone but never from an identical model on the same OS — capture both Device Health screens for the developer.
• Recordings uploading but unreadable/corrupt — preserve the original file on the phone before uninstalling anything.
• A retention purge seems to have deleted audio it should have kept — freeze the setting change, collect dates, and escalate to the super admin before running any purge manually.

Related guides#

• Mobile not syncing / push not arriving
• How a phone call becomes a CRM record
• Recording capability
• Device health