Overview of AndroidApplication Development

©SoftMoore Consulting

Android Operating System Architecture

Slide 2

©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.

Slide 3

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.

Slide 4

©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 useself-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.

Slide 5

©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.

Slide 6

Caution: Applications signed with the debugcertificate 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

Slide 7

©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

Slide 8

©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

Slide 9

©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.

Slide 10

©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.

Slide 11

©SoftMoore Consulting

The Android System Handles Implicit Intents

Slide 12

©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

Slide 13

©SoftMoore Consulting

Using Intents

Three fundamental use cases for intents

• To start an activity

• To start a service

• To deliver a broadcast

Slide 14

©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.

Slide 15

©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.

Slide 16

©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.

Slide 17

©SoftMoore Consulting

Activity Lifecycle and Lifecycle Methods(http://developer.android.com/reference/android/app/Activity.html)

Slide 18

©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.

Slide 19

©SoftMoore Consulting

Developing in Android Studio

Slide 20

©SoftMoore Consulting

Android Virtual Device(emulator)

Slide 21

©SoftMoore Consulting

Relevant Links

• Android Application Fundamentalshttp://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 Channelhttps://www.youtube.com/user/androiddevelopers

• Intents and Intent Filtershttp://developer.android.com/guide/components/intents-filters.html

Slide 22