Checking browser support…
Take an installed app's APK back off the phone over the cable — base and every split — then read its manifest, permissions and signature without leaving the page.
The APKs stream from the phone straight into the file you picked. Nothing is uploaded, and the analysis runs in this tab.
Checking browser support…
Every app on an Android phone is a file on that phone, and adb can read files. This page uses that: pick an installed app, and its APK is pulled over the USB cable into a file you choose — no root, no app installed on the phone, nothing uploaded anywhere. An app that ships as a split bundle comes back as one .apks container with all of its parts and a table of contents describing them, and any app can be analyzed here in place: permissions, signature, SDK levels, DEX and resource statistics, native libraries.
Root is needed to read *other apps' data* — databases, preferences, files under /data/data. The APK itself is not data, it is the installed artifact, and it lives in a world-readable place: /data/app/~~<random>/<package>-<random>/base.apk for anything installed from a store or sideloaded, /system/app or /product/app for what came with the phone. The shell user can traverse those directories and read the files, which is why adb pull of an APK has been a working recipe for over a decade. What this page adds is finding the paths for you (pm path <package>, which prints every file of the package including the splits), naming the output after the package and its version code, and packing a split set into something installable rather than a folder of loose files. It is worth being honest about the limit: the readability of /data/app is a convention, not a documented guarantee, and hardened or heavily modified builds do refuse. When yours refuses you will see the message the phone itself printed.
An app built as an Android App Bundle is installed as several APKs at once. base.apk holds the manifest, the code (classes*.dex), the resource table and everything not specific to a device. Beside it sit configuration splits: split_config.arm64_v8a.apk with the native libraries for one CPU architecture, split_config.xxhdpi.apk with the drawables for one screen density, split_config.en.apk with one language's strings. Feature splits add on-demand modules. The phone only installed the splits that match *it*, which is the first thing to understand about copying them elsewhere: what you extract is not a universal APK, it is the exact set that suits this phone. That is also why the base alone will usually install and then crash on first launch — the code is there, the library it loads is not.
Two things decide it. The **signature** travels with the APK, so the app installs as the same identity it had; that also means it cannot be installed over a copy of the same app signed by someone else, and Play may later replace it with its own build. The **split set** is the harder part: install the whole .apks and the parts are all there, but if the destination phone has a different CPU architecture or a much different screen density, the splits it got do not describe it, and the app can start and then fail to find its libraries. Installing a set is also not a pm install <file> — it is a session (pm install-create, one install-write per APK, install-commit), which is what the APK Installer page here does for you. Finally, apps distributed through Play with license verification or Play Integrity checks may refuse to run when they see they were not installed by the store, however intact the copy is.
.apks is bundletool's output format: a ZIP holding the APKs of one app plus a toc.pb that says which one is the master split and what each other one targets. That metadata is the reason the format exists — a folder of files loses which APK is the base and which architecture a split is for, and a filename is a guess. The container this page writes has the same shape: the pulled APKs under splits/, and a toc.pb we generate from what the phone reported, so the APK Installer page here classifies the splits from the metadata rather than from names. It is stored, not compressed (APKs are already compressed archives), and it is written to disk while the phone is still being read, so a 900 MB game does not have to fit in the browser's memory. It is our own container read by our own tools: it is not claimed to be byte-identical to bundletool's output, and other installers may or may not accept it.
Nothing on this page writes to the phone. Extraction is reads only — list the packages, ask for the paths, read the files — so there is no confirmation to click through, because there is nothing destructive to confirm. From here, the APK Analyzer takes an APK from your own disk and can compare two versions, the APK Installer sends packages the other way, and the Web ADB hub has the device dashboard and the rest of the toolkit.
Connect the phone with USB debugging on, press "Select all user apps" (that is the third-party list, so preinstalled software is left out), then "Choose a folder and extract". You pick one folder on your computer and each app is written into it as its own file — `<package>-<versionCode>.apks` for a split app, `.apk` for a single one. Apps are handled one at a time and each result is reported separately, so an app the phone will not let the shell read is a line in the report rather than a failed backup. To put them back, drop the files onto the APK Installer page on the new phone.
Three reasons, and the page tells you which. The `shell` user may not be allowed to read the app's directory — normal on some hardened and OEM builds, and the phone's own error is shown. `pm path` may print nothing, which happens for an app installed only in a work profile or for another user, since this page asks about user 0. Or the file may not be a plain APK at all: `pm path` can also list `.dm` dex-metadata sidecars, which are skipped because putting one in the container would make it fail to install. An app whose APKs add up to more than a classic ZIP can address (4 GiB) is also refused rather than written out as an archive that some tools open and others call corrupt.
Most often because it is a split app and only the base was installed: the code is there but the native libraries and resources for that device are in the config splits. Install the whole `.apks` through a tool that opens an install session (the APK Installer page here does), not by handing the base to the system installer. The next most common cause is a signature conflict — the same package is already installed from a different source — which needs the existing copy removed first. And a phone with a different CPU architecture may simply not be described by the splits this phone got.
Technically the file copies like any other. Whether you may keep or move it is a licence question, not a technical one: buying an app buys a licence to use it, usually tied to the account that bought it, and the licence terms — not this page — decide what copying is permitted. Making a backup of software you licensed, for your own use on your own device, is a normal thing to do and is what this page is for. Distributing an APK to other people is not, and many paid apps also check with Play at runtime and will refuse to start when they were not installed by the store, so a copy passed to someone else tends not to work anyway. This page will not help with license bypassing, and there is nothing here that removes a signature or patches a check.
Device dashboard, shell drawer and every other Web ADB tool.
The same report over an APK from your disk, plus version comparison.
Send an .apk, .apks, .xapk or .apkm back to a phone.
Remove or disable preinstalled apps, with a restore list.