Android Fundamentals

Application Build
- The compilers convert your source code into DEX (Dalvik Executable) files, which include the bytecode that runs on Android devices, and everything else into compiled resources.
- The packager combines the DEX files and compiled resources into an APK or AAB, depending on the chosen build target.
- Here's the picture
- Before your app can be installed or distributed it must be signed. The packager signs your APK or AAB using either the debug or release keystore:
- The packager uses the zipalign tool to optimize your app to use less memory when running on a device.
- Read all about the build process.
Application Execution
- See this picture for details of the Android environment.
- Android Runtime (ART) uses special bytecode.
  - You cannot run standard Java byte code on ART.
  - You have to use the Android compiler to create this special byte code.
  - An .apk file is given to ART to be interpreted.
- Once installed on a device, each Android application lives in its own security sandbox:
  - Each application is a different user in the Linux system. The Linux user ID is used only by the system and is unknown to the application.
  - The system sets permissions for all the files in an application so that only the user ID assigned to that application can access them.
  - By default, every application runs in its own Linux process. Android starts the process when any of the application's components need to be executed, then shuts down the process when it's no longer needed or when the system must recover memory for other applications.
  - Each process has its own virtual machine (ART), so an application's code runs in isolation from other applications.
- There are ways for an application to share data with other applications and for an application to access system services:
  - An application can register a ContentProvider - see below.
  - It's possible to arrange for two applications to share the same Linux user ID, in which case they are able to access each other's files.
  - An application can request permission to access device data such as the user's contacts, SMS messages, the mountable storage (SD card), camera, Bluetooth, and more. All application permissions must be granted by the user.
An Android application can contain the following types of components:
- Activity - Represents the presentation layer of an Android application, e.g., a screen which the user sees. An Android application can have several activities and can switch between them during runtime of the application.
  - Views - The user interface of an activity is built with widget classes, which inherit from android.view.View.
  - The layout of the views is managed by android.view.ViewGroups.
- Content provider - provides data to applications. Via a content provider your application can share data with other applications. For example, Android contains a SQLite DB which can serve as data provider.
- Services - perform background tasks without providing an UI. They can notify the user via the notification framework. For example, a service might play music in the background while the user is in a different application.
- Broadcast receivers - receive system messages (e.g., "the battery is low") and implicit intents, and can be used to react to changed conditions in the system. They do not have a UI. An application can register as a broadcast receiver for certain events and can be started if such an event occurs.
Sharing components
- Any application can start another application's component. For example, your application can start the camera.
- When the system starts a component, it starts the process for that application. For example, if your application starts the camera, the camera component runs in the process of the camera application.
- Because the system runs each application in a separate process with file permissions that restrict access to other applications, your application cannot directly activate a component from another application. To activate a component in another application, you must deliver a message to the system that specifies your intent to start a particular component. The system activates the component for you.
Intents
- Intents are asynchronous messages that allow an application to request functionality from other services or activities.
- An application can call directly a service or activity (explicit intent) or ask the Android system for registered services and applications for an intent (implicit intents).
- Applications register themselves to an intent via an IntentFilter.