Fundamentals of Android Development

There are a ton of Android App tutorial videos and blogs but almost all of them are concentrated towards the practical applications of this platform and almost no one talks about the actual theory and working of the Android Platform.

Fundamentals

First, let’s talk about the fundamentals of the Android platform, Android is an operating system built on top of a multi-user Linux kernel and the system treats each app as a separate user seperate user and assigns a unique user id to each app, this id is only used by the linux system and is not visible to the app.

Once the id is assigned, the system sets the access permission to all the files in an app data so that only that particular app can use and manipulate those files.

Each app in the Android platform runs as an independent Linux process, the Android system starts the process when any of the app’s component needs to be executed and shuts down the process when it’s no longer needed or the system needs to recover memory for other processes. Each process runs has its own virtual machine, so an app’s code runs isolation from other apps running at the same time in the system.

The Android system implements the principal of least privilege, that is, each app, by default, has access only to the components that it requires to do its work and does not allow any more than that. This creates a secure environment in which an app cannot access parts of the system for which the app does not have the permission of.

However, there are ways for an app to share data with other apps and access system services. There is a way to arrange for two apps to share the same Linux user id, in which case those apps can share the data files with each other. To conserve the system’s resources, the apps with same user id can arrange to run in the same Linux process and share the same virtual machine. To make the system secure, these apps must be signed with the same digital signature.

A digital signature is a mathematical scheme for verifying the authenticity of digital messages or documents. A valid digital signature gives a recipient reason to believe that the message was created by a known sender (authentication), that the sender cannot deny having sent the message (non-repudiation), and that the message was not altered in transit (integrity)

Wikipedia

An app can request permission to access device data such as user’s contact list, SMS data, Bluetooth, etc. But the user has to grant explicit permission to the app access these services.

Android App Life Cycle

Every component in an Android app goes through a series of states while the execution of an app. A typical life cycle of an app includes these states:

• OnCreate
• OnStart
• OnResume
• OnPause
• OnStop
• OnDestroy

OnCreate

OnCreate is called when an app component is first brought into life, Android SDK provides a method which you must override to tell the app what to do as soon as that app component is created.

@Override
public void onCreate(Bundle savedInstanceState) {
    // call the super class onCreate to complete the creation of activity like
    // the view hierarchy
    super.onCreate(savedInstanceState);
 
    // set the user interface layout for this activity
    // the layout file is defined in the project res/layout/main_activity.xml file
    setContentView(R.layout.main_activity);
}

OnStart

When the activity enters the Started state, the system invokes this callback. The onStart() call makes the activity visible to the user, as the app prepares for the activity to enter the foreground and become interactive. For example, this method is where the app initializes the code that maintains the UI.

OnResume

When the activity enters the Resumed state, it comes to the foreground, and then the system invokes the onResume() callback. This is the state in which the app interacts with the user. The app stays in this state until something happens to take focus away from the app. Such an event might be, for instance, receiving a phone call, the user’s navigating to another activity, or the device screen’s turning off.

OnPause

The system calls this method as the first indication that the user is leaving your activity (though it does not always mean the activity is being destroyed); it indicates that the activity is no longer in the foreground (though it may still be visible if the user is in multi-window mode). Use the onPause() method to pause or adjust operations that should not continue (or should continue in moderation) while the Activity is in the Paused state, and that you expect to resume shortly.

OnStop

When your activity is no longer visible to the user, it has entered the Stopped state, and the system invokes the onStop() callback. This may occur, for example, when a newly launched activity covers the entire screen. The system may also call onStop() when the activity has finished running and is about to be terminated.

OnDestroy

onDestroy() is called before the activity is destroyed. When the activity moves to the destroyed state, any life-cycle-aware component tied to the activity’s life-cycle will receive the ON_DESTROY event. This is where the life-cycle components can clean up anything it needs to before the Activity is destroyed.

App Components

App Components are the building blocks of an Android app. Each component is an entry point through which a user or a system can enter your app. Some component depend on other. There are four different types of components in Android Platform:

• Activities
• Services
• Broadcast Receivers
• Content Providers

Activities

An activity is the entry point for interacting with the user. It represents a single screen with a user interface. For example, an email app might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails. Although the activities work together to form a cohesive user experience in the email app, each one is independent of the others. As such, a different app can start any one of these activities if the email app allows it. For example, a camera app can start the activity in the email app that composes new mail to allow the user to share a picture. An activity facilitates the following key interactions between system and app:

• Keeping track of what the user currently cares about (what is on screen) to ensure that the system keeps running the process that is hosting the activity.
• Knowing that previously used processes contain things the user may return to (stopped activities), and thus more highly prioritize keeping those processes around.
• Helping the app handle having its process killed so the user can return to activities with their previous state restored.
• Providing a way for apps to implement user flows between each other, and for the system to coordinate these flows. (The most classic example here being share.)

Services

A service is a general-purpose entry point for keeping an app running in the background for all kinds of reasons. It is a component that runs in the background to perform long-running operations or to perform work for remote processes. A service does not provide a user interface. For example, a service might play music in the background while the user is in a different app, or it might fetch data over the network without blocking user interaction with an activity. Another component, such as an activity, can start the service and let it run or bind to it in order to interact with it. There are actually two very distinct semantics services tell the system about how to manage an app: Started services tell the system to keep them running until their work is completed. This could be to sync some data in the background or play music even after the user leaves the app. Syncing data in the background or playing music also represent two different types of started services that modify how the system handles them:

• Music playback is something the user is directly aware of, so the app tells the system this by saying it wants to be foreground with a notification to tell the user about it; in this case the system knows that it should try really hard to keep that service’s process running, because the user will be unhappy if it goes away.
• A regular background service is not something the user is directly aware as running, so the system has more freedom in managing its process. It may allow it to be killed (and then restarting the service sometime later) if it needs RAM for things that are of more immediate concern to the user.

Bound services run because some other app (or the system) has said that it wants to make use of the service. This is basically the service providing an API to another process. The system thus knows there is a dependency between these processes, so if process A is bound to a service in process B, it knows that it needs to keep process B (and its service) running for A. Further, if process A is something the user cares about, then it also knows to treat process B as something the user also cares about. Because of their flexibility (for better or worse), services have turned out to be a really useful building block for all kinds of higher-level system concepts. Live wallpapers, notification listeners, screen savers, input methods, accessibility services, and many other core system features are all built as services that applications implement and the system binds to when they should be running.

Broadcast Receivers

A broadcast receiver is a component that enables the system to deliver events to the app outside of a regular user flow, allowing the app to respond to system-wide broadcast announcements. Because broadcast receivers are another well-defined entry into the app, the system can deliver broadcasts even to apps that aren’t currently running. So, for example, an app can schedule an alarm to post a notification to tell the user about an upcoming event… and by delivering that alarm to a BroadcastReceiver of the app, there is no need for the app to remain running until the alarm goes off.

Content Providers

A content provider manages a shared set of app data that you can store in the file system, in a SQLite database, on the web, or on any other persistent storage location that your app can access. Through the content provider, other apps can query or modify the data if the content provider allows it. For example, the Android system provides a content provider that manages the user’s contact information.

Intents

Three of the four component types—activities, services, and broadcast receivers—are activated by an asynchronous message called an intent. Intents bind individual components to each other at runtime. You can think of them as the messengers that request an action from other components, whether the component belongs to your app or another.

An intent is created with an Intent object, which defines a message to activate either a specific component (explicit intent) or a specific type of component (implicit intent).

For activities and services, an intent defines the action to perform (for example, to view or send something) and may specify the URI of the data to act on, among other things that the component being started might need to know. For example, an intent might convey a request for an activity to show an image or to open a web page. In some cases, you can start an activity to receive a result, in which case the activity also returns the result in an Intent. For example, you can issue an intent to let the user pick a personal contact and have it returned to you. The return intent includes a URI pointing to the chosen contact.

For broadcast receivers, the intent simply defines the announcement being broadcast. For example, a broadcast to indicate the device battery is low includes only a known action string that indicates battery is low.

The Manifest File

Before the Android system can start an app component, the system must know that the component exists by reading the app’s manifest file, AndroidManifest.xml. Your app must declare all its components in this file, which must be at the root of the app project directory.

The Manifest file does a number of things:

• Identifies any user permissions the app requires, such as Internet access or read-access to the user’s contacts.
• Declares the minimum API Level required by the app, based on which APIs the app uses.
• Declares hardware and software features used or required by the app, such as a camera, bluetooth services, or a multitouch screen.
• Declares API libraries the app needs to be linked against (other than the Android framework APIs), such as the Google Maps library.

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:icon="@drawable/app_icon.png" ... >
        <activity android:name="com.example.project.ExampleActivity"
                  android:label="@string/example_label" ... >
        </activity>
        ...
    </application>
</manifest>

App Resources

An Android app is composed of more than just code—it requires resources that are separate from the source code, such as images, audio files, and anything relating to the visual presentation of the app. For example, you can define animations, menus, styles, colors, and the layout of activity user interfaces with XML files. Using app resources makes it easy to update various characteristics of your app without modifying code. Providing sets of alternative resources enables you to optimize your app for a variety of device configurations, such as different languages and screen sizes.

For every resource that you include in your Android project, the SDK build tools define a unique integer ID, which you can use to reference the resource from your app code or from other resources defined in XML. For example, if your app contains an image file named logo.png (saved in the res/drawable/ directory), the SDK tools generate a resource ID named R.drawable.logo. This ID maps to an app-specific integer, which you can use to reference the image and insert it in your user interface.

One of the most important aspects of providing resources separate from your source code is the ability to provide alternative resources for different device configurations. For example, by defining UI strings in XML, you can translate the strings into other languages and save those strings in separate files. Then Android applies the appropriate language strings to your UI based on a language qualifier that you append to the resource directory’s name (such as res/values-fr/ for French string values) and the user’s language setting.

Android supports many different qualifiers for your alternative resources. The qualifier is a short string that you include in the name of your resource directories in order to define the device configuration for which those resources should be used. For example, you should create different layouts for your activities, depending on the device’s screen orientation and size. When the device screen is in portrait orientation (tall), you might want a layout with buttons to be vertical, but when the screen is in landscape orientation (wide), the buttons could be aligned horizontally. To change the layout depending on the orientation, you can define two different layouts and apply the appropriate qualifier to each layout’s directory name. Then, the system automatically applies the appropriate layout depending on the current device orientation.

You should always externalize app resources such as images and strings from your code, so that you can maintain them independently. You should also provide alternative resources for specific device configurations, by grouping them in specially-named resource directories. At runtime, Android uses the appropriate resource based on the current configuration. For example, you might want to provide a different UI layout depending on the screen size or different strings depending on the language setting.

Once you externalize your app resources, you can access them using resource IDs that are generated in your project’s R class. This document shows you how to group your resources in your Android project and provide alternative resources for specific device configurations, and then access them from your app code or other XML files.

App Permissions

The purpose of a permission is to protect the privacy of an Android user. Android apps must request permission to access sensitive user data (such as contacts and SMS), as well as certain system features (such as camera and internet). Depending on the feature, the system might grant the permission automatically or might prompt the user to approve the request.

A central design point of the Android security architecture is that no app, by default, has permission to perform any operations that would adversely impact other apps, the operating system, or the user. This includes reading or writing the user’s private data (such as contacts or emails), reading or writing another app’s files, performing network access, keeping the device awake, and so on.

This page provides an overview to how Android permissions work, including: how permissions are presented to the user, the difference between install-time and runtime permission requests, how permissions are enforced, and the types of permissions and their groups.

An app must publicize the permissions it requires by including <uses-permission> tags in the app manifest. For example, an app that needs to send SMS messages would have this line in the manifest:

<uses-permission android:name="android.permission.SEND_SMS"/>

In android API version 23 and later, you have to explicitly ask for the permission in addition to adding the tag in the manifest file:

// Here, thisActivity is the current activity
if (ContextCompat.checkSelfPermission(thisActivity,
        Manifest.permission.READ_CONTACTS)
        != PackageManager.PERMISSION_GRANTED) {
 
    // Permission is not granted
    // Should we show an explanation?
    if (ActivityCompat.shouldShowRequestPermissionRationale(thisActivity,
            Manifest.permission.READ_CONTACTS)) {
        // Show an explanation to the user *asynchronously* -- don't block
        // this thread waiting for the user's response! After the user
        // sees the explanation, try again to request the permission.
    } else {
        // No explanation needed; request the permission
        ActivityCompat.requestPermissions(thisActivity,
                new String[]{Manifest.permission.READ_CONTACTS},
                MY_PERMISSIONS_REQUEST_READ_CONTACTS);
 
        // MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
        // app-defined int constant. The callback method gets the
        // result of the request.
    }
} else {
    // Permission has already been granted
}

According to official Android Developer Docs, there are few points you must take care of while handling permission in android app:

• Only use the permissions necessary for your app to work. Depending on how you are using the permissions, there may be another way to do what you need (system intents, identifiers, backgrounding for phone calls) without relying on access to sensitive information.
• Pay attention to permissions required by libraries. When you include a library, you also inherit its permission requirements. You should be aware of what you’re including, the permissions they require, and what those permissions are used for.
• Be transparent. When you make a permissions request, be clear about what you’re accessing, and why, so users can make informed decisions. Make this information available alongside the permission request including install, runtime, or update permission dialogues.
• Make system accesses explicit. Providing continuous indications when you access sensitive capabilities (for example, the camera or microphone) makes it clear to users when you’re collecting data and avoids the perception that you’re collecting data surreptitiously.

Every thing said in this post is taken from the official android developer documentation. I highly recommend you to read that.