Quickvoult Brand Logo
Quickvoult for Android

Privacy Policy

Last updated: September 26, 2026

1. Introduction

Welcome to QuickVault ("we", "our", or "us").
We respect your privacy and are deeply committed to protecting your personal data. QuickVault is designed with a strict "local-first" philosophy - your data stays on your device unless you explicitly choose otherwise. This privacy policy explains how we collect, use, and safeguard your data when you use the QuickVault Android application and our website.

2. The Data We Collect About You

Local Data Storage: The majority of your data - including your custom triggers, text templates, saved images, and documents - is stored exclusively on your device using a local database. We do not transmit, sync, or store this personal vault data on our own servers.

Google Drive Backup: If you choose to enable the Cloud Sync & Backup feature, your encrypted vault data is backed up directly to your personal Google Drive account. We do not have access to your Google Drive files outside of the specific backup folder created by QuickVault.

Android Auto Backup: Android's Auto Backup system may automatically back up app data (including your local database and preferences) to your Google account. This backup is managed by Android itself and is subject to Google's privacy practices. Your snippets may contain personally identifiable information (e.g., email signatures, addresses, account numbers). You can disable Android Auto Backup for QuickVault in your device's system settings if you prefer that this data is not backed up.

3. Accessibility Services

QuickVault requires the Android Accessibility Service permission to deliver its core text expansion feature. When you type a trigger keyword (e.g., ..addr) in any text field - in any app - QuickVault detects it and give suggestion from your stored triggers (Text Snippets, Images, Files, Links, etc.). You can replace the keyword with snippet by tapping on the snippet in the suggestions (Or enable auto insert in settings to automatically insert the snippet when trigger is detected and has only 1 snippet). This is the single purpose of the Accessibility Service.

3.1. What Data Is Accessed

The service only reads the text content of the currently focused editable input field. It reads the current text to check whether it has a user-defined trigger prefix. No data is logged, transmitted, stored, or shared with any third party.

3.2. Accessibility Capability & Flags Used

The following accessibility capability and flags are declared in the service configuration to ensure text expansion works reliably across different apps and Android versions. Each one is strictly limited to enabling trigger detection in editable input fields-nothing more.

Capability

  • canRetrieveWindowContent: Required to read the actual text content of the currently focused editable input field. Without this capability, the service can only receive basic event metadata (e.g., that a text change occurred)-not the text value itself, which is needed to detect your trigger keywords. The service reads this text in-memory only; it is never logged, stored, or transmitted.

Flags

  • flagReportViewIds: Instructs the accessibility framework to include the resource ID of each view node in the accessibility tree. QuickVault uses this to reliably identify and filter the specific input field that is currently focused, so it does not accidentally process text from the wrong element. No content is read from nodes solely because their ID is known-this flag only improves node targeting accuracy.
  • flagRetrieveInteractiveWindows: Required for apps (such as Google Chrome, Opera, or apps using WebViews or floating overlay windows) that render text fields inside secondary or interactive windows rather than the main app window. Without this flag, the accessibility tree for such windows is not provided to the service, making trigger detection impossible in those contexts. The service uses this flag only to locate the focused editable field-it does not enumerate or read content from all open windows.
  • flagIncludeNotImportantViews: Some apps mark their input fields as "not important for accessibility"-a hint intended for screen readers to skip decorative UI elements. This flag overrides that hint so that such input fields remain visible in the accessibility tree. Detection is not guaranteed-apps and certain Android OS versions may still restrict accessibility service access to their text fields regardless of this flag. It does not cause the service to read any additional data; it only affects which nodes are included during tree traversal. The service still filters and processes only editable, focused nodes.

3.3. Accessibility Event Types Subscribed

The service subscribes only to the specific event types necessary to detect when text changes in an input field. Subscribing to fewer events minimises performance overhead and limits the surface area of data the service is exposed to:

3.3.1. Standard Mode (Always Active)

These five events are subscribed at all times and form the core detection surface. They are declared statically in the service XML configuration.

  • typeViewFocused: Fires when the user taps into a text field (focus moves to an input). The service uses this event to identify and cache a reference to the active input field for subsequent text reads.
  • typeViewTextChanged: Fires when the text content of a focused input field changes (i.e., as you type). This is the primary event used to check whether the current text ends with one of your defined trigger prefixes.
  • typeViewTextSelectionChanged: Fires when the text cursor position or selection changes within an input field. The service uses this to re-read the text at the current cursor position, ensuring accurate trigger detection in cases where text is inserted or moved programmatically.
  • typeWindowStateChanged: Fires when a window is opened, closed, or foregrounded (e.g., switching between apps or dialogs). The service uses this event to clear any cached input field reference and reset its detection state, preventing stale data from a previous app being used in the new context.
  • typeWindowContentChanged: A broader event that fires when any content within the visible window changes. This is used as a fallback for apps (e.g., Google Chrome, Microsoft Word, Outlook) where the more specific text-change events are not fired reliably. A debounce mechanism cancels any pending scan and waits 150 ms before processing to prevent excessive CPU usage from rapid successive events.
  • flagInputMethodEditor (Android 13 / API 33 and above only): This flag, introduced in Android 13, grants the accessibility service an InputConnection-the same low-level text channel that a software keyboard uses to interact with the focused input field. QuickVault uses this as a last-resort fallback when all standard accessibility actions (such as ACTION_SET_TEXT, ACTION_PASTE, and select-then-replace) fail to replace a trigger in a particular app or field.

    Why it is needed: Some apps and input fields reject higher-level accessibility actions for security or architectural reasons-for example, apps that use custom text rendering engines, sandboxed WebViews, or hardened input validation. In these cases, writing directly through the InputConnection channel-mimicking how a keyboard would commit text-is the only reliable path available to an accessibility service. Without this flag, QuickVault's text replacement would silently fail in those apps, leaving the trigger unexpanded.

    Exactly what it accesses: The InputConnection exposes only the content of the currently focused, editable input field at the moment of replacement. QuickVault uses it exclusively to:
    • Delete the trigger characters the user just typed (e.g., ..addr) using deleteSurroundingText().
    • Insert the expanded snippet text in their place using commitText().
    What it does NOT do: Despite having access to an InputConnection, QuickVault does not read arbitrary surrounding text beyond what is needed to perform the replacement, does not log keystrokes, does not intercept passwords (password-type fields are explicitly skipped), and does not transmit any content to external servers. The connection is used exclusively for the one-time write operation of replacing a trigger.

    Stability safeguard: Android requires that the framework's bindInput and unbindInput lifecycle calls remain paired. To honour this contract, QuickVault declares this flag only in the static XML configuration file (accessibility_service_config.xml) rather than applying it dynamically in code. Dynamic re-application of this flag was found to cause the Android system to forcibly unbind and rebind the InputMethod session mid-replacement, resulting in a service disruption. Declaring it statically ensures the Android framework manages the binding lifecycle correctly from service startup, preventing instability.

    On devices running Android 12 or earlier, this flag has no effect and is silently ignored by the system. QuickVault falls back to the standard clipboard-based replacement path on those devices.

3.3.2. Enhanced Input Detection Mode (Opt in by user)

When you enable Enhanced Input Detection in QuickVault's settings, four additional event types are dynamically added to the subscription list at runtime. This mode exists solely to improve compatibility with apps that have non-standard input handling (e.g., certain browsers, office suites, or apps using custom canvas-based editors). These events are never subscribed by default and are only active when you explicitly turn on Enhanced Input Detection.

  • typeViewClicked (Enhanced Input Detection only): Fires when the user taps a UI element. The service uses this to re-check which field is currently active after a tap interaction, which is particularly useful in apps where tapping a field does not always produce a separate focus event.
  • typeViewScrolled (Enhanced Input Detection only): Fires when the user scrolls within a scrollable container. The service uses this to update its reference to the active input field when the visible layout shifts as a result of scrolling, ensuring the correct node is targeted in dynamic or list-based UIs.
  • typeWindowsChanged (Enhanced Input Detection only): Fires when the set of visible windows on screen changes (e.g., a floating keyboard appears, a dialog opens, or a picture-in-picture window changes). The service uses this to detect changes to the window stack that may affect which input field is reachable, allowing it to update its internal state accordingly.
  • typeViewAccessibilityFocused (Enhanced Input Detection only): Fires when accessibility focus (distinct from input focus) moves to a view-typically triggered by screen readers or assistive tools navigating the UI. The service listens to this event to maintain an accurate reference to the currently active node in apps where input focus and accessibility focus differ, improving detection reliability in those edge cases.

None of these events cause QuickVault to read, store, transmit, or log any additional data beyond what is described in Section 3.1. They solely control how frequently the service checks which input field is currently focused.

3.4. High-Frequency Event Handling

For applications where standard text change events may not fired (e.g., Google Chrome, Microsoft Word, Microsoft Outlook), the service relies on typeWindowContentChanged as a fallback.

Because these events fire at a high frequency-even when the user is simply scrolling through a webpage, reading, or watching a video-we have implemented a dual-layered optimization strategy to prevent severe performance impacts and battery drain.

First, the service performs a high-speed pre-check during handleWindowContentChanged() to verify if the software keyboard (AccessibilityWindowInfo.TYPE_INPUT_METHOD) is visible. If the keyboard is closed, the service assumes the user is not actively typing and instantly aborts the screen scan, saving significant CPU overhead.

Second, when the keyboard is open and typing is detected, a debounce mechanism is applied that cancels any previous scan and waits 150 ms before processing. Together, these measures ensure the app captures essential input while completely eliminating wasted screen scans during passive device usage.

3.5. What the Service Does NOT Do

  • It does not record passwords - it skips fields with password input types.
  • It does not read content from non-editable elements (labels, images, etc.).
  • It does not transmit any text to external servers.
  • It ignores its own app's windows to prevent feedback loops.
  • It never performs autonomous clicks or navigation on your behalf.

4. Battery Optimization Permission (Opt in by user)

To ensure the Accessibility Service remains alive and responsive at all times, QuickVault may guide you to disable Android's battery optimization (Doze mode) for the app. Without this exemption, Android may kill the service in the background, causing text expansion to fail silently until you manually re-enable it.

During onboarding (or via Help & Support), the app directs you to the general battery optimization settings page - it does not silently self-exempt. You choose whether to grant the exemption. No background network calls, location polling, or data collection occurs as a result - the service only listens to text events from the active input field.

5. Input Helper Floating Bubble

QuickVault offers an additional Input Helper feature: a small floating bubble that, when tapped, expands into a mini panel where you can type free text and copy snippets to clipboard-without switching away from your current app. This is designed specifically for apps that use highly custom input fields not detectable by the accessibility service.

  • The bubble is on by default and starts automatically once you grant the accessibility permission for this feature (via System Settings → Accessibility).
  • It can be dismissed at any time by long-pressing the bubble and choosing the disable option.
  • It does not collect, transmit, or store any data beyond what you type into the panel during that session. Text entered into the panel is only held in memory and is cleared when the panel is closed.

6. Keep Alive-Foreground Service (Opt in by user)

The Keep Alive feature is an opt-in setting (disabled by default) within the Help & Support (Or Long-press Input Helper Bubble). When enabled, it promotes the QuickVault Accessibility Service from a background service to an Android Foreground Service, keeping the floating bubble persistently visible on screen even when the device is idle or other apps are in the foreground.

When Keep Alive is active, Android requires the app to display a persistent notification in the system notification shade. This notification is a mandatory transparency mechanism imposed by Android for all foreground services-it is not used for marketing, alerts, or any other purpose. You can disable Keep Alive at any time from the Input Helper settings, which will stop the foreground service and dismiss the notification.

  • Why it exists: Without a foreground service, Android's memory management may kill the accessibility service or suspend the floating bubble during periods of inactivity, causing the feature to stop working until the app is re-opened.
  • What it does not do: The foreground service does not perform any background network requests, location polling, data collection, or synchronisation. It solely maintains the service process alive so the bubble remains interactive.
  • Permission required: On Android 9 and above, running a foreground service requires the FOREGROUND_SERVICE permission. On Android 14 and above, the FOREGROUND_SERVICE_SPECIAL_USE type is declared. Both are granted automatically by Android upon installation-they do not require user approval and are standard requirements for keeping a UI element visible on screen.
  • How to disable: You can turn off Keep Alive at any time from within the app (Help & Support → Keep Alive toggle). The foreground service will stop immediately, the notification will be dismissed, and the service will revert to standard background mode.

7. Third-Party Services

Our application may use third-party services for essential functionality:

  • Google Play Billing: Used securely to process QuickVault Premium purchases and subscriptions.
  • Google AdMob: Used to display advertisements to free users. AdMob may collect certain device identifiers and usage data to serve relevant ads according to Google's Privacy Policy.

8. Data Security

We have put in place appropriate security measures to prevent your personal data from being accidentally lost, used, or accessed in an unauthorized way. Since your vault data is kept local to your device, its security largely depends on your device's security measures (e.g., screen lock PIN, biometrics). If Android Auto Backup is enabled, backed-up data is protected by Google's encryption; however, if a backup is restored onto a different or compromised device, your snippet data could potentially be exposed.

9. Contact Us

If you have any questions about this privacy policy, please contact us at support@quickvoult.ctrltab.in.