When this text is incorporated into a complete privacy-policy page, "we", "us" and "our" refer to the responsible operator identified on that page for the application or service you use.
APP NAME:
QR Scan Create And Home
QR Reader And Home Launcher
QR Scanner Home Launcher
QR Code Scanner And Launcher
QR Reader Creator And Home
QR Scanner And Custom Home
QR Code Scan And Smart Home
QR Tools And Home Launcher
QR Scan Reader And Home
QR Creator Scanner And Home
QR Code Reader Home Launcher
These common provisions apply to the applications, websites and related services expressly covered by that complete policy. They can be reused by multiple developers or publisher accounts, but each operator remains responsible for its own disclosed information handling. Merely linking to common text does not establish who operates an application or make undisclosed processing covered. Sharing policy wording does not itself mean that separate operators share user information or jointly control it.
Our applications do not all have the same features. Sections about media, face grouping, photo locations, SMS/MMS messaging, contacts, message backup and restore, Home launchers, advertising or analytics apply only to applications that include those functions or services. The relevant application, its permission requests and its store disclosures identify the functionality available to you. An additional feature notice supplements this policy; it does not remove your privacy rights.
The camera/editor and Home-launcher version described here includes camera capture through Android CameraX, on-device photo editing and collages, text and sticker overlays, video trim and mute, a local gallery, and Home-screen/app-drawer functions. It uses Google Mobile Ads, UMP, Firebase Analytics, Firebase Crashlytics, installation attribution and Cloudflare-hosted configuration requests. It does not require an application account or sign-in.
This version does not provide face-library grouping or face embeddings, photo-location/geocoding organisation, ML Kit or LiteRT integrations, or GitHub model downloads. The conditional passages about those features describe other feature sets only and do not apply to this version. Its device-supported camera retouch and portrait modes are distinct from creating a persistent face-grouping database. Website and business-service provisions apply when you use those services or contact the operator, not merely because you use the camera.
The SMS/MMS and Home-launcher version described here combines Android default SMS/MMS messaging with Home-screen and app-drawer functions. It includes conversation search and categories, pinning and archiving, manual blocking, scheduled messages, selected attachments and user-initiated SMS backup and restore. It uses Google Mobile Ads, UMP, Firebase Analytics, Firebase Crashlytics, installation attribution and Cloudflare-hosted configuration requests. It does not require an application account or sign-in.
The messaging provisions below apply to this feature set, not automatically to a camera or gallery application. Conversely, this SMS/MMS version does not include the beauty editor, face-grouping database, photo-location/geocoding organisation, ML Kit or LiteRT integrations, or model downloads described for other feature sets. Attaching a photo or opening a camera application to compose a message does not mean those other media features are included. The Home-launcher provisions apply to both described versions where present.
For privacy questions or requests, use the relevant operator's privacy-contact channel provided on the same privacy-policy page.
Accessing information on your device is different from transmitting it to a server. The local media, message-organisation and launcher functions described below work with information on your device. Sending SMS/MMS intentionally transfers the selected communication through messaging networks to its recipients; it is not an on-device-only operation. An application can also use network-based advertising, analytics, model downloads, configuration or place-lookup services.
Consequently, "on-device photo processing" or "local message organisation" does not mean that the entire application never sends any data over a network. Technical information such as identifiers, usage events, diagnostics and network-request information can be processed separately from the contents of your photos, videos and messages.
We explain these different activities below. Reading this policy or continuing to use an application is not, by itself, affirmative consent to optional processing that requires your consent.
When you contact us, request support, submit a project enquiry, apply for a role or engage our business services, we receive the information you choose to provide. This can include your name, email address, telephone number, company, project requirements, correspondence and attachments.
We use this information to respond, troubleshoot, prepare proposals, deliver services, manage business relationships, consider applications and maintain necessary business records. Please avoid sending passwords, unnecessary identity documents, private photos, message backups, one-time codes or other sensitive information with a support request. If you voluntarily send an attachment, it is received through our support channel and is no longer only on your device.
In applications with a camera, Android camera permission allows the app to show a camera preview and capture a photo when you use the capture controls. In the camera/editor and Home-launcher version, the front or rear camera supplies image data for framing, selfies and photo capture. You can deny or revoke camera permission in Android settings; this prevents camera capture but does not prevent selecting an existing image through Android's file picker.
Photo filters, light and colour adjustments, crops, collages, overlays and available beauty processing run on the device. Supported portrait, night, HDR and retouch modes use the device manufacturer's camera processing through CameraX; availability depends on the device. These camera and editing functions do not upload camera frames or selected media to an editing server, build a persistent face-identity database, or send those images to advertising or analytics providers as event content. Separate technical SDK collection is described in Sections 5 and 6.
Captured images and edits can be held temporarily in application storage while you work. Saved photos are written to the device: on Android 10 and later, this version uses Android's shared media storage, including the Pictures/Beauty Studio folder for camera/editor photos; on older supported Android versions, it uses application-specific picture storage. Other export tools can use their own image or video folders. Shared media can be visible to other applications with appropriate access. Application-specific files can be removed when the app is uninstalled, while shared exports generally remain. See Section 10 before clearing data or uninstalling.
In applications with media-library functions, we access the photos, videos and associated information that Android permits the application to access. Associated information can include filenames, file locations, dates, dimensions, duration, album membership and embedded metadata.
This access supports features such as browsing, playback, albums, favourites, editing, local search, memories, collages, animations, highlights and deletion or Trash controls, where available. Local media processing and saved organisational information remain on the device; these local functions do not automatically upload your media library to us.
You control access through Android's permissions and, on supported versions, its selected-photo controls. Limiting access can make related features unavailable. Saving edits, exporting media, deleting files or sharing them occurs through the functionality you use and any applicable Android confirmation. A local media feature is not a cloud-backup service.
This subsection does not apply to the camera/editor and Home-launcher version described in Section 1.
Applications offering private face grouping can analyse faces after you enable that feature. This can create local face descriptors or embeddings, group associations, face-analysis results and names or labels that you assign. Face-derived information can be sensitive, even though processing occurs locally.
These features organise similar faces within your library. They do not authenticate identity or match people against an external identity database. Photos, face descriptors, group associations and your people labels are not uploaded to us by the local face-grouping function or used by that function for advertising or remote model training.
A model or runtime may first need to download from a hosting provider or Google Play services. Downloading a model is distinct from uploading your photos. The download provider receives network-request information, and the machine-learning software can send technical metrics as described in Section 7.
Where face grouping is available, its controls let you turn it off and delete its stored face data. Deleting face data removes the locally stored names, groups and descriptors without deleting your original photos. Turning a feature off does not necessarily remove data it already created; use the deletion control to remove that data. Enabling and using the feature again can create new face data.
This subsection does not apply to the camera/editor and Home-launcher version described in Section 1.
In applications with places or trip organisation, we can read coordinates already embedded in a photo when you allow access to photo-location metadata. Those coordinates can reveal the precise location where the photo was taken.
The feature may send the coordinates to the device's Android geocoding service to obtain a place name, such as a city or country. The service can receive the coordinates and network-request information. The provider depends on the device and its system services; its handling is subject to the applicable provider's privacy terms. Place results can be cached locally.
This photo-metadata function is not live GPS tracking, and it does not send those photo coordinates to our advertising system. You can deny or revoke photo-location access. Doing so prevents further permission-gated access but does not automatically erase previously derived place information; local application-data controls may be needed to remove it.
The messaging subsections below apply to the SMS/MMS and Home-launcher feature set described in Section 1. Android's default SMS role and relevant permissions allow this application to read, receive, send and manage SMS/MMS. The information used includes message text, sender and recipient telephone numbers or addresses, conversation identifiers, message dates and times, incoming or outgoing status, delivery information, local read/unread state and available MMS attachment information. These permissions support messaging, not access to your call history or recording telephone calls.
Messages are accessed through Android's system messaging storage. The app also keeps local conversation data and working records to display threads, search messages, organise categories, save drafts, and support pinning, archiving and manual blocking. Categories and recognised one-time codes are derived locally from message text. Archiving or blocking a conversation is not the same as deleting its messages. Local read/unread and delivery information should not be interpreted as an online-presence or recipient-read-receipt service.
When you send a message, its text, selected attachments and addressing information are intentionally transmitted through your mobile operator and the relevant SMS/MMS networks to the recipient. Operators and recipients handle their copies independently. This user-requested transmission is distinct from uploading your inbox to a developer-operated server: the described messaging implementation does not upload your message history to us for storage, advertising or analytics. Message contents are not used by these local functions for advertising or remote model training. Separate advertising and diagnostic SDK processing is described in Sections 5 and 6.
You can change the default SMS application and review permissions in Android settings. Without the required role or access, corresponding messaging functions cannot operate. The default SMS role is separate from the default Home role; selecting a Home launcher does not by itself grant access to messages. A permission request or this policy does not replace a separate disclosure and affirmative consent where these are required.
With contacts permission, the messaging app reads contact names, telephone numbers, photo references and associated local address-book information, including record identifiers, number labels, starred status, account-source information and update metadata. It can keep local contact records to match telephone numbers to names, display conversations and help you choose recipients. Reading contact-source metadata is not access to the password for that account. The described contact-matching function does not upload your address book to us or to advertising or analytics providers.
Contact access is distinct from information already contained in a message. Refusing contacts access does not remove sender or recipient numbers from your messages. If you choose to include a contact's details in an outgoing message, the selected details are shared with the recipient when you send it; this does not send your entire address book.
Where supported, phone-state access supplies active SIM/subscription information, such as the SIM slot, subscription identifier and display label, so you can select and route an outgoing message through an available SIM. This function is not call-log collection. Availability depends on Android, your device and its active subscriptions.
You can choose photos, videos or audio through Android's document picker for attachment to a message. The app accesses the selected content and related file information needed to display or send it, and can retain the permitted file reference for later use. Older Android versions can require storage access for relevant media operations. For a new photo, the messaging version opens a camera application to capture an image into device media storage; it does not include the separate beauty editor described above. The camera application's own processing is subject to its practices.
The location attachment is optional and initiated by you. With approximate-location permission, the app obtains an available device location and adds a map link containing coordinates to the draft. The recipient receives that link only when you send the message. Opening the link can disclose the coordinates and network-request information to the map provider. This feature does not continuously track you in the background and does not request precise or background location access. Its device-location access is separate from the approximate location that advertising or analytics services can infer from an IP address.
Selected media can contain personal information or embedded metadata. Review attachments, contact details and location links before sending. Removing a draft or local attachment does not delete a copy already delivered to a recipient or a file saved separately in shared media storage.
Scheduling stores the intended recipients, message body, scheduled date and time, SIM selection, group-send choice and attachment references in the app's local database until the scheduled item is sent or removed. Android alarm access is used to trigger scheduled sending; on applicable versions, exact-alarm access may be required. Pending schedules can be registered again after a device restart. Sending still depends on the required SMS role, permissions, SIM and network availability, and access to selected attachments. Scheduling is not a guarantee of delivery at an exact time.
Drafts and pending schedules can contain sensitive text. Use the available controls to edit or remove a draft or cancel a scheduled item before it is sent. Once a communication has been handed to the messaging network, removing the local schedule cannot recall it or erase the recipient's copy.
Message notifications can display a sender's name or number and message content, including on a lock screen depending on Android and application settings. You can manage notification permission and preview visibility through the available app and device controls. If you use a copy action for message text or a recognised one-time code, the selected text is placed on Android's clipboard and is subject to the device's clipboard-access rules. Detecting or copying a code does not submit it to an account-authentication service operated by us.
The messaging version can export an SMS backup as a JSON file to a folder or document provider that you select. The backup can contain message bodies, telephone numbers or addresses, dates, read state, delivery/status fields and related SMS/SIM metadata. This is an SMS backup feature, not a complete MMS attachment archive or a developer-operated automatic cloud-backup service.
The exported JSON file is not encrypted by this application. Anyone who obtains a readable copy can access its contents. Choose a protected destination, restrict access and sharing, and delete unwanted copies. If you select a cloud-backed document provider, that provider may upload or synchronise the file under its own settings and privacy practices. That is a transfer to your selected provider, not a promise that every backup remains only on the device.
Restoring reads the backup file you choose and imports supported SMS records into Android's system messaging storage, after which they can appear in this and other authorised messaging applications. A foreground data-sync service supports the user-initiated import and shows progress in a notification; it is not continuous message-history syncing to our servers. Stopping an import does not undo records already restored. Uninstalling the app does not automatically delete the selected backup file or messages already imported into system messaging storage. Section 10 explains the separate deletion controls.
In applications with Home or launcher functions, we access information about installed launchable applications, such as their names, icons, package identifiers and launch activities. We use this locally to display and search the app drawer, open applications, manage shortcuts and support launcher controls. Layouts, favourites and related preferences can be stored locally.
The launcher function does not upload the installed-app list to us. A separate analytics event can indicate whether our application is selected as the default Home application; this is not an upload of the installed-app list.
You can change your default Home application in Android settings. Third-party widgets, applications, search providers and destinations opened from the launcher operate under their own privacy practices.
When you choose to share media or open an external search, website, application or service, the selected content or query is passed to the destination you choose. That destination may receive associated metadata and process information independently. Review your content and the destination's privacy policy before sharing. Removing a local copy does not remove a copy already sent elsewhere.
Applications that include advertising can use Google Mobile Ads and Google's User Messaging Platform (UMP). Whether an advertisement is displayed can depend on the application version, configuration, installation source, region and available consent choices.
Google Mobile Ads processes IP addresses, advertising or other applicable identifiers, interactions and performance information for ad delivery and measurement, analytics and fraud prevention. An IP address can be used to estimate an approximate location. Advertising partners can receive information needed for those activities. See how Google uses information from partner applications.
Relevant identifiers can include the Android Advertising ID and an app-set identifier. These have different permitted uses: app-set identifiers are for permitted non-advertising purposes such as analytics and fraud prevention, not personalised advertising. Consent-management tools also record applicable privacy choices and consent status to apply those choices and determine whether a privacy message is needed.
Where used, Google Play Install Referrer provides installation-source information. An application can use it locally to determine installation attribution and advertising eligibility. This is not, by itself, evidence of a payment or subscription.
Use the privacy choices presented by the application and available device or Google settings to manage supported advertising preferences. Android provides advertising-ID controls, which vary by version. Changing that identifier or declining personalised ads does not necessarily stop every technical request, all identifiers, contextual advertising or fraud-prevention processing.
Advertising choices and analytics choices are not interchangeable. An advertising consent message must not be interpreted as a guarantee that all other SDK data processing is disabled. See Section 6 for analytics and Section 11 for additional controls.
Applications using Google Analytics for Firebase send information to Google about application usage and operation. Information can include an app-instance identifier, application and device characteristics, operating-system version, language, approximate location, session and engagement events, and selected feature events.
Examples of application events include launch and lifecycle activity, default-Home status, and advertisement interactions, errors or loading performance. These help us understand usage, identify technical problems and improve reliability. Google processes the information through its analytics infrastructure; see Firebase privacy information and Google's Privacy Policy.
Analytics can initialise when an application starts. An advertising opt-out, a media-permission refusal or local face-data deletion does not necessarily disable analytics. Where a separate analytics control is available, its effect is described with that control. This policy does not claim that an analytics opt-out exists in every application.
The local media, messaging and launcher implementations described in Section 4 do not supply photo or video contents, face descriptors, people labels, message bodies, message attachments, contact lists, SMS backup contents or installed-app lists as analytics event content. If you send diagnostic material to support yourself, Section 3 applies to that submission.
The camera/editor and Home-launcher version and the SMS/MMS and Home-launcher version also use Firebase Crashlytics. Crash reports sent to Google include stack traces, relevant app state, device information and a Crashlytics installation identifier. Related Firebase Installations and Sessions components process installation and session information for service operation and app-quality metrics. Analytics breadcrumbs can help explain the activity preceding a crash. These records help diagnose failures and improve reliability; the described implementations do not attach your photo or video contents, message history, address book or SMS backup files to crash reports. See Firebase's SDK data disclosure.
Crash reporting and analytics can operate automatically without an account. Neither of these versions has an in-app switch that disables all automatic Analytics and Crashlytics collection. Declining personalised ads, refusing camera or contacts permission, deleting a photo or message, or clearing local app data does not erase diagnostic records already received by Google. Retention and request limitations are explained in Section 10.
The camera/editor and Home-launcher version and the SMS/MMS and Home-launcher version obtain advertising configuration from Cloudflare-hosted endpoints over HTTPS. A request exposes network-delivery information such as the IP address, requested resource, time and available headers. These configuration requests do not upload photos, videos, message contents, contact lists, SMS backup files or an installed-app inventory. Hosting services may process operational and security logs; fetching configuration is not evidence that those logs are immediately deleted. See Cloudflare's Privacy Policy.
The following integrations do not apply to either the camera/editor and Home-launcher version or the SMS/MMS and Home-launcher version described in Section 1. Other applications with on-device machine learning can use Google ML Kit and LiteRT through Google Play services. Their local processing does not send the input photos or the face-grouping outputs to Google for inference. Separately, the software can send technical information to Google, including device and application information, relevant identifiers, feature or API events, errors, configuration and performance metrics. Google uses these metrics to operate, diagnose, maintain and improve the software and detect misuse. See ML Kit privacy information and LiteRT privacy information.
Where an application downloads a model from GitHub or another host, the host receives network-request information needed to deliver that resource. The model-download request does not contain your photo library or face descriptors. See GitHub's Privacy Statement. Provider links explain their practices; they do not remove the operator's responsibility for its applications.
Our website and online business services can receive IP addresses, browser and device details, referring pages, requested pages, timestamps and interaction information. We use operational logs and, where deployed, cookies or similar technologies for website operation, security, troubleshooting and usage measurement.
Cookies and device identifiers are not necessarily anonymous or non-personal simply because they do not contain your name. You can manage cookies through your browser and any consent controls provided on the website. Blocking them may affect functionality. Website cookie choices do not automatically apply to mobile-application SDKs.
Business-service information may be processed by hosting, communications, project-management and professional-service providers when necessary to respond to an enquiry or deliver agreed services.
We process information for the specific functions explained above: providing requested services, remembering local preferences, support, application and website reliability, usage measurement, advertising where included, security and legal obligations.
Where applicable law requires a legal basis, the basis depends on the activity. It may include providing a service you request, consent for processing that requires consent, complying with law, or legitimate interests such as security and service improvement where those interests are permitted and do not override your rights. A general reference to legitimate interests does not override a requirement to obtain consent.
Information may be disclosed to:
Service and infrastructure providers: to deliver hosting, support, analytics, configuration, downloads and other described services.
Advertising providers: for advertising and related measurement, subject to applicable choices and requirements.
Destinations you choose: when you share information or open an external service.
Messaging networks and recipients: when you send SMS/MMS, the selected communication and addressing information pass through the relevant mobile operators and messaging networks to the recipients. These parties can retain their own copies; we cannot remove those copies through a local app deletion control.
Professional advisers or authorities: when necessary for legal advice, compliance, valid legal process, security or protecting lawful rights.
A successor business: as part of a lawful merger, acquisition or transfer, subject to applicable safeguards and notice requirements.
We do not sell or rent your personal information for money. Advertising-related transfers may nevertheless fall within broader legal definitions of "sale", "sharing" or targeted advertising in some jurisdictions; applicable rights and choices are not waived by the preceding statement. Local photo contents, face descriptors, message contents and attachments, contact lists, SMS backup contents and installed-app lists are not supplied to advertising partners by the local features described in this policy.
Retention depends on the information, why it is processed and whether it is stored locally, by us or by a service provider. There is no single retention period for every category.
Original media and shared exports: existing media you select and creations saved in shared device storage remain until you remove them or another authorised application or system process changes them. Uninstalling our application does not ordinarily delete these shared files. Trash and permanent-deletion behaviour depend on the application and Android version.
Application-specific captures, exports and working files: are distinct from shared media. In the camera/editor and Home-launcher version, older supported Android versions save camera/editor photos in application-specific storage. Uninstalling can remove these files; clearing application storage can also remove app-owned data. Copy any creations you want to keep to a separate location before clearing storage or uninstalling. Temporary working copies are not a backup of your originals.
Local preferences, caches, groups and derived information: remain until removed using available feature controls, cleared through Android's application-data controls, or removed with the application's private data. System and device behaviour can affect backups or restored copies. Do not rely on uninstalling as a way to delete shared media or copies held elsewhere.
System SMS/MMS and address-book records: remain in Android's messaging or contacts storage until you delete them through an authorised application or another authorised system process changes them. Clearing this app's data, changing the default SMS app or uninstalling does not itself erase those system records. Local read access and a local conversation cache are distinct from the underlying system records. Contacts synchronised by an account provider also follow that provider's settings.
App-owned messaging records: local conversation/contact caches, drafts, pending scheduled messages, attachment references, pinned or archived state, blocking preferences and related settings remain until changed or removed by the relevant feature or the app's private-data controls. Cancel a pending schedule using its control before sending if you no longer want it sent. Revoking access alone does not delete already stored local records. Messages or contacts that remain in system storage can be read into a new local cache if you later grant access and use the app again.
Exported SMS backups and restored messages: a backup remains in the chosen folder or document provider until you delete it there, including any separately synchronised, shared, Trash or backup copies. Deleting a conversation does not edit a previously exported backup. Restoring can create system SMS records that require their own deletion, and stopping a restore does not remove records already imported. Uninstalling is not a deletion request to the backup provider, your mobile operator or message recipients.
Local face data, only where face grouping is offered: remains until you use the face-data deletion control or remove the relevant private application data. Turning off grouping alone is not a promise of immediate deletion. This category does not apply to the camera/editor and Home-launcher version.
Support and business records: are retained while necessary to handle the request or relationship, maintain required business records, meet applicable legal obligations or resolve a dispute. Retention ends when those purposes and requirements no longer apply. No common fixed period is assumed for all operators.
Analytics and session/quality records: follow the relevant service configuration and provider retention rules. Analytics user-level events, aggregated reports, linked services and exported copies can have different retention schedules. Contact the operator through the privacy channel on this page for the settings and schedules applicable to its services. Removing local application data does not automatically erase remote records.
Crashlytics records: Google states that Crashlytics keeps crash traces and associated installation identifiers for 90 days before beginning removal from live and backup systems. This is not a promise of complete erasure exactly on day 90, and it does not set the retention of Analytics, hosting or separately retained support records. See Firebase's retention information.
Advertising, geocoding and hosting records: can be retained under the relevant service's operational, security and legal retention rules. A completed network request does not establish that every related server record has been immediately deleted.
For information under our control, retention is limited by its purpose, ongoing support or contractual needs, security investigations and legal recordkeeping requirements. Our retention policy is to delete or de-identify information through the relevant system's processes when it is no longer needed. Legally required or dispute-related records may need to be retained longer, with access limited to the relevant purpose.
To request information about applicable retention or request deletion, use the relevant privacy-contact channel on this policy page with the application or service name and a description of your request. An app-store link can help identify the correct application. We may need proportionate information to verify the request and locate records. Do not send sensitive device identifiers or identity documents unless we explain why a particular item is necessary and how to provide it safely.
A support email address does not by itself identify pseudonymous SDK records. We will explain relevant identification requirements or limitations rather than promise that emailing us instantly removes every third-party record. Requests concerning information processed by providers independently may also require use of their privacy controls. These practical limitations do not remove our obligations under applicable law.
There is no application account to close and no in-app control that deletes every remote advertising, Analytics or Crashlytics record. To remove local preferences and app-owned data, use Android's app-information and storage controls; labels differ by device. Review the storage distinctions above first. To remove shared photos or videos, use an appropriate media/file deletion control and check any separate Trash or backup copies. Changing the default Home app alone does not delete stored launcher preferences.
For support correspondence or other records held by the operator, send a request through the privacy-contact channel on the complete policy page, identifying the app and the records concerned. Remote SDK records may need additional, proportionate information to locate them. A request is not an automatic device wipe or a guarantee that unrelated provider-held records disappear. We will explain any retained records, applicable exceptions and practical identification limitations when responding to the request. A local deletion or uninstall confirmation is not confirmation that provider-held records have also been deleted.
There is no messaging application account to close. Use the relevant messaging controls to remove messages, drafts or pending schedules, and Android's app-storage controls to clear app-owned records when needed. Clearing private app data is not the same as deleting system SMS/MMS or the system address book. Delete exported backup files through the chosen file or document provider, and review that provider's synchronisation, Trash and retention settings. Keep any data you need before deleting it, and protect backups because they contain readable message data.
Changing the default SMS or Home application does not by itself erase stored messages or preferences. Revoking a permission stops the associated permission-gated access, not all SDK processing or retention of information already obtained. Neither an uninstall nor a local-data deletion removes a recipient's messages, operator-held network records or remote advertising, Analytics or Crashlytics records. For information held by the developer, use the privacy-request process and identification guidance above; the app does not provide a single control that deletes every local and remote copy.
You can use Android settings to review or revoke permissions, limit photo access where supported, change the default Home or SMS application, manage advertising identifiers and clear local application data. In the messaging version, the relevant settings can include SMS, contacts, phone/SIM information, approximate location, notifications and exact-alarm access, depending on Android and the feature. Selected-file access is also governed by Android's document-provider controls. Optional contact, attachment, location or scheduling functions do not make those permissions a requirement for the separate Home-launcher function.
You can also use the application's available controls to manage notification previews, remove drafts, cancel pending scheduled messages and choose not to use optional features. Disabling access can affect the associated function; it does not necessarily delete information already processed or recall a communication already sent. Review Section 10 for the difference between deleting app-owned data, system records, exported files and provider-held records.
Depending on your location and applicable law, you may have rights to access, correct, delete or obtain a copy of personal information; object to or restrict processing; withdraw consent; or opt out of certain advertising-related processing. Withdrawing consent does not undo processing that was lawful before withdrawal. You may also have the right to complain to the relevant data-protection authority or challenge a decision about your request.
Contact us using the privacy-contact channel on this policy page to exercise applicable rights or raise a grievance. We will handle requests within the period required by the law that applies to the request. We may need to verify your authority, particularly where you act for another person, and explain any lawful reason a request cannot be fully fulfilled. You do not need to create an application account merely to contact us about privacy.
Application suitability and intended audiences are described in the relevant store listing and applicable service information. A content rating does not by itself mean that an application is designed for children. A common minimum age or child-directed status is not assumed across different operators and services.
This shared policy does not authorise collection from children or replace any parental-consent, age-assurance or child-directed-service protections required by applicable law. If an application is specifically intended for children, its child-specific handling and protections must be explained in an additional notice before that use.
If you believe a child has provided information to us contrary to applicable requirements, use the privacy-contact channel on this policy page so that we can investigate and take appropriate action, including deletion where required. Age thresholds and parental rights can differ by jurisdiction.
We use reasonable technical and organisational measures appropriate to the information and service. These include operating-system access controls for private application data and HTTPS connections for the configuration requests described here. Google documents encrypted transport for its Ads and ML Kit SDK data, where those integrations are used. These statements about SDK and configuration traffic are not a claim that every form of communication or exported file is encrypted. Third-party destinations and device-provided services have their own security practices.
The SMS/MMS messaging function does not provide end-to-end encryption. Message delivery uses the applicable mobile operators and messaging networks and is subject to their security and retention practices. The app's exported SMS JSON backups are not encrypted by the app; a destination provider may have separate protections, but those should not be assumed. Protect device access, review lock-screen previews and keep message backups away from public or broadly shared locations.
No system, transmission or storage method is completely secure. We do not promise absolute security, end-to-end encryption for every operation, or protection of a file after you share it with another service.
Network services and providers can process information in countries other than your own or the operator's location, where their infrastructure or personnel operate. Local processing of your media, messages and contacts is distinct from processing of technical service data or a communication sent to recipients through messaging networks. Destinations and backup providers you choose can also process information internationally. Where applicable law requires transfer safeguards, appropriate contractual or other lawful safeguards must apply; this policy does not claim that all information remains in one country.
We may update this policy when our applications, providers, business practices or legal requirements change. Material changes will be communicated as required, and additional consent will be sought where required before the changed processing takes place.
A new feature involving materially different information handling needs an appropriate disclosure; the fact that an application links to this shared policy does not authorise undisclosed collection.
Use the privacy-contact or enquiry channel provided alongside this text on the same privacy-policy page. Include the application or service name and the nature of your request so that the responsible operator can identify the relevant records and respond appropriately. Please do not send unnecessary sensitive information.
Where a complete policy covers more than one operator, use the channel identified for the operator of your application. Contact details for one operator do not automatically serve as another operator's privacy-request channel.