Privacy Policy | Call Log Monitor

1. Scope of this policy

This policy applies to the Android mobile application Call Log Monitor Mobile, package com.zerodale.calllog, published by Zerodale, and to related service endpoints under calllogmonitor.com.

If app features, permissions, backend APIs, or data handling behavior change, this policy should be updated before the changed behavior is released to users.

2. Information processed by the app

Sign-in details: workspace, username, and password are sent to the server when you sign in.
Access request details: full name, phone number, username, password, and workspace are sent when you request account access.
Call metadata: the app may process phone number, call direction, start time, end time, duration, source app, and whether a call was marked as work or personal.
Phone state and call history: the app uses Android phone state and recent call log data to detect active calls and match them against recent records.
Contacts: if permission is granted, contacts access is used to support recognizable local display inside the app. The current mobile client does not upload the full contact list.
Workspace and account data: after sign-in, the app may receive and display your name, username, role, workspace display name, workspace domain, entitlement status, and access permissions.
Operational workspace data: if enabled by your organization, the app may display assigned phone numbers, descriptions, priority, follow-up status, performance metrics, and work-time tasks.
Limited diagnostics: for troubleshooting, the app may send an app-generated device ID, device brand/model, Android version, app version, wizard step, recent technical events, and short diagnostic errors.

3. What this Android build does not collect

No microphone permission No location permission No advertising ID No ad network SDK No call-audio upload in this build

The current Flutter Android client for com.zerodale.calllog does not request microphone or location permissions. This build also does not upload call audio from the mobile app.

4. Android permissions and why they are used

Permission / capability	Why it is used	Local processing	Server transfer
`READ_PHONE_STATE`	Detect active calls and phone state changes.	Yes	Indirectly through synced work-call metadata.
`READ_CALL_LOG`	Read recent calls to resolve phone number, time, direction, duration, and source app.	Yes	Yes, for calls that are synchronized as part of the work workflow.
`READ_CONTACTS`	Support recognizable contact names inside the app.	Yes	No. The current mobile client does not upload the contact list.
`POST_NOTIFICATIONS`	Show service alerts, sync status, reminders, and assignment notifications.	Yes	No, except limited technical app-state diagnostics.
`SYSTEM_ALERT_WINDOW` and `USE_FULL_SCREEN_INTENT`	Show the quick call prompt during an active call.	Yes	No, except the user-selected work/personal decision.
`REQUEST_IGNORE_BATTERY_OPTIMIZATIONS`	Help keep call monitoring alive in the background.	Yes	No
`RECEIVE_BOOT_COMPLETED`	Restart the monitor after reboot when a valid session exists.	Yes	No
`INTERNET` and `FOREGROUND_SERVICE`	Call APIs and run the Android foreground service required for monitoring.	Yes	Yes, for authentication, calls, dashboard, work time, and telemetry APIs.

5. Data sent to the server

Login: workspace, username, and password are posted to /api/auth/login.
Registration / access request: workspace, full name, phone number, username, and password are posted to /api/auth/register.
Session restore: the authentication token is used to retrieve current account and workspace status.
Call synchronization: start time, end time, phone number, direction, duration, source app, client log ID, and work/personal classification are posted to /api/callrecords/upload.
Dashboard and reporting data: the app fetches your call history, range stats, assigned numbers, target progress, and related workspace data from the API.
Work-time tracking: task ID, date, and minutes are sent to /api/worktime/entries.
Limited technical telemetry: device ID, app version, device brand/model, Android version, upload reason, wizard step, recent events, breadcrumbs, and short error summaries may be sent to /api/client-telemetry.

Phone numbers are masked in Flutter telemetry Flutter-side telemetry trims and masks phone-like values inside event data and error text before upload.

Separate on-device native debug log The app also keeps a local debug log file in internal app storage for troubleshooting. It can include call-state metadata and can be cleared from the in-app Debug Logs screen.

6. Data stored locally on the device

The authentication token is stored using Android secure storage / encrypted preferences.
Workspace and username are remembered only if the user enables the remember option.
Your password is not stored for later reuse after sign-in or registration.
Local pending call queues, sync markers, and temporary call-session state may be stored to make synchronization more reliable.
The app may also store a local telemetry queue, an app-generated device ID, appearance settings, and permission-wizard state.

7. Why we use this data

Authenticate you against the correct workspace and manage your session.
Detect active calls and match them with Android call log entries.
Synchronize work-call records for reporting, analytics, leads, and targets.
Display assigned numbers, follow-up state, total talk time, and other operational metrics.
Record work-time entries and show daily task definitions.
Keep the background monitor, notifications, and call prompts functioning reliably.
Troubleshoot crashes, permission problems, and setup failures.
Check for new app versions and direct users to a trusted update package.

8. How information is shared

We do not sell data from this app for advertising and we do not use ad-network SDKs in this client.

Your data is shared with the relevant workspace / tenant and its authorized administrators.
Data is used on the backend infrastructure that operates the services behind calllogmonitor.com.
If you use CSV export or share features, the selected data is shared with the destination app or service that you choose.
Data may also be disclosed when required by applicable law, legal process, or security obligations.

9. Retention

The current mobile client does not publish a fixed automatic server-side deletion window. Server-side retention is generally controlled by the service operator and workspace administrators based on business, subscription, audit, or legal requirements.

Device-side cached data remains until it is synchronized, cleared from the app, removed on sign-out, or deleted through Android app-data controls.

10. Security

Authentication tokens are stored using Android secure storage / encrypted preferences.
The client is configured to use https://calllogmonitor.com as the production service endpoint.
Flutter-side telemetry masks phone numbers before upload.
Runtime permissions are requested for workflow-relevant features only.
No internet-connected system can guarantee absolute security, so residual risk always exists.

11. Your choices and rights

You can deny or revoke app permissions in Android settings, but core functionality may stop working.
You can sign out and remove remembered login details.
You can clear in-app debug logs from the Debug Logs screen.
For access, correction, or deletion of workspace data, contact your workspace administrator first because most operational data is controlled at the tenant level.

12. Contact

Current app publisher in this project: Zerodale

support@calllogmonitor.com calllogmonitor.com

If your request is about workspace records, account approval, assigned numbers, or call records, your workspace administrator is usually the fastest contact path.