Zodiac Tech CRM Docs

Demo APK (UI review)

A shareable, server-free build of the Android app for reviewing the UI and checking call-recording capability on a real phone.

admin super-admin support Easy ⏱ 5 min Updated 2026-10-05

Demo APK (UI review)

Before a client commits their sales team to the app, send them the demo APK. It is a full build of the real app that runs with no server and no login, filled with bundled sample data captured from the ABC Realty demo workspace. Recipients can browse every screen and — most usefully — check what their own phone supports for call recording.

Who this is for

  • Super admins and agency staff demoing the product to a client.
  • Business admins reviewing the app before rolling it out.
  • Support staff asking a client to check a specific phone's capability.

Difficulty: Easy · Time: about 5 minutes · Prerequisites: the APK file (demo-apk/LeadHub-Demo-UI-Review.apk) shared by your operator; an Android phone.

Two ways in — and which to use

The login screen of this build has both demo entry points:

Button What it does Needs a server?
🔍 EXPLORE DEMO — NO SERVER NEEDED Opens the app with sample data already inside (offline mode) — Home, Leads, Follow-ups, Calls, WhatsApp click-to-chat, Appointments, Notifications, Device health, Settings No
TRY THE DEMO ACCOUNT Signs into the seeded demo workspace (owner@abcrealty.demo) on a real server Yes

For pure UI review, use EXPLORE DEMO. It flips the app into demo mode: an internal flag plus a stub token, with an interceptor that answers every API call from bundled fixtures — the same screens, DTO parsing and state handling as the real app, so what a reviewer sees is the real UI.

Step 1 — Install and open

  1. Send the APK to the reviewer (WhatsApp, Drive, email).
  2. They open the file and allow "install unknown apps" when prompted — same as any sideloaded APK; see Installation.
  3. Tap 🔍 EXPLORE DEMO — NO SERVER NEEDED.
  4. Mutating actions (call notes, dispositions, stage changes, follow-ups) succeed locally with the same optimistic UI as the real app. A Demo mode notice appears in Settings; LOG OUT — EXIT DEMO returns to the login screen.

Step 2 — Review checklist

Walk through each screen and confirm it works for the client's workflow:

  • [ ] Home — today's follow-ups and assigned leads render correctly.
  • [ ] Leads — list, search, open a lead, notes and stage change.
  • [ ] Follow-ups — due items, complete one.
  • [ ] Calls — call list and a call detail with disposition chips.
  • [ ] WhatsApp click-to-chat — opens the chat action.
  • [ ] Appointments and Notifications — lists render.
  • [ ] Device health — on the reviewer's own phone, read the Recording: row and the health rows (this is computed entirely from on-device Android APIs — no CRM server involved).
  • [ ] Settings — demo notice present; call-tracking settings visible.

The single most valuable demo check Ask the reviewer to open More → Device health on the phone they intend to use. The capability report tells them honestly whether that phone can record natively, can only import recordings, or is metadata-only — before anyone promises anything in a sales meeting.

Step 3 — Rebuild the demo APK (operators only)

  1. Open android/DEMO_BUILD.md — it is the source of truth for this process.
  2. Build with a JDK 17 environment: 
    cd android
./gradlew assembleRelease
cp app/build/outputs/apk/release/app-release.apk ../demo-apk/LeadHub-Demo-UI-Review.apk
  3. The release build is signed with the demo keystore (android/keystore.properties + leadhub-release.keystore, demo credentials intended for demo use only).
  4. To refresh the bundled sample data, re-capture payloads from the local server and regenerate the fixtures as described in DEMO_BUILD.md (php android/tools/gen-demo-fixtures.php), then rebuild.

Expected result

  • The reviewer navigates the full app with zero setup and zero server.
  • Their Device health reading is a real, device-computed result.
  • You have an honest answer about recording support per phone without installing anything on a real workspace.

Common mistakes

Mistake What happens Fix
Sending the demo APK but saying it is the production build Demo buttons and demo data confuse the client Explain it is a UI-review build; production installs use the operator's APK
Testing on an emulator Device capability readings are meaningless virtually Always check Device health on a real phone
Editing fixtures manually $ or """ breaks Kotlin raw strings Follow DEMO_BUILD.md and rebuild from captured payloads
Reviewer tries to log in with their own account The demo build may not point at their server Use EXPLORE DEMO, or the demo account button

Troubleshooting

  • "App not installed" — see Installation troubleshooting.
  • Demo mode won't exit — Settings → LOG OUT — EXIT DEMO.
  • Device health shows a state the reviewer doesn't understand — the copy on screen is the complete explanation; each row states exactly what it means and what to do. See Device health.

Technical details

  • Demo mode: SecureStore.demoMode + stub token, entered via AppViewModel.enterDemoMode(); ApiClient's demo interceptor serves responses from DemoFixturesGenerated while the flag is on.
  • Build/refresh instructions live in android/DEMO_BUILD.md; the built file is kept in the repo's demo-apk/ folder (git-ignored).
  • Demo workspace credentials for the server demo button are seeded by database/seeders/IndiaDemoSeeder.php.

Was this page helpful?