Privacy Policy for Call Guard

Last updated: 11 October 2026

Call Guard is developed by Dzmitry Lukashanets. This policy explains how the Android app handles information, including usage analytics, crash reporting and external services you may choose to use. For privacy questions, contact dmlukas@gmail.com.

Contacts and call screening

Call Guard helps block incoming calls from visible numbers that are not in your contacts. It needs Android Contacts permission and selection as your call-screening app. It queries the device's contacts provider locally to check the incoming phone number. A number found in your contacts is allowed before the optional region filter is considered. The app does not upload your address book or screening numbers to the developer or an app-operated server.

By default, Call Guard blocks numbers outside your contacts. If you enable Block only selected regions, it instead blocks numbers outside your contacts only when they resolve to a selected numbering country or territory. Resolution uses libphonenumber metadata bundled in the app, without sending numbers to a remote lookup service. It accepts only complete international numbers beginning with + that resolve unambiguously; unresolved, malformed, local-format or non-geographical numbers are allowed in this mode. A numbering region does not identify the caller's physical location or prove that a number is authentic. Call Guard does not use your location, SIM country or mobile network to determine the numbering region.

Screening depends on the call details Android supplies. Call Guard does not guarantee filtering of hidden or unavailable numbers. If Android supplies a screening callback with no number, the app requests a block without saving a numbered history entry. For a visible number, missing contacts permission, unavailable contact lookup, a lookup timeout, or unavailable blocking settings causes the app to allow the call. Settings-read or region-resolution errors also allow the call. Android and device manufacturers control final call handling.

Call Guard does not request permission to read Android's system call log. Its call-screening service is protected by Android's call-screening service binding permission and uses the role you grant. The app's blocked-call history is separate from Android's system call log, which may still contain blocked calls.

Local history and preferences

After submitting a block decision for a numbered call, Call Guard makes a best-effort local record of its phone number and call time. A record is not proof that Android accepted the block. The app keeps at most 100 records and removes older records as new records arrive. Repeated calls remain separate records. Optional grouping combines them for display only, and local history search filters what you see on the device; neither sends a search query to an external service nor changes stored records. You can delete selected records or clear all app history from the history screen. These controls do not delete contacts or Android's system call history.

The app also keeps local preferences recording whether it previously requested Contacts permission, observed enabled-protection use, review-attempt timing, history grouping, blocking mode, selected region identifiers, protection-pause state and your usage-analytics choice. Local analytics preferences also keep setup and readiness markers used to coordinate collection. These local stores are not uploaded as a database or preference file. When usage analytics is enabled, the app sends limited events about setup, readiness and settings actions as described below; it does not send selected region identifiers or private history records. Region names and region-picker search are processed locally using Android locale resources and bundled names and numbering metadata. The Settings version is read from the installed app package.

History and preferences are kept in the app's private device storage. Clearing the app's data or uninstalling it removes its local stores through Android. Call Guard configures exclusions from Android cloud backup and device transfer. These settings do not guarantee the behavior of every device manufacturer's backup or transfer implementation.

Actions on a history number

Search on Google opens an external browser with the selected phone number as the Google search query. Call Guard removes whitespace, parentheses and hyphens from that query and does not attach other history rows, call times or contacts. This explicit web search is separate from local history search. The browser and Google receive and process the request under their own privacy practices; Google may also process search activity and connection information such as your IP address according to your settings and its Privacy Policy.

Copy number places the original selected number in Android's clipboard. Android and apps permitted to access clipboard data control subsequent access. Clipboard content is not private to Call Guard.

Add to contacts passes the original selected number to an external Android contacts editor. You choose whether to save it. The selected contacts provider or account may synchronize a saved contact according to its own settings and privacy practices. Call Guard does not upload your address book, and adding a contact does not erase the corresponding app history or repeated records.

Google Play reviews

Call Guard uses Google's Play In-App Review library and may offer an optional review after use. Google Play controls whether its review interface appears. If you enter a rating or review, Google Play processes that user-entered information to post the review. Google's documentation describes encrypted data, public Play Store reviews or private feedback to the developer for closed testing, and deletion through your Play Store or Google Account. The developer may see information you submit through Play. Call Guard does not attach its contacts or private blocked-call history to the review request.

Google Play's terms and privacy practices govern its service. See Google's In-App Review data safety information: https://developer.android.com/guide/playcore/in-app-review#data-safety and Google's Privacy Policy: https://policies.google.com/privacy.

Sharing, policy links and support

Share app opens Android's sharing interface with a localized description of Call Guard and its public Play Store link. It does not include contacts, call history or diagnostics. You choose the receiving app and whether to share; that app's privacy practices apply.

The Privacy policy action opens an external browser without attaching contacts, call history or diagnostics. This policy is hosted at https://dluk18b3.github.io/call-guard/privacy/ on GitHub Pages. GitHub and your browser may process the visit, including connection and request information; their privacy practices apply. See GitHub's Privacy Statement.

Contact support opens your email app with only dmlukas@gmail.com prefilled. Call Guard does not add a subject, message, attachments, contacts, call history or diagnostics and does not send the email. If you decide to send an email, the developer receives your sender address and the content or attachments you choose to include. Your email provider and the developer's email provider handle that communication. The developer uses information you voluntarily send to respond to and investigate your request. Avoid sending unnecessary personal information; contact the address above to request deletion of correspondence, subject to any retention required by law.

Usage analytics

Starting with release 3.3, Call Guard uses Google Analytics for Firebase to understand app use, setup completion, return visits and feature adoption, and to improve the app. Usage analytics is enabled by default unless you turn it off. No separate consent dialog is shown. You can change this choice at Settings → Privacy → Usage analytics; call screening and local history remain available when analytics is off.

When enabled, the app sends events about foreground visits, screens viewed, permission and call-screening setup, protection readiness and whether protection is paused. It also sends limited events about opening history search, copying a number, opening the contacts editor, deleting history, changing grouping or regional blocking, selecting or deselecting a region, pausing or resuming protection, and opening sharing, privacy-policy or support actions. Parameters describe the action, screen and outcome, such as a granted permission, a saved setting or a failed operation. Analytics does not record individual incoming calls or blocking decisions.

These custom events do not include phone numbers or their hashes, contact names or address-book contents, blocked-call records or call times, database record identifiers, clipboard contents, search text, selected country or region identifiers, selection counts, email contents or other free text. A copy or contact-editor event records that an action occurred and its outcome, not the number involved. The app does not set a custom user ID or send a name, email address or account ID to Analytics.

The Analytics SDK also handles automatic app and session events and technical information such as app version, operating system, device characteristics and an app-instance identifier used to associate events from the same installation. Google documents approximate location derived from masked IP addresses; this is separate from local numbering-region resolution and does not use GPS permission. These identifiers mean that analytics data should not be understood as completely anonymous. Call Guard disables advertising-ID collection and sets advertising storage, advertising user data and advertising personalization to denied in its Analytics integration. The app has no advertising or app-operated user account.

Turning usage analytics off stops new usage events from the app and requests that the SDK disable collection and reset local analytics data. SDK processing is asynchronous: work already handed to the SDK cannot be recalled, and an abrupt process termination can delay reconciliation of the saved choice until the app returns to the foreground. Turning analytics off does not delete data already received by Google. Re-enabling analytics can start a new analytics identity; reinstalling or clearing app data can also change identifiers.

The developer can access analytics reports and may analyze exported event data using Google BigQuery to measure aggregate usage and retention. The app does not use Analytics to display or personalize advertising. Google processes it under the applicable Analytics terms and privacy practices, including configured service and account data-sharing settings. See Google Analytics for Firebase data collection and Google’s Privacy Policy.

Crash reporting

Call Guard uses Firebase Crashlytics to diagnose crashes and improve reliability. Crash reporting is enabled automatically and independently of the Usage analytics setting; switching usage analytics off does not disable Crashlytics. The app currently has no separate crash-reporting switch.

Crashlytics can send crash traces, exception details, crash times, app and operating-system versions, device characteristics and installation or session identifiers to Google. The developer can view crash reports in Firebase. Call Guard does not deliberately attach contacts, phone numbers, blocked-call records, search text, custom user IDs or its local development diagnostic logs to these reports. Automatic exception details are separate from the restricted local diagnostic fields described below.

When Analytics is enabled, Firebase can include usage events and their parameters as breadcrumbs in crash reports to show actions preceding a crash. The custom-event exclusions above also apply to those event payloads. See Firebase privacy and security information and Firebase crash-report and breadcrumb documentation.

Remote processing, retention and deletion

Analytics and crash reporting transmit data to Google over encrypted connections. Remote processing and storage may take place outside your country, including on Google’s global infrastructure; a regional BigQuery export does not establish that every Firebase or Analytics service processes data only in that region.

Remote analytics data is retained according to Google Analytics retention settings and service rules. Exported BigQuery data has separate retention and table-expiration settings. These are separate from the app’s limit of 100 local history records. Google states that Crashlytics retains crash traces and associated identifiers for 90 days before starting removal from live and backup systems. Aggregate reports and other service data may follow different retention rules. See Analytics data retention and Firebase retention information.

Deleting app history affects the local history store. Clearing app data or uninstalling removes local app stores but does not automatically delete analytics or crash reports already received by Google. To ask about access to or deletion of remotely processed data, contact dmlukas@gmail.com. The developer will assess what can be identified and deleted using the available service tools; because the app has no account or custom user ID, an email address alone may not identify an installation’s analytics or crash data. Do not send phone numbers or private call history to identify telemetry.

Development diagnostics

Development builds have local debugging diagnostics. Their allowed fields exclude phone numbers, contact names, database record IDs, call timestamps, Intent or URI contents, exception messages and stack traces. The release app uses an inert diagnostic implementation rather than the development log writer. This local diagnostic mechanism is separate from Firebase Analytics and Crashlytics. Call Guard does not automatically attach or upload these local diagnostic logs through Settings.

Changes and contact

This policy may change as the app changes. The updated policy will remain at this document's existing public URL and will show the date the revision is published. For questions about this policy or information you voluntarily send to the developer, email dmlukas@gmail.com.