1. Overview of Android Application Development

2. Android Operating System Architecture
©SoftMoore Consulting

3. 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
©SoftMoore Consulting

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

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

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

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

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

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

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

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

12. The Android System Handles Implicit Intents
©SoftMoore Consulting

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

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

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

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

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

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

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

20. Developing in Android Studio
©SoftMoore Consulting

21. Android Virtual Device (emulator)
©SoftMoore Consulting

22. Relevant Links Android Application Fundamentals
Android Developer Videos – Androidology
Part 1 of 3: Architecture Overview
Part 2 of 3: Application Lifecycle
Part 3 of 3: APIs
YouTube Android Developers Channel
Intents and Intent Filters
©SoftMoore Consulting