This Privacy Policy explains how data is accessed, used, stored, and shared when using the Android applications Switchly, Switchly Lite, and Switchly Launcher, developed by Andi Schreiner.
This policy applies to users of the Android applications:
Some features are optional and may only be available in certain app versions or builds. If a feature is not used or not available in a specific app version, the related permission or data access may not apply.
Switchly, Switchly Lite, and Switchly Launcher may use the Android AccessibilityService API for the app blocking feature. When enabled by the user, this service can detect when a selected app is opened so the app can immediately block access and enforce limits, schedules, profiles, and related blocking rules configured by the user.
While enabled, Android may allow the app to observe app and window changes needed to detect blocked apps. This access is used only for app blocking and enforcement of the blocking rules configured by the user. It is not used to read passwords or keystrokes for advertising.
Accessibility access is optional, must be enabled manually by the user in Android Accessibility settings, and can be revoked by the user at any time.
The apps may request App Usage Access to read Android usage statistics. This is used to provide screen-time summaries, daily app limits, usage-based blocking, usage insights, diagnostics, and related in-app statistics.
Usage access is optional and must be enabled manually by the user in Android settings. Without this access, usage-based features may not work or may be limited.
The apps may access information about installed apps or app package names so the user can select which apps should be blocked, allowed, limited, or monitored. This information is used to display app lists, enforce blocking rules, show usage statistics, and provide related app management features.
App selections, blocked-app lists, allowed-app lists, package names, and related settings may be stored locally on the device. If the user enables optional account, sync, backup, or restore features, this configuration may also be included in the backup data needed to restore the user’s app state.
If the user enables notification-related features, the apps may request Notification Listener access to identify notifications from apps that are currently blocked by the active profile and suppress them on the device.
Notification access is used only for notification blocking and related features configured by the user. Without this access, notification blocking features will not function.
If the user enables NFC-based actions, the apps may read NFC tag data to trigger user-configured actions. If paired-tag features are used, NFC tag identifiers and related metadata may be stored locally on the device so the apps can recognize authorized tags and apply configured actions, limits, or cooldowns.
NFC data is used only for the NFC features configured by the user.
If the user enables QR code or barcode features, the apps may request Camera permission to scan QR codes or barcodes. Camera access is used only for scanning content needed for the selected feature.
QR codes, barcodes, generated codes, paired code identifiers, and related metadata may be stored locally on the device so the apps can recognize authorized codes and trigger user-configured actions.
If the user enables location-based features, the apps may request Location permission to detect whether a user-configured location rule should become active or inactive. This can be used for location-based schedules, automation rules, or blocking profiles configured by the user.
Location access may include approximate or precise location, depending on the Android permission granted by the user. If background location access is enabled by the user, location may also be accessed while the app is not open so that location-based blocking rules can continue to work.
Location data is used only to provide the location-based features configured by the user. It is not sold, not used for advertising, and not used to track the user for marketing purposes. The user can disable location access at any time in Android system settings, but location-based features may stop working.
Location-based rule configuration created by the user, such as saved places, location triggers, or related schedule settings, may be stored locally on the device. If the user enables optional cloud backup or restore, this configuration may also be included in backup data so the user can restore their settings.
If the user enables Wi-Fi or Bluetooth based automation, the apps may access Wi-Fi network information or Bluetooth device information needed to detect whether a configured rule should become active or inactive.
This may include Wi-Fi network names, Wi-Fi identifiers, Bluetooth device names, Bluetooth addresses, or related connection state information, depending on the Android version, permissions granted by the user, and the feature being used.
Wi-Fi and Bluetooth data is used only for rules and automation configured by the user. It is not sold or used for advertising.
The apps may request notification permission so they can show reminders, status updates, blocking status, schedule status, foreground service notifications, and feature-related notifications to the user.
The apps may use alarms, exact alarms, foreground services, or background receivers to keep user-configured schedules, timers, temporary actions, widgets, and blocking rules working reliably.
These features are used only to provide app functionality configured by the user. The user may disable related permissions or system settings, but some scheduling or automation features may stop working reliably.
If the user enables hard mode, uninstall protection, or similar protection features, the apps may request Android Device Administrator access. This can be used to make it harder to bypass active blocking rules by uninstalling or disabling the app.
Device Administrator access is optional, must be enabled manually by the user, and can be disabled by the user in Android system settings. The apps do not use this access for advertising or tracking.
If the user chooses to sign in and use optional cloud features, the apps may use services such as Google Sign-In, Firebase Authentication, and Firebase Firestore to authenticate the account and store or restore backup data.
Account-related data may include identifiers provided by the sign-in provider, such as account ID, email address, display name, or authentication tokens needed to provide sign-in, backup, restore, sync, and premium-related features.
Optional cloud backup data may include app settings, profiles, schedules, location-based rule configuration, Wi-Fi or Bluetooth rule configuration, blocked-app selections, allowed-app selections, NFC-related configuration, QR code or barcode-related configuration, usage or blocking statistics, and other settings needed to restore the user’s app state across installs or devices.
Cloud backup and restore are optional and user-initiated. If the user does not use these features, most app data remains stored locally on the device.
If the user purchases or activates premium features, the apps may use Google Play Billing or related purchase verification systems to process purchases, verify entitlement, and unlock premium functionality.
Purchase processing is handled by Google Play. The apps may receive and store purchase status, product identifiers, purchase tokens, entitlement status, or related technical information needed to verify and restore premium access.
The apps may use crash reporting tools such as Firebase Crashlytics to collect technical diagnostics needed to detect errors, investigate crashes, and improve app stability.
Diagnostic data may include crash logs, stack traces, app version, device model, Android version, installation identifiers, timestamps, and related technical information needed to understand and fix issues.
The apps store configuration and runtime data locally on the device as needed for core functionality. This may include profiles, schedules, location-based rule configuration, Wi-Fi or Bluetooth rule configuration, blocked-app selections, allowed-app selections, app usage statistics, blocking statistics, NFC-related data, QR code or barcode-related data, widget settings, premium status, and other settings created by the user.
The apps may use third-party service providers to operate optional or technical features, including Google Play services, Google Sign-In, Google Play Billing, Firebase Authentication, Firebase Firestore, and Firebase Crashlytics.
These providers may process data according to their own privacy policies and terms. Data may be processed in countries outside the user’s country of residence, depending on the provider’s infrastructure.
Local app data is retained for as long as necessary to provide app functionality or until the user clears app data, uninstalls the app, or deletes relevant content. If the user uses optional cloud features, cloud-stored data is retained until it is deleted by the user or no longer needed to provide the service.
Crash reports and diagnostic data are retained only as long as needed to analyze and fix technical issues, subject to the retention settings of the service provider used for diagnostics.
If the user has enabled optional account and cloud features, account-related cloud data can be deleted using the deletion options provided in the app, where available. Users may also contact us to request deletion support.
Users can delete local app data by clearing the app data in Android system settings or by uninstalling the app. Some system-level permissions, such as Accessibility, Notification Access, Location, or Device Administrator access, may need to be revoked separately in Android system settings.
The apps are not specifically directed to children. If we become aware that personal data from a child has been collected without appropriate consent where required, we will take reasonable steps to delete that data.
Under applicable data protection laws, including the GDPR where applicable, users may have the right to request access to, correction of, or deletion of their data. Requests can be made via email: info@saltyy.at
Andi Schreiner
Vienna, Austria
Email: info@saltyy.at