The call button was the smallest part of the problem
A dealership phone can have two active SIMs, more than one calling account, carrier-specific controls, a matched contact, a waiting call, and a recent-call entry that needs to remember which line handled the conversation. A generic call button can start dialing while hiding every decision that matters immediately before and after it.
LP Phone moved toward Android’s default-dialer role because Android Telecom owns the real call lifecycle. A browser cannot honestly imitate ringing, active, held, disconnected, audio-route, and multi-call states. The app has to qualify for the system role, subscribe to the states the device provides, and render only controls Android and the carrier can actually perform.
Role qualification is a product dependency
Android does not grant default-dialer behavior because an app draws a convincing call screen. Its manifest, services, intents, permissions, and in-call declarations must satisfy the current platform’s role rules. During the build, an attempted car-mode declaration made the app ineligible on a current Android device. Removing the prohibited capability restored the qualification path.
That failure changed how the feature is described. Platform eligibility must be verified on the target OS; it cannot be inferred from an older emulator or from permissions appearing in settings. LP Phone should ask for the narrow role it needs, explain why, and remain clear about what is unavailable until Android confirms that role.
Capture the line before Telecom removes it
Disconnect is not simply a final status event. By the time Android removes the call object, account and subscription details may no longer be readable. If LP Phone waits until cleanup to create a recent entry or callback action, it can lose the fact that SIM 2, not SIM 1, handled the conversation.
The call layer therefore snapshots the relevant account and subscription identity before Telecom removal. Recents can then explain the line used, and a later callback can prefer that prior line when Android permits it. When the device exposes multiple valid accounts or cannot honor the preference, the user still needs a visible choice rather than a silent fallback.
- Preserve account and subscription identity before removal
- Keep the used line visible in recent-call context
- Prefer prior-line continuity only when Android allows it
- Let the user resolve ambiguity on multi-SIM devices
The call screen follows state, not a scripted animation
Incoming, outgoing, active, held, waiting, and disconnected calls do not all need the same controls. The full-screen overlay responds to the current Telecom state and keeps the primary actions stable: answer on the left when a call can be answered, and hang up on the right when a call can be ended. Contact and line context remain visible without crowding the action area.
Merge, hold, mute, speaker, Bluetooth, and route choices appear only when the device reports support. That restraint prevents the interface from promising an action the carrier rejects. It also means two Android phones can legitimately show different controls for the same apparent call scenario.
Hang-up begins a short second workflow
The useful dealership moment is often immediately after the call, while the employee still remembers the commitment. LP Phone can hold a compact post-call panel long enough to expose the supported next action: return to the paired LotPro context, review a recent entry, or continue a locally available workflow. It then dismisses so the phone does not remain trapped in a completed call.
The action policy takes its input from the ended call and current pairing state. It does not assume every call originated in LotPro, and it does not treat an unknown incoming number as an existing customer record. Capturing a next step should preserve context without manufacturing a CRM identity from call history.
Private preview means device-by-device evidence
LP Phone is an Android 10+ private preview. Call waiting, merging, audio routes, SIM selection, Bluetooth behavior, background restrictions, and role qualification vary by phone, carrier, Android version, and granted permissions. The static implementation and targeted device repairs do not establish universal handset coverage.
Always-on remote relay behavior is outside the current public claim and can remain disabled for cost containment. Phone Control availability is confirmed during rollout, along with the supported pairing and local network behavior. Rollout validation should record the exact device, OS, carrier, SIM configuration, and call scenarios tested before that environment is described as supported.