Android applications can be written using Kotlin, Java, and C++ languages. The Android SDK tools compile your code along with data and resource files into an APK: an Android package, which is an archive file ending in .apk. One APK file contains all the contents of an Android application and is the file that Android devices use to install applications.<\/p>\n\n\n\n
Each Android app resides in its own security sandbox, which is protected with the following Android security features:<\/p>\n\n\n\n
The Android operating system is a multi-user Linux system in which each application is a different user.
By default, the system assigns a unique Linux user ID to each application (this ID is only used by the system and is not known to the application). The system assigns permissions to all files in the application so that only authorized user IDs can access them.
Each process has its own virtual machine (VM), so application code runs in isolation from other applications.
By default, each application runs in its own Linux process. The Android system starts the process when an app component needs to run, then kills the process when it’s no longer needed or when the system needs to recover memory for other apps to use.<\/p>\n\n\n\n
The Android system implements the principle of minimal privilege. This means that by default the application only has access to the components it needs to do its job and nothing more. This results in a highly secure environment where applications cannot access parts of the system without permission. However, there are several ways for apps to share data with other apps and for apps to access system services:<\/p>\n\n\n\n
Two applications can be set to use the same Linux user ID, in which case they can both access each other’s files. To save system resources, applications with the same user ID can also be set to run in the same Linux process and use the same VM. The application must also be signed with the same certificate
Apps can request access permissions to device data such as user contacts, SMS messages, removable storage (SD card), camera, and Bluetooth. The user must explicitly grant this permission. For more information, see Working with System Permissions.<\/p>\n\n\n\n
The next section of this document introduces the following concepts:<\/p>\n\n\n\n
The core framework components that define the application.
The manifest file where you declare the components and features your device needs for your app.
A resource that is separate from the application code and allows the application to optimize its behavior for various device configurations.<\/p>\n\n\n\n
Application components<\/strong><\/p>\n\n\n\n Application components are the essential building blocks of Android applications. Each component is an entry point where the system or user can enter your application. Some components depend on other components.<\/p>\n\n\n\n A<\/strong>ctivities<\/p>\n\n\n\n Activities are entry points for interacting with users. It represents a single screen with a user interface. Activities simplify the following important interactions between the system and applications:<\/p>\n\n\n\n Keep track of what’s important to the current user (what’s on the screen) to ensure that the system keeps the process hosting the activity running. You implement an activity as a subclass of the Activity class. For more information about the Activity class, see the Activity developer guide.<\/p>\n\n\n\n services<\/p>\n\n\n\n Services are versatile entry points to keep apps running in the background for all kinds of reasons. These are components that run in the background to perform long-running operations or to do work for remote processes.. Syncing data in the background or playing music also represents two different types of startup services, which modify how the system handles them:<\/p>\n\n\n\n Music playing is something that the user is directly aware of, so the app notifies the system by saying it wants to run in the foreground with a notification to notify the user of this; in this case the system understands that it must really try hard to keep the service process running, because the user will be unhappy if the service is lost.
Understand the processes that were used previously contain something that the user can return (the activity that was stopped), so prioritize keeping the process more a priority.
Help deal with apps stopping their processes so that users can return to activities with their previous state restored.
Provides a way for applications to implement flows between users, and for the system to coordinate these flows. (The most classic examples are being shared here).<\/p>\n\n\n\n
A regular background service is not something the user is directly aware of as a running service, so the system has more freedom in managing the process. This service may be allowed to shut down (and then restart later) if it requires RAM for more important things to the user.<\/p>\n\r\n