Embedded Files
VirtualizeApps
Clone Your Android Applications And Keep In Safe your virtual environment e Way by using Google Drive
Privacy Policy — Virtualize Apps
Clone Your Android Applications And Keep In Safe your virtual environment e Way by using Google Drive
Privacy Policy — Virtualize Apps
Application ID: com.albatrosengineering.virtualizeapps Developer: Albatros Engineering Last updated: 11 April 2026
1. Purpose of this app and our commitment
1. Purpose of this app and our commitment
Virtualize Apps is a virtualization (container) tool for Android. Its purpose is to make it easier for people to run and manage applications in an isolated environment on their own device — for example to separate work and personal use, test apps, or organize copies of apps without replacing the official Play experience.
We do not sell your personal data. We do not use the app to take unauthorized control of devices, to distribute malware, or to extract data from your phone for resale. Processing described below is limited to operating the product you installed, optional features you turn on, and services required by the platform (Google Play, ads, and sign-in where you choose to use them).
2. Who is responsible for your information
2. Who is responsible for your information
The data controller for Virtualize Apps is Albatros Engineering, in respect of any processing we describe as carried out by us. For processing that is performed only by Google (Play, Drive, ads, billing), Google acts under its own terms and policies.
3. What data is processed and why
3. What data is processed and why
3.1 Data that stays on your device (we do not upload this to our servers)
• Virtualized / sandbox environment — Apps and data you run or store inside the virtualized space remain on your device under Android’s normal app storage rules. We do not operate a cloud backend that receives the contents of your sandbox as part of the core service.
• Device and system interaction — The app needs access to device capabilities so virtualization can work (for example listing or launching apps you add to the container, storage paths the system assigns to the app, and permissions reflected in the merged manifest so sandboxed apps can request features such as camera or microphone when you use them). This is functional processing on the device, not a separate “profile” we sell.
• App lock (optional) — If you enable the lock, your unlock pattern is not stored in plain text. A salted hash is stored using Android’s encrypted storage (EncryptedSharedPreferences with a hardware-backed or strong software MasterKey where the device supports it). Biometric unlock uses the standard Android biometric APIs; we do not receive your fingerprint or face data — the system performs matching on device.
• Local preferences — Settings you choose inside the app (for example lock on/off, backup-related preferences stored locally) are kept on the device unless a feature explicitly uses a service below.
3.2 Google Drive backup (only if you sign in and start a backup)
• When you choose to use Google backup, you sign in with your own Google account and grant the app access to create and manage files in Google Drive on your behalf, limited to the scopes requested by the app (Drive file access for app-created backups).
• Backup files (for example archives of sandbox-related data you choose to export) are transferred directly between your device and Google’s servers using Google’s APIs. They are stored in your Google account (for example under a dedicated folder name used by the app). We do not route that content through our own servers and we do not retain a copy on infrastructure operated by us for that purpose.
• Google processes account and file metadata under Google’s Privacy Policy. You can revoke access or delete files in your Google account at any time.
3.3 Google Sign-In and account identifiers (only if you use Drive backup)
• If you use Google Sign-In for Drive, Google processes authentication and may share with the app the account information needed for that flow (such as account identifier and email as provided by the sign-in API). We use this only to perform the backup and restore features you request.
3.4 Google Play Billing (only if you purchase a subscription or in-app product)
• Purchases are processed by Google Play. Payment information is handled by Google and its payment partners. We receive information needed to confirm entitlement (for example subscription state as exposed by the billing library), not your full card details.
3.5 Advertising (Google AdMob)
• The app may show ads through Google Mobile Ads (AdMob). Ad networks may use advertising identifiers, device information, and interaction data to show and measure ads, in line with Google’s policies and your device’s advertising settings. This processing is primarily between your device and Google/ad partners; we do not sell a separate list of your contacts or sandbox contents to advertisers.
3.6 Internet and diagnostics
• Network access is used for ads (if enabled), Google services you opt into (sign-in, Drive, Play Billing), and normal Play distribution/update channels. We do not describe operating our own analytics backend in this policy; if we add first-party analytics later, we will update this document.
4. What we do not do
4. What we do not do
• We do not sell your personal information to data brokers.
• We do not exfiltrate the contents of your virtualized apps or your sandbox to our own servers as part of the described product behavior. Optional backup goes only to the Google account you authenticate.
• We do not design Virtualize Apps to harm devices or bypass security for unrelated third parties; the product is intended as a legitimate virtualization aid for the device owner.
5. Legal bases (for users in the EEA, UK, and similar jurisdictions)
5. Legal bases (for users in the EEA, UK, and similar jurisdictions)
Where the GDPR applies, we rely on: performance of a contract / steps prior to contract (providing the app and features you request); legitimate interests (for example securing the app, fraud prevention, and product improvement compatible with your rights); and consent where required (for example for certain advertising or optional integrations). You may withdraw consent where processing is consent-based, without affecting prior lawful processing.
6. Sharing and recipients
6. Sharing and recipients
• Google LLC and affiliates, for Play distribution, optional Sign-In, Drive API, Play Billing, AdMob, and device safety where applicable — under their policies.
• We do not list additional advertising or analytics partners beyond what the integrated SDKs introduce; AdMob is identified above.
• We may disclose information if required by law or to protect rights and safety.
7. International transfers
7. International transfers
If you use Google services, data may be processed in the United States and other countries where Google operates, subject to Google’s safeguards (for example standard contractual clauses as described in Google’s documentation).
8. Retention
8. Retention
• On-device data remains until you uninstall the app or delete data through the app or system settings.
• Backup files on Google Drive remain until you delete them in Drive or revoke the app’s access.
• Google retains billing and ad-related records according to Google’s policies.
9. Security
9. Security
We use platform security features (including encrypted storage for lock settings where applicable) and expect users to keep devices updated. No method of storage or transmission is 100% secure.
10. Your rights
10. Your rights
Depending on your location, you may have rights to access, rectify, erase, restrict processing, object, data portability, and to complain to a supervisory authority. Contact us via the developer contact email published on this app’s Google Play store page. You may also manage Google-held data through your Google Account and privacy controls.
11. Children
11. Children
Virtualize Apps is not directed at children under 13 (or the digital consent age in your country). We do not knowingly collect personal information from children for marketing. If you believe a child has provided information improperly, contact us via the Play listing contact.
# Critical permissions, processing, and privacy (English)
This document explains why sensitive permissions appear in the app, how they are used, and how that relates to user control and data leaving the device. It is written for Google Play review, in‑app disclosures, and policy pages.
1. What the app does (scope)
1. What the app does (scope)
The app provides an isolated “second space” on the same device where other apps can run with their own data and lifecycle, similar in concept to a parallel or cloned app environment. Many permissions exist so that apps you choose to run inside that space can call the same Android APIs they would call when installed normally. The host app does not use those APIs to build a remote copy of your life on a developer server.
2. User control and “no export” statement (plain language)
2. User control and “no export” statement (plain language)
User request: Features that touch sensitive data (files you pick, permissions you grant in system settings, apps you install or open inside the space, purchases you confirm) are driven by your actions. Nothing in the core design described here automatically ships your private content (messages, call logs, contacts, photos, microphone audio, etc.) to the app developer’s servers for analytics or resale.
How we process: Sensitive capabilities are used on the device to deliver the functionality you triggered (for example: opening an app that needs the microphone, granting storage access so container apps can read their own data paths, or showing a map). Processing follows Android’s permission model and your choices in Settings → Apps → [this app] → Permissions (exact UI varies by Android version and OEM).
“Nothing leaves the device” — accurate wording: We do not, as the app publisher, collect, aggregate, or transmit your sandboxed app content to our own backend or to unrelated third parties for marketing or profiling.
What must still be stated honestly: The app may integrate Google Play Billing (purchases handled by Google Play) and Google Mobile Ads (AdMob). Those components can send device/advertising‑related and transaction signals to Google under Google’s policies when ads are shown or when you buy a subscription. That is not the same as “we upload your SMS/contacts to our server,” but it is external processing by Google. Your Play Data safety form should list Google where required.
3. Critical and restricted permissions (detailed)
3. Critical and restricted permissions (detailed)
Below, “Why declared” covers manifest / compatibility reasons. “How used” describes the intended runtime behavior. “User gate” states what the user does before anything meaningful happens.
3.1 All files access — MANAGE_EXTERNAL_STORAGE (Android 11+)
3.1 All files access — MANAGE_EXTERNAL_STORAGE (Android 11+)
Topic
Detail
Why declared
Some apps running in the isolated space expect broad file access similar to legacy storage behavior. The merged manifest may also list Google’s mirrored declaration for Play Services compatibility.
How used
On Android 11 and above, the app may direct you to the system screen “All files access” for this package only, so container data and installs can work reliably. No bulk upload of your personal folders to our servers is performed by this mechanism.
User gate
You must explicitly allow “All files access” in system settings; you can revoke it at any time.
3.2 Package visibility — QUERY_ALL_PACKAGES (restricted on Google Play)
3.2 Package visibility — QUERY_ALL_PACKAGES (restricted on Google Play)
Topic
Detail
Why declared
A dependency manifest may still contain a historical declaration.
How used
The shipping app is configured so this permission is removed from the merged manifest (tools:node="remove"). Package visibility for the host relies on narrow <queries> (for example launcher apps and a small set of explicit package names where needed).
User gate
Not used as “list every installed app for background upload.” Final Play bundle should be verified so QUERY_ALL_PACKAGES does not appear in the released artifact.
3.3 Usage / diagnostics-style permissions — e.g. PACKAGE_USAGE_STATS, protected APIs in manifest
3.3 Usage / diagnostics-style permissions — e.g. PACKAGE_USAGE_STATS, protected APIs in manifest
Topic
Detail
Why declared
Compatibility with apps that declare or invoke usage / package / ops related APIs inside the virtualized environment.
How used
The host does not operate a hidden “usage harvesting” product that exfiltrates which apps you use to our servers. Any usage‑style capability is bound to normal Android enforcement and what you enable in system settings if the OS exposes such a toggle for this package.
User gate
Special access toggles (if applicable) remain user‑controlled in system settings.
3.4 Overlay / system UI — SYSTEM_ALERT_WINDOW, related overlay declarations
3.4 Overlay / system UI — SYSTEM_ALERT_WINDOW, related overlay declarations
Topic
Detail
Why declared
Floating windows, game tools, or “always on top” experiences used by some cloned apps.
How used
Drawing over other apps happens only after the user grants the “Display over other apps” (or equivalent) permission in system settings when a feature requires it.
User gate
System overlay permission screen; revocable in settings.
3.5 Location — ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_MEDIA_LOCATION, plus GMS‑prefixed mirrors
3.5 Location — ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_MEDIA_LOCATION, plus GMS‑prefixed mirrors
Topic
Detail
Why declared
Maps, “follow my location,” or apps inside the space that use location APIs; EXIF location for photos where the OS requires ACCESS_MEDIA_LOCATION.
How used
Location is read on device for the feature you opened; we do not describe a background pipeline that sends a continuous location history to the publisher’s servers. Third‑party apps you run inside the space may request network access under their own logic — that is their behavior once you use them.
User gate
Runtime location permission dialogs and OS toggles; can be denied or revoked.
3.6 Camera and microphone — CAMERA, RECORD_AUDIO, MODIFY_AUDIO_SETTINGS, foreground service types for mic/camera
3.6 Camera and microphone — CAMERA, RECORD_AUDIO, MODIFY_AUDIO_SETTINGS, foreground service types for mic/camera
Topic
Detail
Why declared
Video calls, voice notes, camera apps, and Android 10+ foreground‑service type requirements.
How used
Streams are handled locally for the session you start; there is no publisher‑operated “silent always‑on recording” channel described here.
User gate
You open an app or feature that needs camera/mic; runtime permissions and in‑app controls apply.
3.7 Phone, SMS, MMS, contacts, calendar, call log — telephony and PIM group
3.7 Phone, SMS, MMS, contacts, calendar, call log — telephony and PIM group
Topic
Detail
Why declared
So messaging, dialer, and productivity apps inside the isolated space can work like normal installs.
How used
Data is accessed through Android APIs when you use an app that requests it. The publisher does not describe a batch job that copies your address book or SMS database to a custom cloud.
User gate
Per‑permission grants and per‑app behavior inside the space; uninstalling the host removes that sandbox data from the host’s app data area under normal Android rules.
3.8 Storage and media — READ_* / WRITE_* storage, READ_MEDIA_*, app‑specific storage, clips/download manager entries where declared
3.8 Storage and media — READ_* / WRITE_* storage, READ_MEDIA_*, app‑specific storage, clips/download manager entries where declared
Topic
Detail
Why declared
Installers, backups, media pickers, and app caches inside the space.
How used
File operations serve user‑visible actions (install, export you start, open document).
User gate
Storage permissions and, on newer Android, photo picker / partial access where applicable; “All files access” is a separate explicit system grant (see §3.1).
3.9 Bluetooth, NFC, Wi‑Fi / nearby devices
3.9 Bluetooth, NFC, Wi‑Fi / nearby devices
Topic
Detail
Why declared
Headsets, file share, tap‑to‑pay style flows, and peripheral pairing inside cloned apps.
How used
Used when you initiate pairing or a feature that needs radio hardware.
User gate
Runtime Bluetooth / nearby‑device permissions on supported versions; NFC requires physical tap where relevant.
3.10 Accounts and credentials — GET_ACCOUNTS, AUTHENTICATE_ACCOUNTS, etc.
3.10 Accounts and credentials — GET_ACCOUNTS, AUTHENTICATE_ACCOUNTS, etc.
Topic
Detail
Why declared
Corporate or multi‑account apps inside the space.
How used
Account access follows your sign‑in flows inside those apps.
User gate
You choose whether to add or use an account in that app.
3.11 Internet — INTERNET and network state permissions
3.11 Internet — INTERNET and network state permissions
Topic
Detail
Why declared
App updates, AdMob, Play Billing, optional cloud features you turn on (e.g. backup to a provider you choose).
How used
Network is used for services you implicitly accept by using the app (ads, store purchases) and for features you explicitly use.
User gate
You can stop using online features; ads follow Google’s controls; purchases are confirmed by you in Play.
3.12 Notifications — POST_NOTIFICATIONS (Android 13+)
3.12 Notifications — POST_NOTIFICATIONS (Android 13+)
Topic
Detail
Why declared
Legitimate notifications (updates, sandbox status, errors).
How used
Shown through the system notification channel; user can disable in system settings.
User gate
OS notification permission prompt / settings.
3.13 Remote diagnostic logs (code path transparency)
3.13 Remote diagnostic logs (code path transparency)
Some builds may contain optional remote log upload hooks for support. In the current production configuration described for Play:
Remote upload is disabled at compile time (ENABLE_REMOTE_LOG_UPLOAD = false).
No upload destination is configured (getLogSenderChatId() returns null in the default client configuration).
Therefore diagnostic log packages are not sent to a publisher‑controlled URL in that configuration. If you ever enable support uploads for a debug or enterprise build, you must update this document and the Play Data safety form accordingly.
4. Why the full permission list is long (short explanation for reviewers)
4. Why the full permission list is long (short explanation for reviewers)
Android merges permissions from dependencies and from the virtualized app compatibility layer. Many lines mirror:
Google Mobile Services permission names (com.google.android.gms.permission.*) next to standard android.permission.* names for the same capability, and
OEM launcher / badge permissions so shortcuts and unread badges work across Samsung, Huawei, OPPO, etc.
That breadth is compatibility and declaration, not an indication that each line maps to a separate data‑collection pipeline in the host app.
5. Summary lines you can reuse in Play Console or policy UI
5. Summary lines you can reuse in Play Console or policy UI
User‑driven: Sensitive behavior is tied to actions you take (opening apps inside the space, granting system permissions, confirming purchases).
On‑device first: The app is built around local execution of the isolated environment on your phone.
No publisher sale of your content: We do not sell your personal content (messages, call history, contacts, etc.) to data brokers.
Google as infrastructure: Google Play and Google Mobile Ads may process data required for billing and advertising under Google’s terms — declare this separately in Data safety.
Restricted permissions: QUERY_ALL_PACKAGES is removed from the release manifest; visibility uses narrow queries.
12. Changes
12. Changes
We may update this Privacy Policy. The “Last updated” date will change and, for material changes, we may provide notice through the store listing or in-app where appropriate.
13. Contact
13. Contact
Albatros Engineering — Virtualize Apps (com.albatrosengineering.virtualizeapps)
Please use the official contact email and/or website shown on the Google Play store page for this application. If no website is listed, the Play developer contact is the primary channel.
Page updated
Google Sites
Report abuse