See what an app or an extension asks for MANIFEST

Read the package, not the store listing

A store listing is marketing. The package is a statement of fact: it contains the exact list of permissions the system will grant, the exact set of components other applications can reach, and the actual code. Those three things are what the software can do, whatever the description on the page says it does.

The gap between them is where the interesting cases live. A torch that asks for contacts. A keyboard with network access. A browser extension whose listing mentions one site and whose manifest.json asks to read and change data on every site you visit. An extension that was honest for two years, changed hands, and shipped an update with a wider permission set that nobody read because updates install silently.

Everything here happens in the tab. That matters for a package you are suspicious of: uploading a possibly malicious APK to a scanning service is a reasonable thing to do and it is also a thing you may not be allowed to do, with a client's application, a pre-release build, or anything under an agreement.

What is actually read out of an APK

An Android APK is a zip, and its AndroidManifest.xml is not text. It is the binary XML that aapt writes: a string pool, a table of resource ids, and a stream of start and end element chunks. That is decoded here by hand, because nothing on the shelf does it in a browser and the format is small and stable enough to be worth writing.

From it: the permission list, which is what the system will grant; the exported components, which say what other applications on the device can reach without asking you. Then the string tables of the classes*.dex files, which name every class the application links, and that is where an analytics or advertising SDK gives itself away, because it cannot be used without being named. The same tables carry every address the code holds as a constant, so you can see what it is built to talk to.

An XAPK or APKS bundle is a zip of APKs and the base one carries the manifest. A Chrome or Edge extension is a zip behind a CRX header, a Firefox add-on is a plain zip, and both carry a manifest.json that says in readable text what it wants.

Reading the result without frightening yourself

Permissions are claims about capability, not evidence of behaviour. A messaging app legitimately needs contacts, the microphone and the camera, and a photo editor legitimately needs storage. The question is never “is this permission alarming” but “does this permission have an explanation in what the app is for”.

So work from the purpose inwards. Write down what the app claims to do, then read the list and account for each entry. The ones you cannot account for are the finding: READ_SMS in a game, ACCESS_FINE_LOCATION in a calculator, REQUEST_INSTALL_PACKAGES in almost anything. For an extension, <all_urls> and webRequest together mean it can read and alter every page you load, including your bank.

The named SDKs and the hardcoded addresses answer the other half: not what it may do, but who it is in touch with. A free application with four advertising SDKs is not free, and the price is in that list.

Related: X-RAY reads what a file really is, MACROLENS shows the macros inside an Office document, DISARM removes the parts of a document that run, and POLICYLENS reads the privacy policy that is supposed to describe all of this in words.