Android Fundamentals - Part 1
Alexander Nelson
September 9, 2019
University of Arkansas - Department of Computer Science and Computer Engineering
Reminders
Projects
Project 1 due Friday, September 20thLink
Choose a project idea and team for the final project ASAP
First project report is due September 13th
Android OS Platform Architecture
Android Stack
https://developer.android.com/guide/platform
Used by Fair Use under Creative Commons Attribution 2.5
Linux Kernel
Android is based on the Linux kernel
• All lower-level functionality is handled by Kernel
• Provides consistent functionality across devices
• Maintains standard security practices
• No need to reinvent the wheel
Hardware Abstraction Layer (HAL)
Standard set of interfaces from device hardware to
Java/Kotlin APIs
• Consists of library modules
• Modules are loaded when API makes call to access hardware
Android Runtime (ART)
Managed runtime environment of an application
• Beginning with Android 5.0, each app runs in its own process
and its own instance of ART
• Each process runs in its own VM, and is thus isolated from
other applications
• Includes core Java libraries for most of the Java functionality
• Android 9 and above convert executables to more compact
machine code
Native C/C++ Libraries
Android system components are built from native code and
require support libraries
• Android provides Java framework APIs to expose some
funcitonality to these libraries
• e.g. OpenGL ES can be accessed through Java OpenGL API
for graphics
Java API Framework
Entire Android OS feature-set available through Java APIs
including:
• View System to build UI (XML defined)
• Resource manager - Access to non-code resources
• Notification manager - All apps can display alerts
• Activity manager - Manage lifecycle of apps
• Content Providers - Enable cross application sharing
System Applications
Core set of applications provided by OS
• e.g. Camera, SMS, Email, Calendar, Calls, etc...
• No special status among apps
• Provide capabilities developers can access from their own app
Application Fundamentals
Application & OS
OS Security Features:
• Multi-user Linux system – each app is a different user
• System assigns each app a unique user ID
• Permissions are set for files such that only the assigned app
can access them
• Each process has own VM – App code run in isolation
https://developer.android.com/guide/components/fundamentals.html
Application & OS
Process Cycle:
• Each app runs in its own Linux process
• Android starts the process when any app component is needed
• Shuts down process when finished, or memory is needed
elsewhere
Principle of Least Privilege
Each app, by default, has acess only to the components that
it requires, and nothing more!
Exceptions:
• Two apps can share the same Linux user ID
• Can access each other’s files
• Can run in the same process and same VM
• Must be signed with the same certificate
• e.g. Facebook & Messenger
• App can request permission to access device data
• User must grant these permissions explicitly
Application Components
Four different types of Application components:
• Activities
• Services
• Broadcast Receivers
• Content Providers
Activities
Activity
Entry point for interacting with the user
Typically represents a single screen with a UI
Mutliple activities can come together to create a single application
Example: e-Mail application
• Inbox Screen
• Compose e-Mail
• Settings
Activies (continued)
An activity facilitates key interactions between the system
and the application, including:
• Keeping track of what the user is currently focused on
• Helping the app handle having its process killed
• Providing a way for apps to implement user flowss between
each other
Activities (continued)
To be used, an activity must be declared in the application manifest
Example:
<m a n i f e s t . . . >
<a p p l i c a t i o n . . . >
<a c t i v i t y a n d r o i d : n a m e=” . E x a m p l e A c t i v i t y ” />
. . .
</ a p p l i c a t i o n . . . >
. . .
</ m a n i f e s t >
Activitiy Attributes
Attributes can define certain interactions about the activity
Contained inside the activity tag
The only required attribute for an activity is ”android:name”
This specifies the class name of the activity
Think these names through! They should not change after
publishing your applications!
Activitiy Attributes (continued)
Other attributes you may want to include in the manifest:
• Intent filters (Will discuss later)
• Permissions
• Screen Orientation
• Icon
Activity Lifecycle
https://developer.android.
com/guide/components/
activities/
activity-lifecycle.html
Activity Lifecycle
An activity will transition through a number of states during
its lifetime
A series of callbacks are used to handle transitions
• onCreate()
• onStart()
• onResume()
• onRestart()
• onPause()
• onStop()
• onDestroy()
onCreate()
Callback which fires when the system creates the activity
You must implement this callback!
This callback should initialize the essential components:
• Create views
• Bind data
• Calls setContentView() which defines the layout for the UI
After returining, the next callback is always onStart()
onStart()
Activity becomes visible to the user
Final preparations before coming to the foreground and becoming
interactive
Followed by onResume()
onResume()
Invoked when the activity starts interacting with the user
Most of the App’s core functionality implemented here
At this point the activity is on the top of the activity stack and
captures all user input
onPause()
Called when activity loses focus and enters Paused state
e.g. When the user hits the back button
The activity is still partially visible and can (should?) continue to
update
If the user returns to the activity, onResume() will be called
onStop() is called if the activity beomes no longer visible
onStop()
Called when activity becomes no longer visible to user
e.g. When activity being destroyed, new activity starting, existing
activity being resumed
If the activity comes back to the foreground, onRestart() is called
onDestroy() is called if the activity is completely termininating.
onRestart()
Called when a stopped actibity is about to restart
e.g. When activity is brought back to the foreground
Restores the state of the activity from when it was stopped
Always followed by onStart()
onDestroy()
onDestroy() is invoked before the activity is destroyed
Implemented to ensure that all the activities resources are released
This is the final state in the activity lifecycle
Must be recreated to start again
Services
Service
Application component that can perform long-running operations
in the background
Does not provide a user interface!
Another app component can start a service
The service continues to run in the background even after activity
change
Components can bind to a service to interact & perform
interprocess communication
Services
There are three different types of services:
• Foreground
• Background
• Bound
Foreground Service
Performs some operation that is noticable to the user
e.g. Audio app uses foreground service to play music
Must display a status bar icon
Continue running even when user isn’t interacting with the app
Background Service
Performs operations not directly noticed by user
e.g. Compress file storage for application
Caveat:
Starting with API 26, background services have restrictions when
the app is not in the foreground
Often better to use a scheduled job instead
Bound Service
A service becomes bound when app component uses bindService()
Offers a client-server interface for interacting with the service
Only runs when another application is bound to it!
Declaring Services
To be used, an service must be declared in the application manifest
Example:
<m a n i f e s t . . . >
<a p p l i c a t i o n . . . >
< s e r v i c e a n d r o i d : n a m e=” . E x a m p l e S e r v i c e ” />
. . .
</ a p p l i c a t i o n . . . >
</ m a n i f e s t >
Service Lifecycle
onStartCommand()
One way to start an Android service
System invokes this by calling startService() from another
component
• startService() takes Intent as argument
• onStartCommand() takes Intent, flags, and startId
If this is implemented, you must stop the service when work
is complete by calling stopSelf() or stopService()
Started Services
A started service is one that is created when a component calls
startService()
Lifecycle of the service is independent of the component
which creates it!
App components create services by calling startService() and
passing an Intent object specifying the targeted Service
Started Services (continued)
By default started services run in the same process in the main
thread of the application in which it is declared
If the service is blocking while the user is to be interacting with the
app, start a new thread within the service
Started Services (continued)
It is best to start a service by extending the IntentService class
The IntentService class does the following:
• Creates default worker thread that executes all intents
delivered to the onStartCommand()
• Creates a work queue that passes one intent at a time to your
onHandleIntent() implementation, so you never have to worry
about multi-threading
• Stops the service after all of the start requests are handled, so
you never have to call stopSelf()
• Provides a default implementation of onBind() that returns
null
• Provides a default implementation of onStartCommand() that
sends the intent to the work queue and then to your
onHandleIntent() implementation
Example IntentService
Extending Intent Service
All you need (as shown by previous example):
• Constructor
• Implementation of onHandleIntent()
You may also override callbacks, but you must call the super
implementation
Starting a Service
You create a Started Service by calling startService() and passing
an intent object
Stopping a Service
Started services must manage their own lifecycle
The system will not stop or destory a service unless it must
recover memory
Services must stop itself by calling stopSelf() or another
component may stop it by calling stopService()
If your service is potentially used by multiple components
concurrently:
Use stopSelf(int) where the passed integer is the ID of the start
request
onBind()
Other way to start an Android Service
Calledc when another component calls bindService()
• You must provide an interface to communicate between client
and service
• IBinder object provides this, by extending the Binder class
Bound Services
Bound services are to be used when you want your service to
interact with other components through Interprocess
Communication (IPC)
Use onBind() callback to create a bound service
onBind() returns an IBinder object defining the interface for
communication
Bound Services
Multiple components may bind with a service, and have a reference
to the same IBinder object
When a client is finished with the service, it calls unbindService()
to unbind
You do not need to stop a bound service!
Bound services terminate when no clients are connected
onCreate()
Invoked by the system before onStartCommand() or onBind()
Perform one-time setup procedures
Not called if service is already running!
onDestroy()
Invoked by the system before when Service is no longer needed
Should be implemented to clean up any resources (threads,
registered listeners, receivers)
Last call that the service will receive
Service Stop Conditions
Service started by calling startService() will run until stopped by
stopSelf() or another component calls stopService()
Service started by bindService() will run as long as the component
is bound to it
Force-stop conditions
• If memory is low and system resources must be recovered
• Bound services to app in focus less likely to be killed
• Foreground services are rarely killed
• Long-running started services are highly susceptible to being
killed
Notifications
Services may communicate to the
user with:
• Toast Notifications
• Status Bar Notifications
Foreground Services
Foreground services are services the user is actively aware of
Must provide a notification for the status bar under the
Ongoing heading!
Notification cannot be dismissed unless service is stopped or
removed from foreground
ex. Music player should be foreground
Notification shows current song
Can interact to launch the music player
Starting a foreground service
Request to run service in foreground with startForeground()
Takes two parameters:
• Integer to uniquely identify the notification
• A Notification object for the status bar
Notification object must have priority of PRIORITY LOW or higher
Foreground Service Example
Removing Service from Foreground
To remove service from foreground:
• Call stopForeground()
stopForeground() takes a boolean argument which indicates
whether to remove the status bar notification
Removing service from foreground does not stop the service!