High ram usage and same process showing multiple times?

Question

I made a mediaplayer in Android Studio which uses a Service to control playback.

Now everything works fine and i don't notice any lag even though my logcat says 123 frames where skipped during startup.

I read somewhere that this message can be ignored if it doesn't exceed 300+ frames skipped, but now i'm not so sure anymore because i now read that even 1 frame skipped is too much.

I also compared the ram usage with a mp3 player from the store and i noticed most mediaplayers stay below 10mb memory usage.

But mine exceeds almost 50mb and i have no idea why but if you see at details you can see that there are processes with the same name and alot 'sandboxed_processes'.

So my question is if it's ok that my app almost consumes 50mb memory and what those 'sandboxed_processes' mean.

Answer 1

Question 1 :

it depends on how many resources your application are using and needing .you should really take memory seriously, and you should use as little as possible. Garbage collector will help you to recycle the allocated memory, but you should think about the lifespan of any instance of objects you create, and also about their design so to minimize the structures. Last but not least, Studio allows you to profile the memory allocation of your app, so use it :) .

Question 2 :

Application Sandbox from the official documentation

The Android platform takes advantage of the Linux user-based protection to identify and isolate app resources. This isolates apps from each other and protects apps and the system from malicious apps. To do this, Android assigns a unique user ID (UID) to each Android application and runs it in its own process.

Android uses this UID to set up a kernel-level Application Sandbox. The kernel enforces security between apps and the system at the process level through standard Linux facilities, such as user and group IDs that are assigned to apps. By default, apps can't interact with each other and have limited access to the operating system. For example, if application A tries to do something malicious, such as read application B's data or dial the phone without permission (which is a separate application), then the operating system protects against this behavior because application A does not have the appropriate user privileges. The sandbox is simple, auditable, and based on decades-old UNIX-style user separation of processes and file permissions.

Because the Application Sandbox is in the kernel, this security model extends to native code and to operating system applications. All of the software above the kernel, such as operating system libraries, application framework, application runtime, and all applications, run within the Application Sandbox. On some platforms, developers are constrained to a specific development framework, set of APIs, or language in order to enforce security. On Android, there are no restrictions on how an application can be written that are required to enforce security; in this respect, native code is as sandboxed as interpreted code.