Android applications are written in the Java programming language and compiled using the Android SDK tools. A compiled app will include all data and resource files packed together in one package, which will be a single file with an .apk extension. That single file is the full Android application and is what devices will use to install the app.
Installed apps live in their own little sandbox on the device. This way is something goes wrong with one, it’s unlikely to break out of its sandbox and affect other apps. The easiest way to envision this is to imagine a Windows or *Nix computer which has several users, each with their own login. Every Android app is another one of those users, but one user can’t access the information another has without permission, keeping them separated. Even if several people are logged into that computer at once, they’re all unaware of the others as they are on their own virtual machine.
Android gives each app, by default, the lowest level of privileges for access. With each app running on its own Linux user ID within the device, however, they cannot easily talk with one another. To make this happen, apps that need to communicate or share data are given the same user ID, and are thus running in the same “sandbox.” Some data, such as device data, is available to all apps with permissions, regardless of user ID. This includes SD card contents, device APIs for camera, Bluetooth, and so forth, as well as the user’s contacts and SMS messages. Apps can also detect whether services are currently in use, such as whether the user is using the mobile phone or already using the camera with another app.
Every Android app has basic components, called Application Components. These are the basic building blocks of the app and each one of them is a point through which the system can enter the application – whether by sending data through an API or by direct user request. There are four types of App Comps: Activities, Services, Content providers, and Broadcast receivers.
An Activity is a user interface screen component (usually a single screen as part of a larger GUI). A phone’s SMS app, for example, might have an Activity used to launch the creation of a new message and another for reading incoming messages. The user could select one or the other or other apps, such as the Gallery viewer for photos taken with the camera, might launch the new message Acvitiy to send a photo to a friend.
Services are components that run in the background to perform long-running operations or remote processes work. These do not have a user interface, as they are meant to run without user intervention. For example, your phone’s music player likely has a Service that keeps the music playing in the background, even after you’ve closed the music player app in order to read email or surf the Web. Services can be launched through Activities or bound to apps through them.
A Content provider manages application data. Any storage option the app can access, such as the SD card or an online system, will be accessed through a Content provider. This can be app-only data that is not accessible by other apps on the device, such as the app’s configuration files. The Content provider also acts as the manager to allow other apps to access the same data. Several built-in Content providers in Android, for example, provide things like the contacts list (ContactsContract.Data). There are a standard set of APIs for Content provider transactions that every developer should become familiar with.
Finally, apps will have Broadcast receivers, which are system-wide broadcast announcement handlers. When certain global (to the device) events take place, such as the screen going dark or the WiFi being disabled, the Android system will send a broadcast message to every active app to tell them about the change. At the same time, apps themselves can broadcast to others about certain things, such as new common data downloaded or created. Most of the time, these broadcasts happen in the background, but a few of them will issue a status bar notification.
One of the great things about Android is that components can be shared, making many of the developer’s tasks easier. For example, if your app uses the camera to snap photos or record video, most devices will already have an app to do that and those components will be broadly known and are usually standardized. This means you won’t have to create a photo-taking app, you can just access the default app on the device for doing this through an Activity call. This is why Android apps don’t have a main() function, they have multiple entry points (Activities).
Component activation is done through an Intent Object. An Intent can access any Activity, Service, or Broadcast receiver on the device (that is accessible). These can take several forms, but are all done through common APIs. These can be one-way (launch something) or two-way (launch/query something, return a result), depending on the action taken and the calls used.
As you delve into Android development, you’ll learn what these common APIs are and how to use them properly. They give the developer a lot of power when building apps.