Android applications generate a wide range of digital artefacts, including SQLite databases, shared preferences, application logs, cached files, configuration data, and system records. These artefacts can help investigators reconstruct user activity, identify suspicious application behaviour, establish event timelines, and determine whether sensitive information may have been accessed or transferred.

However, extracting application data from Android devices is not always straightforward. Android's application sandbox, file-based encryption, scoped storage, and access restrictions limit what can be collected from a standard device.

A reliable investigation therefore requires a structured approach to evidence acquisition, database analysis, log interpretation, timestamp normalisation, and forensic validation.

This article explains how analysts can identify, extract, and interpret Android application artefacts while preserving evidence integrity.

1. Understanding Android Application Storage

Android applications store information in several locations depending on the application's design, permissions, and Android version.

Understanding these locations is the first step in determining which artefacts may be available during an investigation.

1.1 Internal application storage

An application's private data is commonly stored under a directory such as:

/data/user/0/<package.name>/

On many devices, /data/data/<package.name>/ may refer to the same application data location.

Depending on the application, this directory may contain:

• databases/ — SQLite databases and related database files.

• shared_prefs/ — XML-based preferences and configuration.

• files/ — Application-specific files.

• cache/ — Temporary application data.

• no_backup/ — Data excluded from certain backup mechanisms.

These directories are protected by Android's application sandbox. An ordinary application or unauthorised ADB session generally cannot access another application's private data.

Access may require an application-specific export, a supported backup mechanism, an authorised forensic acquisition method, or a suitably privileged device. Rooting a device solely to obtain access can alter evidence and should not be treated as a routine first step.

1.2 Shared and externally accessible storage

Applications may also store files in shared storage or app-specific external directories.

Potential artefacts include downloaded documents, exported reports, images, media, attachments, and cached files.

Modern Android versions restrict access to shared storage through scoped-storage controls. The presence of a file in shared storage does not necessarily mean every application can access it.

Investigators should record the original path, filename, size, timestamps, and acquisition method wherever available.

1.3 System and package metadata

Android maintains information about installed packages, application versions, permissions, and other operating-system state.

Relevant sources may include:

• Package-manager information.

• Application installation and update records where available.

• Permission grants and app-ops state.

• Accessibility-service configuration.

• Device logs and crash records.

• Network usage statistics.

• Relevant backup or enterprise-management records.

These sources provide context for interpreting application data, but their availability and retention vary across devices and Android releases.

2. SQLite Database Forensics

SQLite is widely used by Android applications because it provides a lightweight, local database engine.

Messaging applications, browsers, note-taking tools, authentication applications, and business utilities may use SQLite to store structured records. The database schema and retained information depend entirely on the application.

2.1 Identifying SQLite databases

During an authorised acquisition, investigators should identify files with SQLite database structures rather than relying exclusively on filename extensions.

A database may have a conventional name such as history.db, messages.db, or appdata.db, but filenames are not reliable indicators of content.

Record:

• Original path and filename.

• File size and cryptographic hash.

• Database header and format.

• Acquisition time and method.

• Related files collected with the database.

• Any access restrictions or collection errors.

Do not assume that every file named .db is SQLite or that every SQLite database has a .db extension.

2.2 Understanding database structure

A SQLite database contains tables, columns, indexes, and potentially views and triggers. Investigators should inspect its schema before interpreting records.

Useful initial queries on an acquired copy include:

-- List tables and views SELECT name, type FROM sqlite_master WHERE type IN ('table', 'view') ORDER BY type, name;

To inspect a particular table, first identify its columns:

PRAGMA table_info('messages');

The table name messages is only an example. Replace it with the actual table identified during analysis.

Once the schema is understood, analysts can examine relevant records, relationships, and timestamps without making assumptions about the application's internal data model.

2.3 Analysing records and relationships

A database may contain records representing messages, user actions, contacts, application events, downloaded content, or synchronisation state.

A useful workflow is to:

1. Identify relevant tables and columns.

2. Determine primary keys and relationships.

3. Examine representative records.

4. Identify timestamp fields and their formats.

5. Compare records with related files and logs.

6. Document missing, deleted, or inconsistent records.

7. Validate interpretations against independent evidence.

A database record may represent an attempted action rather than a completed one. For example, a queued upload record does not independently prove that the upload reached an external server.

2.4 WAL and journal files

SQLite may use write-ahead logging (WAL) or other journaling mechanisms to support database consistency.

When WAL mode is active, relevant files may include:

• database.db

• database.db-wal

• database.db-shm

The WAL file can contain changes not yet checkpointed into the main database. The shared-memory file supports coordination between database connections.

Collect related files together where possible. Acquiring only the main database may omit relevant recent transactions.

Do not manually combine or modify original database files during examination. Use a forensic working copy and appropriate SQLite-compatible tooling. Record any recovery or reconstruction operation performed.

2.5 Deleted records and remnants

Deleted records may sometimes be recoverable from unallocated database pages, freelist pages, WAL files, journal files, or remnants in other artefacts.

Recovery is not guaranteed. Records may have been overwritten, securely removed, checkpointed, encrypted, or never persisted to disk.

Investigators should distinguish between:

• A record currently present in the database.

• A record recovered from a journal or WAL file.

• A partial remnant with incomplete context.

• A record inferred from corroborating evidence.

Recovered remnants require careful validation before they are presented as definitive evidence of user activity.

3. Shared Preferences and Configuration Artefacts

Android applications commonly use shared preferences to store small amounts of key-value data, often represented in XML files.

Depending on the application, these files may contain settings, feature flags, onboarding state, cached identifiers, or session-related configuration.

Example structure:

<map> <boolean name="notifications_enabled" value="true" /> <string name="theme">dark</string> </map>

This is an illustrative example, not evidence from a real application.

What investigators should examine

• Preference names and values.

• File modification times, where reliable.

• Changes that correlate with suspicious activity.

• References to unexpected endpoints or configuration.

• Application identifiers or state markers.

• Differences between acquired versions, if available.

Sensitive tokens and credentials may sometimes be stored insecurely, but analysts must not assume that every preference file contains them. Modern applications may use encrypted storage, Android Keystore-backed keys, or other mechanisms.

A preference value indicating that a feature is enabled does not necessarily prove that the feature executed successfully.

4. Application Logs and Runtime Evidence

Logs can provide useful context about application execution, errors, network failures, authentication attempts, and background operations.

However, Android logging is not a complete record of everything an application does.

4.1 Logcat

Android's logging system can be queried through ADB when the device and debugging configuration permit it.

An example command is:

adb logcat -d -v threadtime > logcat.txt

This writes the available log-buffer contents to a local file on the computer running ADB.

The output may contain timestamps, process identifiers, thread identifiers, priorities, tags, and messages. Actual fields and formats depend on the selected output format and Android version.

Important limitations:

• Logs may have rotated or been overwritten.

• Some messages may never have been logged.

• Access to particular buffers or messages may be restricted.

• Sensitive information may be redacted.

• Applications can use their own logging systems or omit useful messages.

• Collecting logs from a live device may not reproduce its earlier state.

Preserve the original collected output, calculate a hash, and document the collection command and time.

4.2 Crash logs and diagnostic artefacts

Crash reports and diagnostic records can help explain when an application failed, which component was involved, or whether a suspicious execution sequence coincided with an error.

Potential sources include application-specific crash reports, Android diagnostic output, and authorised bug reports.

A crash does not itself indicate malicious activity. It becomes more significant when it coincides with other indicators, such as unexpected permission changes or suspicious outbound connections.

4.3 Application-generated logs

Some applications maintain their own event logs, diagnostic files, or audit databases.

These may contain more application-specific information than system logs, but their reliability depends on how they were implemented. Applications may truncate logs, change their format, omit events, or delete records.

Treat application-generated logs as one evidence source among several rather than as an independently complete audit trail.

5. Analysing Other Android Artefacts

Databases and logs are only part of the investigative picture.

5.1 Cache and temporary files

Cached content can provide clues about previously accessed material, downloaded resources, thumbnails, or temporary processing.

Cache files are often volatile and may be cleared automatically. Their absence does not prove that the associated activity never occurred.

5.2 Browser artefacts

Depending on the browser and acquisition method, available artefacts may include browsing history, downloads, cookies, session state, and cached content.

These records can help establish whether a user visited a suspicious website or downloaded an APK.

A browser history entry proves that a navigation record exists; it does not necessarily prove that a download completed or that a downloaded application executed.

5.3 Application installation and permission history

Where available, package and permission records can help establish the relationship between installation, capability grants, and subsequent activity.

Correlate these records with application databases and network telemetry to investigate whether suspicious behaviour began after a new application was introduced.

5.4 Notifications and accessibility configuration

Notification-listener and accessibility settings can be important in investigations involving credential theft, unauthorised monitoring, or surveillance.

Determine which services were enabled and whether their configuration is consistent with the application's stated purpose. Historical records may be limited, so current configuration alone may not reveal past states.

5.5 Network and usage artefacts

Android network statistics, VPN logs, DNS records, proxy telemetry, and firewall events may help establish when an application communicated externally.

Network attribution can be difficult when traffic is encrypted or multiple applications share network infrastructure. Correlate timestamps and available process or UID information with other evidence before attributing a connection to a particular application.

6. Evidence Acquisition and Preservation

A technically correct analysis can still be unreliable if the acquisition process is poorly documented.

Step 1: Establish authority and scope

Confirm that the device and relevant application data are within the authorised investigation scope. Document the case reference, device details, examiner, and reason for collection.

Step 2: Record the device state

Document the device model, Android version, visible state, network connectivity, time settings, and relevant security configuration.

Avoid unnecessary interactions that may change application state or trigger synchronisation.

Step 3: Select an appropriate acquisition method

The acquisition method depends on device access, encryption, lock state, application sandbox restrictions, and the legal authority for collection.

Possible sources include application exports, supported backups, enterprise-management exports, logical acquisition, and more advanced forensic methods where authorised and available.

No single method guarantees complete access to every Android application artefact.

Step 4: Preserve original evidence

Maintain original acquired files and perform analysis on working copies.

Where technically appropriate, calculate SHA-256 hashes:

sha256sum acquired_database.db

Hash the associated WAL and journal files separately as well. A matching hash establishes that two files are byte-for-byte identical; it does not by itself prove that the original acquisition was complete or accurate.

Step 5: Document limitations

Record inaccessible directories, unavailable logs, missing files, encryption barriers, unsupported extraction methods, and any changes made during collection.

These limitations matter when interpreting what the evidence can and cannot establish.

7. Reconstructing a Forensic Timeline

A timeline can connect database entries, log events, file metadata, and network observations into a coherent sequence.

For example, an investigation might identify:

Time (UTC)ArtefactPossible significance09:12:03Application installation recordPossible introduction of the application09:15:27Permission-related eventPotential access to a sensitive capability09:18:41Application database entryPossible recording of an application event09:19:02Outbound network connectionPossible external communication09:20:10Application log entryAdditional context for the activity

These times are illustrative and do not describe a real incident.

Timestamp normalisation

Android artefacts may use different timestamp formats, including Unix seconds, Unix milliseconds, formatted local time, or application-specific representations.

Investigators should:

1. Identify the timestamp format for each source.

2. Determine whether it represents UTC or local time.

3. Convert values consistently.

4. Account for device clock drift where possible.

5. Preserve original values alongside converted timestamps.

6. Record the uncertainty associated with each event.

A timestamp from an application database may represent creation time, update time, server time, or synchronisation time. Its meaning must be established from the schema and application behaviour.

8. Practical Investigation Example: Suspicious Data Collection

Consider a hypothetical case in which an employee reports that an unfamiliar Android application appeared shortly before unusual account activity.

The objective is to determine whether the application accessed sensitive information and whether any information was transmitted externally.

Investigation approach

First, examine package metadata. Record the package name, signing certificate, installation information, and requested permissions. Determine whether the application came from an expected source.

Next, inspect available application data. Review databases, preference files, cached artefacts, and application-specific logs for relevant records. Preserve SQLite WAL and journal files when present.

Then, analyse runtime and permission evidence. Establish which capabilities were granted and identify evidence of relevant application activity. Avoid equating a permission grant with successful data collection.

Finally, correlate network telemetry. Compare the application timeline with DNS, VPN, firewall, or proxy events. Investigate whether an external transfer occurred and whether the destination can be linked to the application with sufficient confidence.

What would support a finding?

A stronger finding would combine application-specific records indicating data collection, reliable timestamps, evidence linking the application to an outbound connection, and network telemetry consistent with the suspected transfer.

If only the application's permissions and a suspicious domain are available, the appropriate conclusion is that the activity warrants further investigation—not that exfiltration has been confirmed.

9. Common Forensic Mistakes

Several mistakes can weaken an Android application-data investigation:

• Collecting only the main SQLite file: Recent transactions may remain in WAL or journal files.

• Assuming filenames describe content: A database or cache file may contain unexpected information.

• Treating logs as complete: Android logging is subject to retention, filtering, and access restrictions.

• Ignoring encryption: Some application data may be encrypted or dependent on keys unavailable to the examiner.

• Misinterpreting timestamps: Seconds, milliseconds, local time, and UTC can produce misleading event sequences.

• Confusing capability with activity: A granted permission establishes potential access, not necessarily use.

• Overstating recovered records: Partial remnants may lack enough context to establish an event conclusively.

• Failing to preserve acquisition details: Without hashes, collection records, and documented limitations, results are harder to reproduce and defend.

10. Building a Repeatable Android Forensics Workflow

A consistent workflow improves reproducibility across cases.

1. Scope: Define the device, application, incident questions, and authority to collect.

2. Acquire: Use an appropriate, documented method and preserve relevant files.

3. Validate: Record hashes, inspect file structures, and check acquisition completeness.

4. Parse: Examine SQLite databases, XML preferences, logs, caches, and package metadata.

5. Correlate: Connect application records with system and network evidence.

6. Timeline: Normalise timestamps while preserving original values.

7. Assess: Separate confirmed observations from hypotheses and unresolved questions.

8. Report: Explain the method, evidence, findings, limitations, and confidence level.

Conclusion

Android application data extraction is a foundational skill in mobile digital forensics. Databases reveal structured application records, logs provide runtime context, and supporting artefacts can help reconstruct installation, access, and communication activity.

The reliability of an investigation depends on more than finding a suspicious file. Analysts must understand Android's storage and access restrictions, preserve related database files, validate timestamps, and correlate evidence from independent sources.

A defensible forensic report distinguishes what was directly observed from what is inferred. By following a repeatable acquisition and analysis process, investigators can produce findings that are technically sound, transparent, and useful for incident response.

Further Reading

• Android Developers — Data and File Storage: https://developer.android.com/training/data-storage

• Android Developers — Android Debug Bridge: https://developer.android.com/tools/adb

• SQLite Documentation: https://www.sqlite.org/docs.html

• Android Open Source Project — Security: https://source.android.com/docs/security

• NIST — Mobile Device Forensics, SP 800-101 Rev. 1: https://csrc.nist.gov/pubs/sp/800/101/r1/final

• MITRE ATT&CK Mobile: https://attack.mitre.org/matrices/mobile/