Overview of Android Application Development

Android Operating System Architecture ©SoftMoore Consulting

Android Applications Are written in the Java programming language. Each application must have a unique package name. Some core libraries are different. Are bundled into an archive file with the “.apk” suffix. vehicle for distributing applications and installing on mobile devices Run on the Dalvik Virtual Machine, a Java VM designed for systems that are processor/memory constrained. Google is working on a replacement for Dalvik called ART. See https://source.android.com/devices/tech/dalvik/art.html ©SoftMoore Consulting

Android Application Security By default, application code runs in isolation of other applications Every application runs in its own Linux process. Each process has its own virtual machine (VM). By default, each application is assigned a unique Linux user ID. Permissions are set so that the application’s files are visible only to that application. ©SoftMoore Consulting

Signing an Application The Android system requires that all installed applications be digitally signed with a certificate (a.k.a., key) whose private key is held by the application’s developer. The certificate does not need to be signed by a certificate authority – most Android applications use self-signed certificates. Android devices test a signer certificate’s expiration date only at install time. If the certificate expires after the application is installed, the application will continue to function normally. ©SoftMoore Consulting

The SDK Debug Key During installation, the Android SDK tools create a debug keystore and key in <ANDROID_SDK_HOME>\.android with predetermined names/passwords: Keystore name: “debug.keystore” Keystore password: “android” Key alias: “androiddebugkey” Key password: “android” At each compilation, SDK tools use this debug key to sign the .apk file. Caution: Applications signed with the debug certificate cannot be released to the public. ©SoftMoore Consulting

Application Components Every application is made up of one or more of the following four components: Activity – represents a single screen with a user interface. An application usually consists of one or more activities. most common component implemented as a subclass of class Activity Service – runs in the background and does not provide a user interface. example: music player implemented as a subclass of class Service ©SoftMoore Consulting

Application Components (continued) Broadcast Receiver – responds to system-wide broadcast announcements. Broadcast receivers do not display a user interface, but they may create a status bar notification or they may start an activity in response to the information they receive implemented as a subclass of class BroadcastReceiver Content Provider – manages a shared set of application data and makes it available to other applications; e.g., from a file or an SQLite database. example: contact information implemented as a subclass of class ContentProvider ©SoftMoore Consulting

Android Manifest Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest file presents essential information about the app to the Android system Among other things, the manifest does the following: names the Java package for the application. The package name serves as a unique identifier for the application. describes the components (activities, services, broadcast receivers, and content providers) that make up the application declares permissions the application must have in order to access protected parts of the API declares the minimum Android API level required by the application ©SoftMoore Consulting

Intents With the exception of content providers, each component is activated by an asynchronous message called an intent, an object of class Intent. An intent object holds the content of the message. For activities and services, it names the action being requested and specifies the URI of the data to act on, among other things. Intents provide a facility for performing late runtime binding between the code in different applications. Their most significant use is in the launching of activities. ©SoftMoore Consulting

Explicit Intents versus Implicit Intents There are two types of intents: Explicit intents request the launch of a specific activity by referencing the activity by class name. Explicit intents are typically used within a single application. Implicit intents declare a general action to be performed or provide data of a specific type on which the action is to be performed. For implicit intents, the Android runtime selects the activity to launch that most closely matches the criteria. When you create an explicit intent to start an activity or service, the system immediately starts the application component specified in the Intent object. When you create an implicit intent, the Android system finds the appropriate component to start. ©SoftMoore Consulting

The Android System Handles Implicit Intents ©SoftMoore Consulting

Information Contained in an Intent Component name: name of the component to start optional, but including it makes an intent explicit Action: string that specifies the generic action to perform e.g., ACTION_MAIN or ACTION_EDIT Data: URI of data to be acted on and/or the data MIME type different actions are paired with different kinds of data type of data supplied is generally dictated by the intent's action Category: string containing additional information about the kind of component that should handle the intent any number of category descriptions can be placed in an intent most intents do not require a category Extras: key-value pairs that carry additional information required to accomplish the requested action ©SoftMoore Consulting

Using Intents Three fundamental use cases for intents To start an activity To start a service To deliver a broadcast ©SoftMoore Consulting

Activities and Views One of the activities of an application is typically marked as the first one that should be presented to the user when the application is launched; i.e., the main activity. Each activity is given a default window to draw in. An activity can also make use of additional windows such as a pop-up dialog. The visual content of the window is provided by a hierarchy of views. Each view controls a particular rectangular space within the window. A view is an object of a subclass of class View. ©SoftMoore Consulting

Activities and Views (continued) Parent views contain and organize the layout of their children. Examples include WebView, LinearLayout, and TableLayout. Leaf views draw in the rectangles they control and respond to user actions directed at that space. Most leaf views are graphical widgets such as buttons, text fields, check boxes, etc. Android has a number of ready-made views that you can use – see packages android.view and android.widget. ©SoftMoore Consulting

States in the Lifetime of an Activity An activity has essentially three main states: Active (running): It is in the foreground of the screen (at the top of the activity stack for the current task). Paused: It has lost focus but is still visible to the user. That is, another activity lies on top of it and that activity either is transparent or doesn't cover the full screen, so some of the paused activity can show through. Stopped: It is completely obscured by another activity. It still retains all state information. However, it is no longer visible to the user, so its window is hidden and it will often be killed by the system when memory is needed elsewhere. ©SoftMoore Consulting

Activity Lifecycle and Lifecycle Methods (http://developer. android ©SoftMoore Consulting

Understanding the Activity Lifecycle The activity lifecycle is designed to protect battery life and manage system memory. Activities live on a stack; i.e., the Android framework manages a stack of activities. If an activity is paused or stopped and available memory is low, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state. Android makes it easy to develop applications that are killed at any moment without losing state. ©SoftMoore Consulting

Developing in Android Studio ©SoftMoore Consulting

Android Virtual Device (emulator) ©SoftMoore Consulting

Relevant Links Android Application Fundamentals http://developer.android.com/guide/components/fundamentals.html Android Developer Videos – Androidology Part 1 of 3: Architecture Overview https://www.youtube.com/watch?v=QBGfUs9mQYY Part 2 of 3: Application Lifecycle https://www.youtube.com/watch?v=fL6gSd4ugSI Part 3 of 3: APIs https://www.youtube.com/watch?v=MPukbH6D-lY YouTube Android Developers Channel https://www.youtube.com/user/androiddevelopers Intents and Intent Filters http://developer.android.com/guide/components/intents-filters.html ©SoftMoore Consulting