Android App Security · Storing Data Safely · Lesson 3 of 5

Backups & Logs

Find two quiet ways private app data leaves its sandbox: backups and logs.

Auto Backup and transfers

Private storage keeps other apps out, but the system itself can still copy an app's files. The biggest example is Auto Backup. For apps that target Android 6.0 or higher, Android backs up app data to a private folder in your Google account's Drive storage, up to 25 MB per app. Other apps and you can't browse it, and it doesn't count against your Drive space. On Android 9 and higher, with a screen lock set, the backup is end-to-end encrypted using your PIN, pattern or password.

By default the backup includes an app's settings files, its databases, the files/ folder in internal storage, and its app-specific external folder. It skips the cache/ folder and a special no_backup folder. When you set up a new phone, the data comes back.

Usually that's what you want. But a developer should think about what's in there. A saved login token restored onto another phone might sign that phone straight in. Data encrypted with a hardware-backed Keystore key won't help either, because the key stays behind on the old phone.

Developers control this in the manifest. android:allowBackup turns backup on or off, and it defaults to true. Backup rules files list what to include or exclude.

Android 12 split things in two. A cloud backup goes to Google Drive. A device-to-device transfer copies data straight from your old phone to the new one, for example over a cable. For apps that target Android 12 or higher, the old include and exclude rules no longer affect transfers, and a newer rules format has separate cloud-backup and device-transfer sections. Google also warns that on some manufacturers' phones, allowBackup="false" stops Drive backups but doesn't stop device-to-device transfers. So an app that must never move a file should exclude it in both sections.

What ends up in the logs

Android keeps a running system log called Logcat. The system and every app can write lines to it, like "Sync finished" or "Login failed, error 401". Developers read it while building an app, usually by plugging the phone into a computer with USB debugging turned on, or through a bug report, a bundle of diagnostic files that can include the log.

The trouble starts when an app writes something sensitive. A developer adds a quick debug line that prints the whole server reply, and it happens to contain a password, a session token or someone's email address. The line ships in the release version, and now that secret sits in the log for anyone who can read it.

Who can read it has narrowed over the years. Before Android 4.1, any app holding the READ_LOGS permission could read every other app's log lines. Since Android 4.1, only privileged system apps can be granted it, and an ordinary app can see just its own log lines. On Android 13 and later, when an app asks for all device logs for a use such as bug reporting, you get a prompt offering one-time access, which you can decline.

That's still not a reason to relax. Google's guidance points out that some pre-installed apps on some phones hold READ_LOGS. Bug reports get shared with support teams. Anyone with your unlocked phone and a cable can read the log through USB debugging.

Google's advice for developers is simple:

• Don't log sensitive data at all.
• Strip debug logging from release builds. A build tool called R8 can remove log calls automatically.
• If something must be logged, redact it, like showing a card as XXXX-XXXX-XXXX-1313. For passwords, show nothing.