Understanding Operating Systems
Seventh Edition
Chapter 16
Android Operating Systems
Learning Objectives
After completing this chapter, you should be able to
describe:
• The design goals for the Android™ operating
system
• The role of the Memory Manager and Virtual
Memory Manager
• The cooperation of the Android operating system
with Linux for memory, device, processor, and
network management
Understanding Operating Systems, 7e
2
Learning Objectives (cont’d.)
• System security challenges
• The critical role of Android applications
Understanding Operating Systems, 7e
3
Introduction
• Android
– Designed to run mobile devices: specifically
smartphones and tablets
– Built on a Linux foundation
– Customizable user interface
• Allows user to customize app configurations
– Open source operating system
• Key elements, but not all, of the source code are
published
Understanding Operating Systems, 7e
4
Brief History
• Android operating system
– Developed by Any Rubin and associates
– Designed to power the Sidekick cell phone
• Initial challenges
– Phone battery power limitations
– Small CPU
– Limited memory space
• Design team solution
– Multilevel system integrating Linux: user actions
performed via unique apps from the phone’s screen
Understanding Operating Systems, 7e
5
Brief History (cont’d.)
• Google purchased Android (2005)
• Rubin joined Google
• Android extended to reach entire mobile
smartphones and tablets generations
– “More than 750 million devices have been activated
globally; and 25 billion apps have now been
downloaded from Google Play”
Larry Page, Google CEO (2013)
Understanding Operating Systems, 7e
6
(figure 16.1)
The Android robot logo can be
used only according to terms
described in the Creative
Commons 3.0 Attribution
License..
© Cengage Learning 2014
Understanding Operating Systems, 7e
7
(table 16.1)
Selected releases of Android, listing the Linux kernel on which each is built.
Notice that the code names (all sweet treats) are assigned in alphabetical
order.
© Cengage Learning 2014
Understanding Operating Systems, 7e
8
Brief History (cont’d.)
• Android’s source code: available with each new
release
– Manufacturers and enthusiasts can prepare their
installation and customized software
– Instructions at http://source.android.com
• Device’s Android version number and Linux kernel
version number
– Available under Systems menu
Understanding Operating Systems, 7e
9
Design Goals*
• Enchant me
– Sleek and aesthetically pleasing design
• Simplify my life
– Make life easier
• Make me amazing
– Empower people to try new things and to use apps in
inventive new ways
* Taken from Android Web site for developers at
http://developer.android.com/design/get-started/creativevision.html
Understanding Operating Systems, 7e
10
Memory Management
• Handled by the Linux kernel: supported by several
software modifications
– Works successfully on limited main memory and
slower CPU devices
• Resources utilized only as needed
• Sleep-like state when dormant
• Open app remains resident in main memory
– Least recently used (LRU) algorithm for tracking
– Low memory killer (LMK) frees memory when
memory becomes scarce
Understanding Operating Systems, 7e
11
(figure 16.3)
This simplified illustration shows that the Android software stack is built on a
Linux kernel, which manages all device drivers (only a few are shown here).
(Illustration is adapted from http://source.android.com/tech/security.)
© Cengage Learning 2014
Understanding Operating Systems, 7e
12
Processor Management
• Requires four key objects: manifest, activities, tasks,
and intents
• Manifest: file that holds essential information that
the system must have before it can run an
application
– AndroidManifest.xml
• Activity: application component that defines the user
interface screen that the individual uses to interact
with the application
– Including all the actions that can be performed
Understanding Operating Systems, 7e
13
Processor Management (cont’d.)
• Task: “sequence of activities a user follows to
accomplish a goal”
– Can involve one or many apps
– Service: task that runs in the background
• Intent: mechanism that one app uses to signal to
another app that its cooperation is requested to
accomplish something
– Allows apps to call on one another as needed to
meet a user’s request
Understanding Operating Systems, 7e
14
Activity States
• Created state: transient state when the activity has
just begun
• Started state: software initialization begins and the
first screen can be drawn
– Generally considered the main screen
• Resumed state (running state): activities execute
until they are interrupted by another activity or a
user command
Understanding Operating Systems, 7e
15
Activity States (cont’d.)
• Paused state: a stop for an activity that is
interrupted and ready to go into a “background”
mode
• Stopped state: activities disappear from the user’s
view
– Subsequently, activity may be terminated or it may be
recalled
Understanding Operating Systems, 7e
16
Activity States (cont’d.)
• Destroyed state: formal indication that the activity is
terminated
– Will be removed completely from system memory
– Background activities closed properly to prevent
memory leaks
Understanding Operating Systems, 7e
17
(figure 16.4)
The changing states of a typical activity from Created on the left to Destroyed
on the right. Typically, activities can be removed from memory when they are
in the Paused, Stopped, or Destroyed states.
© Cengage Learning 2014
Understanding Operating Systems, 7e
18
Activity States (cont’d.)
• Back stack: data structure
– When new app is loaded, replaced app is moved onto
the stack
– Loading and unloading uses last-in, first-out (LIFO)
scheme
– User navigates previously viewed apps using the
screen’s “back” button
Understanding Operating Systems, 7e
19
(figure 16.5)
The last-in, first-out (LIFO) scheme moves the activity status of the current
app into the back stack when that app is replaced by another one. Later, it
restores each app in reverse order each time the user presses the back
button.
© Cengage Learning 2014
Understanding Operating Systems, 7e
20
(figure 16.6)
Detailed view of the Activity Lifecycle and the system callbacks that move an
activity from one state to another.
(Illustration source: http://developer.android.com/training/basics/activitylifecycle/starting.html, 2012)
© Cengage Learning 2014
Understanding Operating Systems, 7e
21
Activity States (cont’d.)
• Smoothly running Android system
– App developers
• Must remain aware of the many ways in which an app
can be terminated and impact on resource allocation
• Ensure each app ends gracefully when terminated by
user regardless of app’s state at the time
Understanding Operating Systems, 7e
22
Device Management
• Apps are designed to accommodate numerous
devices, often without user help
• Screen requirements
– Design considerations: screen size, screen density,
orientation, and resolution
– Density-independent pixel (dp): equivalent to one
physical pixel on a 160 dpi screen
– Interface design using dp unit: system can perform
the necessary scaling for each screen based on its
size, resolution, orientation, and density
Understanding Operating Systems, 7e
23
(figure 16.2)
Four device display variables that directly impact the design of user interface
screens.
© Cengage Learning 2014
Understanding Operating Systems, 7e
24
Device Management (cont’d.)
• Android’s four screen sizes categories
–
–
–
–
Extra-large screens: at least 960dp x 720dp
Large screens: at least 640dp x 480dp
Normal screens: at least 470dp x 320dp
Small screens: at least 426dp x 320dp
• Ultimate app designer’s goal
– Give every user the impression that the app was
designed specifically for the user’s device
Understanding Operating Systems, 7e
25
(figure 16.7)
Comparison of the four screen sizes supported by Android and the different
densities for each size: low dpi (ldpi), medium dpi (mdpi), high dpi (hdpi), and
extra high dpi (xhdpi). (Illustration source: http://developer.android.com)
© Cengage Learning 2014
Understanding Operating Systems, 7e
26
Device Management (cont’d.)
• Battery management
– Android device’s battery usage information: Settings
tab
– Ways to improver battery availability
• Users choose to leave certain functions turned off until
they are actually needed, e.g., GPS, Bluetooth
communications, background file syncing, etc.
• Wi-Fi instead of telephony: saves power
Understanding Operating Systems, 7e
27
(figure 16.8)
This device has 1 hour, 32 minutes of battery time remaining. This display
also indicates that the screen is consuming 73 percent of the device’s battery
resources at a very bright setting and that the Android operating system is
using 5 percent.
© Cengage Learning 2014
Understanding Operating Systems, 7e
28
File Management
• Linux-managed at the kernel level
• User ID: the part of the operating system that is the
user’s own protected mode and that allows it to
manage the files it creates and executes
– Each application has its own
– Not shared: no other apps can read or alter the app’s
files
– Two apps with same User ID: data is shared
• Supplementary apps
– Necessary for file manipulation tasks
Understanding Operating Systems, 7e
29
Security Management
• Multiple tiered security structure
– Protects user’s data and system’s resources
(including networking resources)
– Provides application isolation: prevents intentional
damage or inadvertent vulnerabilities from a malicious
or poorly designed app
• User installed apps
– Higher vulnerability risks than pre-installed apps
Understanding Operating Systems, 7e
30
Permissions
• User-defined permissions
– Individual controls device security
– Resource access must be explicitly given to the app
Understanding Operating Systems, 7e
31
(figure 16.9)
This application requested these four permissions. The app is not installed
until the user agrees to allow access.
© Cengage Learning 2014
Understanding Operating Systems, 7e
32
(table 16.3)
Before installing an app, the user is presented with a list of all the
permissions requested by that application. A few are listed here.
© Cengage Learning 2014
Understanding Operating Systems, 7e
33
(table 16.3) (cont’d.)
Before installing an app, the user is presented with a list of all the
permissions requested by that application. A few are listed here.
© Cengage Learning 2014
Understanding Operating Systems, 7e
34
Device Access Security
(table 16.4)
Each mobile device can be set to an appropriate level of the security.
© Cengage Learning 2014
Understanding Operating Systems, 7e
35
Device Access Security (cont’d.)
• Strong passwords: highest built-in security level
• Google’s recommended two-step process to build a
strong password consisting of numbers, letters, and
symbols:
1. Start with a random phrase that is easy to
remember.
2. Insert random numbers, capital letters, and special
characters to make it even harder to guess.
Understanding Operating Systems, 7e
36
Device Access Security (cont’d.)
• Passwords to avoid
– Dictionary entries
– Keyboard patterns (e.g., 123456)
– Anything that would be easy for someone else to
guess
• Longer passwords are stronger
• Password alternative: Android’s pattern recognition
tool
• Facial recognition: currently not a strong access
control tool
Understanding Operating Systems, 7e
37
(figure 16.10)
To establish the pattern lock security option, the device owner traces a single
line to connect the dots, such as the one shown here. Later, to unlock the
device, the same pattern must be retraced exactly.
© Cengage Learning 2014
Understanding Operating Systems, 7e
38
Encryption Options
(figure 16.11)
For higher security, encryption is offered. It’s a time-consuming option to
invoke, so the device owner should have the device plugged in or at least
fully charged before starting it.
© Cengage Learning 2014
Understanding Operating Systems, 7e
39
Bring Your Own Devices (BYOD)
• Organization’s members connect to a secured
network with own devices
– Greatly complicates network administration
• Many considerations
–
–
–
–
–
–
Cost
Security
Data management
Convenience
Productivity
Other factors
Understanding Operating Systems, 7e
40
Bring Your Own Devices (BYOD)
(cont’d.)
• Raises many questions:
– Who decides which apps will be run on each device,
and which apps can be connected to a secure
system?
– How can productivity improvements attributed to
BYOD be measured?
– Who should pay the usage charges when an
employee’s device is used for both work and personal
activities?
– Is device network access limited to email or expanded
to multiple database access?
Understanding Operating Systems, 7e
41
Bring Your Own Devices (BYOD)
(cont’d.)
• More questions:
– Who controls the data on the device—the personal
information as well as organizational data?
– Who should pay for upgrades in device hardware and
software?
– What happens if the device is misplaced or lost?
– Who else in the employee’s family is allowed to use
the device?
– How are the device and its data managed when the
owner leaves the organization?
Understanding Operating Systems, 7e
42
(table 16.5)
Survey responses to the question, “What business services can employeeowned (personal) devices connect to via your organization’s network?” (Bit9
Report, 2012).
© Cengage Learning 2014
Understanding Operating Systems, 7e
43
User Interface
• Touch screen
– Features icons that are manipulated by the user
– User-selected apps that remain in place when the
user swipes the screen from side-to-side
– “Soft buttons” along screen bottom: allow the user to
perform critical tasks, e.g., go home, go back, or view
open tasks
Understanding Operating Systems, 7e
44
User Interface (cont’d.)
(figure 16.12)
User-definable icons and buttons at the base of the display allow users to
quickly access these functions.
© Cengage Learning 2014
Understanding Operating Systems, 7e
45
Touch Screen Controls
(table 16.6)
Seven primary gestures that users can make on their mobile devices.
© Cengage Learning 2014
Understanding Operating Systems, 7e
46
Touch Screen Controls (cont’d.)
(table 16.6) (cont’d.)
Seven primary gestures that users can make on their mobile devices.
© Cengage Learning 2014
Understanding Operating Systems, 7e
47
Touch Screen Controls (cont’d.)
• “Lights-out mode”
– On-screen buttons temporarily disappear: allows full
screen viewing without distractions
– Screen touch: exits lights-out mode
Understanding Operating Systems, 7e
48
User Interface Elements
• Consistent navigation experience: essential to user
satisfaction
– Android developers: highly encouraged to follow the
same standards regarding the icons’ placement and
functionality
http://developer.android.com/design/index.html
• “Action bar”: top of each app screen
– Stays in place while app is active
– Provides consistent layout
Understanding Operating Systems, 7e
49
(figure 16.13)
Sample action bar. Its four parts must be programmed according to the
published standard so that users enjoy a consistent experience from one app
to another.
(Figure source: http://developer.android.com/design/patterns/actionbar.html)
© Cengage Learning 2014
#1 App icon
#2 View control
#3 Action buttons
#4 Action overflow (additional tasks)
Understanding Operating Systems, 7e
50
(figure 16.14)
A typical action overflow area
revealing six additional actions.
Any that are not currently usable
are shown in light gray.
© Cengage Learning 2014
Understanding Operating Systems, 7e
51
Conclusion
• Android: designed for mobile, multitasking,
multipurpose systems that often have multiple cores
– Powers hundreds of millions of mobile devices in
more than 190 countries
– Open source operating system based on Linux
• Continued success: may depend on app developers’
ability to keep current with new emerging
technologies and to use consistent design elements
– Providing users a seamless experience meandering
from one app to the next
Understanding Operating Systems, 7e
52