So Android leverages Linux user management to isolate apps.
Yeah, so this approach is different from user management in traditional Linux environments where multiple
apps are often run by the same user.
But here, Android creates a unique eweida for each Android app and then runs the app in a separate
process, so consequently each app can access its own resources only.
And this protection is enforced by the Linux kernel.
Generally, apps are assigned UID is in the range of 10000 and.
Ninety nine thousand nine hundred ninety nine.
Android apps receive a username based on their UID.
For example, the app with UID ten thousand one hundred eighty eight receives this username, you zero
underscore a one hundred eighty eight.
And if the permissions and app requests are granted, the corresponding group ID is then added to the
apps process.
So let's have a look at how sandboxing works.
So imagine you're downloading apps from Google Play.
These apps are executed in the Android application sandbox, which separates the app data and code execution
from the other apps on the device, right.
So the separation adds a layer of security.
Now, applications run under well-defined and constant UID.
Android does not have the traditional Etsy slash password file.
And it's just the are statically defined in the Android filesystem config header file advocation uid
is are also written to the data system packages list file.
Additionally, each application is given a dedicated data directory.
Which only has permission to read and write to.
If your applications are isolated or sandboxing both at the process level by having each run in a dedicated
process and add the file level by having a private data directory.
So this creates a kernel level application sandbox, which applies to all applications, regardless
of whether they're executed in a native or virtual machine process.