How RAM usage works in Android DAPs

RAM memory in Android DAPs (Digital Audio Players) has been a recurring concern. The reason for this is the pursuit of a smoother experience when using music apps or simply navigating the operating system. However, the amount of RAM may not be as critical a limitation as most users think.
Music streaming apps such as Spotify, Apple Music, and Tidal do not require a large amount of RAM. If only one app is opened at a time, 3 GB of RAM is unlikely to critically limit navigation smoothness or track playback.

That said, there are factors that lead to higher RAM consumption. Google apps and Android services/features can affect the smoothness of system navigation and music apps. If the Digital Audio Player manufacturer does not optimize these elements, performance issues may occur.

In addition, using a newer version of Android generally results in better RAM utilization. However, it is necessary to evaluate driver compatibility to ensure proper hardware and software operation, as well as the higher processing power required to run new operating system features.

How does Android manage app execution?

The component responsible for managing app execution on Android is the ActivityManagerService (AMS). It handles the lifecycle of activities and services, adjusts the priority of each process, and works together with the LMKD (Low Memory Killer Daemon) to terminate processes when available RAM is low.

The LMKD is responsible for monitoring RAM usage and deciding which processes should be terminated. Its goal is to maintain operating system stability. To do this, the Low Memory Killer Daemon uses the following mechanisms:

• RAM monitoring: uses memory information and can be configured to act based on the vmpressure level (memory pressure level), classified as low, medium, or critical.
• Configurable thresholds: process termination is based on memory thresholds (low memory thresholds), defined in lowmemorykiller policies. Limits are set according to the amount of free memory or vmpressure levels.
• Process prioritization (OOM score): each process has an OOM (Out Of Memory) score calculated based on its importance and priority. The LMKD will terminate processes with a higher OOM score (less critical to system stability).
• PSI (Pressure Stall Information): the LMKD uses PSI data.

PSI measures the time during which the system is stalled due to insufficient resources (available CPU, sufficient RAM, or available read/write bandwidth). In practice, it helps prevent performance drops, stuttering (jank/stutter), and FPS drops, improving overall responsiveness. To achieve this, it monitors three main resources.

The OOM score (Out-Of-Memory score) is the metric used by LMKD in Android to determine which processes should be terminated first when available RAM is low. The higher the score, the greater the chance that the process will be killed.

Android assigns the OOM score based on the process priority level (adj) and the amount of memory used.

The adj (adjustment level) is how Android classifies processes according to their importance to the user and the system. It determines which process should be protected or discarded first when available memory is low.

There is a hierarchy for adj levels, which works as follows:

• adj “-1000” – Critical system processes that should never be terminated – OOM score “-1000”
• adj “0” – Foreground app or service (Foreground Service or FGS) actively interacting with the user – OOM score “0”
• adj “1” – Visible app, visible but not directly interacting – OOM score “100”
• adj “2” – Perceptible app (indirectly, such as playing music) – OOM score “200”
• adj “3–6” – Background services – OOM score “300–600”
• adj “7–8” – Previous app or last app used before the current one – OOM score “700–800”
• adj “9” – Cached app, not currently in use – OOM score “900”
• adj “15” – Empty app, with no active activities or services – OOM score “1000”

Every time the user switches apps, the adj value is automatically recalculated in real time.

What happens when we open a music app on Android?

When a music app is opened on Android for the first time, it is classified as a foreground app. This causes the AMS to set the adj and OOM score to “0.” As a result, the app has high priority and the LMKD will not kill it.

When you turn off the screen but keep the music app playing a track, the AMS sets the adj to “1” (visible app) or “2” (perceptible app), with an OOM score of 100 or 200, depending on the case. In this way, the music app remains active unless the system needs to free memory.

When music playback is paused and there is no interaction with the music app for a certain period, the process type changes to “background services.” This causes the AMS to reduce the adj to a level between 3 and 6, and the OOM score to something between 300 and 600. At this point, the process may be selected for termination if the system needs to free memory.

More control over foreground and background apps in Android 13

Android 13 introduced a new feature called the FGS Task Manager (Foreground Services Task Manager), which gives users more visibility and control over apps that run long tasks in the background, even if they are technically running in the foreground.

The FGS Task Manager was introduced in response to some apps that use foreground services to keep themselves alive indefinitely, bypassing Android’s background activity restrictions.

This results in a notification being shown to the user whenever an app runs foreground processes for an extended period (usually more than 20 minutes). In addition, the user has the option to stop these apps directly without having to open the settings menu.

Differences in AMS behavior in Android 10, 12, and 13

Most Android DAPs currently on the market use Android 10, Android 12, or Android 13. Newer versions of the operating system feature an improved ActivityManagerService (AMS), resulting in smarter resource usage and a smoother user experience. See the differences below.

Process management (adj/OOM)

• Android 10: More basic, with priorities by type (foreground, background, etc.).
• Android 12: More refined, with better differentiation between background types.
• Android 13: More dynamic adjustments, considering more context and real usage state.

Foreground apps (Foreground Services or FGS)

• Android 10: No specific category for this type of app.
• Android 12: Introduced service types (MEDIA_PLAYBACK, LOCATION, etc.).
• Android 13: Mandatory type validation + FGS Task Manager (user control).

Notifications and influence on adj

• Android 10: Notifications keep the process alive, regardless of importance.
• Android 12: Same behavior as Android 10.
• Android 13: Low-priority notifications no longer guarantee a high adj level.

Management of inactive processes

• Android 10: Basic, reactive.
• Android 12: Improved tracking via Watchdog and GC.
• Android 13: Proactive, with more accurate detection of useless processes and faster cleanup.

Resource usage monitoring

• Android 10: Basic statistics (battery/CPU).
• Android 12: More metrics, integration with BatteryStats.
• Android 13: AMS actively participates in decisions to keep or kill processes due to excessive consumption.

User control over active processes

• Android 10: Limited.
• Android 12: Light indication via notifications.
• Android 13: FGS Task Manager shows running processes and allows direct termination.

Conclusion

More recent versions of Android have gained improvements related to resource management (RAM, CPU and GPU processing, and internal or external storage read/write operations). Combined with the optimizations implemented by Digital Audio Player (DAP) manufacturers—as explained in this article—the user experience tends to be good, even when using an older chipset (“processor”).