Permissions and safety

Android keeps apps apart and lets each one do only what you allowed. This lesson covers how those permissions work, how to install an APK from outside a store without regretting it, what the destructive buttons really delete, and the checklist for putting a phone back the way you found it.

Three kinds of permission

Every app lists the permissions it wants in its manifest, inside the APK. Android treats them in three different ways:

Kind	Examples	How it is granted
Install-time (normal)	Internet access, vibration	Automatically, when the app is installed. No prompt
Runtime (dangerous)	Camera, microphone, location, contacts, photos, notifications	A pop-up the first time the app needs it. You can say no
Special app access	All files access, usage access, display over other apps, install unknown apps	Only on a page in Settings, which the app can open for you, but you flip the switch

Runtime permissions often offer While using the app, Only this time or Don't allow. Choose the narrowest that lets the app do its job. Android 11 and newer also take runtime permissions back from apps you have not opened for a few months.

Special access is kept for powers that are too broad for a quick pop-up: reading every file, seeing which apps you use, drawing over other apps. Android makes you go to a settings page on purpose.

A worked example: SpaceSweep

SpaceSweep frees storage by finding duplicates, junk and large files. Its permissions show each kind in action, and each one has a reason:

Permission	Kind	Why SpaceSweep needs it
All files access (Android 11+) or Storage (8 to 10)	Special access (runtime on older versions)	To read every file in shared storage to find duplicates, and to delete the ones you choose
Usage access	Special access	Android only tells an app how much cache other apps hold if it has usage access
List of installed apps	Install-time	To show app names and icons beside their cache sizes
Internet	Not requested	It has none, so nothing it reads can leave the phone

That last row is the habit to learn. When you grant a broad permission, look at what else the app can do. All files access plus internet access means an app could upload your files. All files access with no internet permission cannot. SpaceSweep explains each permission on its Permissions page; a trustworthy app tells you why it asks.

To review permissions on any phone, open Settings › Apps, choose an app, then Permissions. Special access has its own list, usually under Settings › Apps › Special app access; search Settings for All files access or Usage access if your phone puts it elsewhere.

Permissions over ADB

Testers often need an app in a known state: permission granted, or refused. ADB can set runtime permissions directly:

adb shell pm grant com.example.notes android.permission.CAMERA
adb shell pm revoke com.example.notes android.permission.CAMERA
adb shell dumpsys package com.example.notes      # long output; look for the permissions sections

pm grant only works for runtime permissions the app declares in its manifest. adb install -g, from lesson 2, grants all of them at install. Testing what happens when the user says no matters as much as testing the yes.

Sideloading safely

Sideloading means installing an app from an APK file instead of from an app store: with adb install, DroidDeck's Install APK, or by opening the file on the phone. On the phone, Android asks you to allow Install unknown apps for the app that opens the file, such as your browser or file manager. That switch is per app.

An APK gets the same powers as a store app, so the question is whether you trust the file. Three checks:

1. Get it from the source. Download from the developer's own site or their official release page, not from a mirror, a forum attachment or a "modded" copy. Modified APKs are a common way to spread malware.

2. Compare the checksum. Many projects publish a checksum, a SHA-256 value calculated from the file. If one byte differs, the checksum is completely different. On Linux:

   $ sha256sum notes-1.4.2.apk
   2a97516c354b68848cdbd8f54a226a0a55b21ed138e207ad6c5cbb9c00aa5aea  notes-1.4.2.apk

   Compare it with the value on the release page. If the project gives a checksum file, sha256sum -c checks it for you:

   $ sha256sum -c SHA256SUMS
   notes-1.4.2.apk: OK

   A changed or damaged file says FAILED instead. Do not install it.

3. Know the signature. Every APK is signed with its developer's key. Android only installs an update over an existing app when both are signed with the same key, which is why a different build fails with INSTALL_FAILED_UPDATE_INCOMPATIBLE. If you have the Android SDK build tools, apksigner verify --print-certs notes-1.4.2.apk prints the signing certificate's SHA-256 digest, which some developers publish so you can compare.

When you have installed the app, turn Install unknown apps off again for the browser or file manager you used.

What the destructive buttons delete

The buttons sound alike and do very different things:

Action	Command	What is lost
Force-stop	adb shell am force-stop	Nothing stored. Work the app had not saved yet
Clear cache (in phone Settings)		Only the cache: thumbnails and temporary files the app rebuilds
Clear data / Clear storage	adb shell pm clear	Everything the app stored privately: sign-ins, settings, databases, offline files. The app is as if newly installed
Uninstall	adb uninstall	The app and all its private data

Two things surprise people. First, files an app saved to shared storage, such as photos in DCIM or files in Download, are not removed by clear data or uninstall. Second, data an app keeps in its own online account comes back when you sign in again; data kept only on the phone does not.

None of these can be undone. DroidDeck asks before Clear data… and Uninstall…, and runs Force-stop at once; see Manage apps. On a phone, clearing storage in Settings is equally final. SpaceSweep's cache guide shows the safe choice, Clear cache, beside the dangerous one.

Stay safe

The checklist for whenever you have finished debugging a phone:

1. Switch off network debugging. Run adb usb or select Revert to USB if you used tcpip, and turn Wireless debugging off.

2. Undo test changes. If you changed the screen size or density, reset them (adb shell wm size reset and adb shell wm density reset, or Reset in DroidDeck's Shell tab). Put back any permissions you granted or revoked for a test.

3. Revoke old authorisations. In Developer options, select Revoke USB debugging authorizations now and then, and always after connecting to a computer that is not yours. Remove computers you no longer use from Paired devices under Wireless debugging.

4. Turn Developer options off with the switch at the top of that menu when you do not need it. It turns USB debugging off with it.

And the rules that do not change:

• Never authorise a computer you do not own or trust, including public charging stations and shared lab machines.
• Only debug devices that are yours or that you have permission to test. ADB on someone else's phone gives you their messages, photos and accounts.
• Back up before anything permanent. Pull files, export logs, extract an APK. Uninstall, clear data, delete and logcat -c have no undo.

Check yourself

QuizPermissions and safety

Question 1 of 6

How does an app get All files access on Android 11 and newer?

Score: 0

What you learned

• Permissions come in three kinds: install-time, runtime pop-ups, and special access set on a Settings page.
• Look at the whole set: broad file access plus internet access is a very different risk from file access alone.
• Sideload from the official source, compare the SHA-256 checksum, and remember updates must carry the same signature.
• Clear data and uninstall delete an app's private data for good; files in shared storage stay.
• When you finish, close network debugging, undo test changes, revoke authorisations and turn Developer options off.

Next steps

• The DroidDeck lab: put the whole track into practice
• SpaceSweep permissions
• Manage apps in DroidDeck