PPT ch16

Chapter 16
Android Operating Systems
Mchoes/Flynn, Understanding Operating Systems, 8th Edition. © 2018 Cengage. All Rights Reserved.
1
May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Learning Objectives
After completing this chapter, you should be able to describe:
• The design goals for the Android™ operating system
• The role of open source software
• How Android works with its Linux foundation
• How system security challenges are managed
• The critical role of Android application developers
2
Introduction
• Android
o Designed to run mobile devices: specifically smartphones and tablets
o Built on a Linux foundation
o Customizable user interface
• Allows user to customize app configurations
o Open source operating system
• Key elements, but not all, of the source code are published
3
Brief History (1 of 5)
• Android operating system
o Developed by Any Rubin and associates
o Designed to power the Sidekick cell phone
• Initial challenges
o Phone battery power limitations
o Small CPU
o Limited memory space
• Design team solution
o Multilevel system integrating Linux: user actions performed via unique apps from
the phone’s screen
4
• Google purchased Android (2005)
• Rubin joined Google
• Android extended to reach entire mobile smartphones and tablets
generations
o “More than 750 million devices have been activated globally; and 25 billion apps
have now been downloaded from Google Play”
o Larry Page, Google CEO (2013)
5
(figure 16.1)
The Android robot logo can be used only in compliance with the terms described in the Creative
Commons Attribution License.
© Cengage Learning 2018
6
(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. From https://source.android.com/source/build-numbers.html
Year Release Code Name Features

2008 Version 1.0 First product available to the public.
2009 Version 2.0 Eclair Based on Linux kernel 2.6.29.
2011 Version 3.0 Honeycomb A table-only version based on Linux kernel 2.6.36.
2011 Version 4.0 Ice Cream Sandwich Based on Linux kernel 3.0.1.
2012 Version 4.1 Jelly Bean Based on Linux kernel 3.0.31.
2013 Version 4.4 KitKat Based on Linux kernel 3.10
2014 Version 5.0 Lollipop Based on Linux kernel 3.16.1
2015 Version 6.0 Marshmallow Based on Linux kernel 3.18.10
2016 Version 7.0 Nougat Based on several Linux kernels
7
• Android’s source code: available with each new release
o Manufacturers and enthusiasts can prepare their installation and customized
software
• Device’s Android version number and Linux kernel version number
o Available under Systems menu
8
Design Goals
• Enchant me
o Sleek and aesthetically pleasing design
• Simplify my life
o Make life easier
• Make me amazing
o Empower people to try new things and to use apps in inventive new ways
9
Memory Management (1 of 2)
• Handled by the Linux kernel: supported by several software modifications
o 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
o Least recently used (LRU) algorithm for tracking
o Low memory killer (LMK) frees memory when memory becomes scarce
10
Memory Management (2 of 2)
(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
https://developer.android.com/guide/practices/screens_support.html.)
11
Processor Management (1 of 2)
• 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
o AndroidManifest.xml
• Activity: application component that defines the user interface screen that the
individual uses to interact with the application
o Including all the actions that can be performed
12
Processor Management (2 of 2)
• Task: “sequence of activities a user follows to accomplish a goal”
o Can involve one or many apps
o 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
o Allows apps to call on one another as needed to meet a user’s request
13
Activity States (1 of 7)
• Created state: transient state when the activity has just begun
• Started state: software initialization begins and the first screen can be drawn
o Generally considered the main screen
• Resumed state (running state): activities execute until they are interrupted by
another activity or a user command
14
• 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
o Subsequently, activity may be terminated or it may be recalled
• Destroyed state: formal indication that the activity is terminated
o Will be removed completely from system memory
o Background activities closed properly to prevent memory leaks
• Terminated: the app has been ended
15
(figure 16.5)
The changing states of a typical activity from Created to Terminated. Typically, activities are
removed from memory, or terminated, only from the Paused, Stopped, or Destroyed states.
16
• Back stack: data structure
o When new app is loaded, replaced app is moved onto the stack
o Loading and unloading uses last-in, first-out (LIFO) scheme
o User navigates previously viewed apps using the screen’s “back” button
17
(figure 16.6)
The back stack is loaded using the last-in, first-out (LIFO) scheme. The activity status of the current app is
loaded into the back stack when that app is interrupted for another one. Later, each app is restored, in
reverse order, each time the user presses the back button.
1. Open the email inbox

2. Open a message
3. Follow link to a sender’s website
4. Click on website video side link
18
(figure 16.7)
Detailed view of the Activity Lifecycle and the system callbacks that move an activity from one
state to another. (Illustration source: https://developer.android.com/training/basics/activity-
lifecycle/starting.html)
19
• Smoothly running Android system
o 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
20
Device Management (1 of 6)
• Apps are designed to accommodate numerous devices, often without user
help
• Screen requirements
o Design considerations: screen size, screen density, orientation, and resolution
o Density-independent pixel (dp): equivalent to one physical pixel on a 160 dpi
screen
o Interface design using dp unit: system can perform the necessary scaling for
each screen based on its size, resolution, orientation, and density
21
(table 16.2)
Four device display variables that directly impact the design of user interface screens.
Design Factor Sample Values What It Means

Screen size Phone: 3 in (5.1 cm) The screen's physical size as measured from one corner
Tablet: 10 in (25 cm) diagonally to the other.
Screen density Phone: 164 dpi The number of pixels located within a certain area on the
Tablet: 284 dpi screen, such as a one-inch line.
Orientation Portrait (vertical)
Two potential screen orientations as viewed by the user.
Landscape (horizontal)
Resolution Phone: 240 × 320
The number of physical pixels.
Tablet: 1280 × 800
22
• Android’s four screen sizes categories
o Extra-large screens: at least 960dp × 720dp
o Large screens: at least 640dp × 480dp
o Normal screens: at least 470dp × 320dp
o Small screens: at least 426dp × 320dp
• Ultimate app designer’s goal
o Give every user the impression that the app was designed specifically for the
user’s device
23
(figure 16.8)
A comparison of four general physical screen sizes supported by Android, not drawn to scale.
The physical size is measured as the diagonal distance of the screen from corner to corner.
Each screen is measured by a virtual measurement called a density-independent pixel (dp).
24
• Battery management
o Android device’s battery usage information: Settings tab
o Ways to improve 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
25
(figure 16.9)
This device has more than six hours of battery
time remaining; and the operating system is only
using three percent of the device’s battery
resources. Available from the Settings, System,
Battery menu.
26
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
o Each application has its own
o Not shared: no other apps can read or alter the app’s files
o Two apps with same User ID: data is shared
• Supplementary apps
o Necessary for file manipulation tasks
27
Security Management
• Multiple tiered security structure
o Protects user’s data and system’s resources (including networking resources)
o Provides application isolation: prevents intentional damage or inadvertent
vulnerabilities from a malicious or poorly designed app
• User installed apps
o Higher vulnerability risks than pre-installed apps
28
Permissions (1 of 3)
• User-defined permissions
o Individual controls device security
o Resource access must be explicitly given to the app
29
(figure 16.11)
This application requested numerous
permissions and some actions may cost
the user money. Android will not install an
app unless and until the user agrees to
allow the requested permissions.
Available from the Settings, Applications,
Applications Manager, and by clicking on
the app of interest.
30
Requested Permission Application’s Reason for the Request
(table 16.3)
Accounts Find accounts that have been set up for this device.
Before installing an app, the user is
presented with a list of all the Development Tools Test access to protected storage.
application’s requested Hardware Controls Record audio and activate the camera to take picture and/or videos
permissions, which can range from and/or modify haptic (vibration) controls.
none to many. A sample is listed Location Learn approximate user location using network information and/or
here. For more details see: precise GPS location.
https://developer.android.com/guid
e/topics/security/normal- Network Communication View and control network connections and/or Near Field
permissions.html Communication.
© Cengage Learning 2018 Personal information Read and/or modify contact lists or the call log, write to the dictionary.
Phone calls Read the status of the phone and identify callers.
Service that cost you
Directly call phone number and send message.
money
Storage Modify and/or delete contents of the device’s storage.
System Tools Access Bluetooth settings, connect and disconnect from Wi-Fi, modify
system settings, retrieve running apps, toggle synchronization on and
off, delete app cache data, disable the screen lock, close other apps,
run at startup, uninstall shortcuts, write Home setting, prevent the
device from sleeping, and more.
31
Device Access Security (1 of 4)
(table 16.4)
Each mobile device can be set for access that’s either fast or secure. Note: Early builds support
facial recognition but this is no longer recommended.
Technique Security Level

Password Matching Higher security
PIN Matching Medium to high security
Pattern Recognition Medium security
Face Recognition Low security
Finger Swipe No security, open access
32
• Strong passwords: highest built-in security level
• Google’s recommended two-step process to build a strong password
consisting of numbers, letters, and symbols:
o Start with a random phrase that is easy to remember.
o Insert random numbers, capital letters, and special characters to make it even
harder to guess.
33
• Passwords to avoid
o Dictionary entries
o Keyboard patterns (e.g., 123456)
o 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
34
(figure 16.12)
To establish the pattern lock security option, the device’s owner must trace a single line, connecting the
dots, as shown here on a tablet. Experts suggest varying the direction of the line, bottom-to-top or right-to-
left, to make it more difficult for someone else to guess.
35
Encryption Options
(figure 16.13)
For higher security, encryption is offered. This is a time-consuming option to invoke, so the device owner
should have the device plugged in or at least fully charged before starting it. On this tablet, it’s available
from the Settings, Personal, Security menu.
36
Bring Your Own Devices (1 of 3)
• Organization’s members connect to a secured network with own devices
o Greatly complicates network administration
• Many considerations
o Cost
o Security
o Data management
o Convenience
o Productivity
o Other factors
37
• Raises many questions:
o Who decides which apps will be run on each device, and which apps can be
connected to a secure system?
o How can productivity improvements attributed to BYOD be measured?
o Who should pay the usage charges when an employee’s device is used for both
work and personal activities?
o Is device network access limited to email or expanded to multiple database
access?
38
• More questions:
o Who controls the data on the device—the personal information as well as
organizational data?
o Who should pay for upgrades in device hardware and software?
o What happens if the device is misplaced or lost?
o Who else in the employee’s family is allowed to use the device?
o How are the device and its data managed when the owner leaves the
organization?
39
User Interface
• Touch screen controls
o Features icons that are manipulated by the user
o User-selected apps that remain in place when the user swipes the screen from
side-to-side
o “Soft buttons” along screen bottom: allow the user to perform critical tasks, e.g.,
go home, go back, or view open tasks
40
Touch Screen Controls (1 of 2)
(table 16.5) Gesture Actions Meaning
Primary gestures that Touch Press and then lift Starts the default activity for this item. When used
with a virtual on-screen keyboard, this allows typing.
users typically make on When used with a graphics app, it allows drawing.
their mobile devices.
© Cengage Learning Long press Press, move, and then lift Moves into the data selection mode and allows the
user to select one or more items in a view, and act
2018 upon the data using a contextual action bar.
Swipe Press, move, and then lift Moves to content located in a neighboring view,
generally in the same hierarchy.
Drag Long press, move, and then lift Rearranges data from one place to another within
this view, or moves data into a directory, folder, or
other container.
Double Two touches in quick succession Zooms into content currently displayed. When used
touch within a text selection context, it is also used as a
secondary gesture.
Pinch open Two-finger press, move them apart, and Zooms into content, offering a closer perspective.
then lift
Pinch close Two-finger press, move them together, and Zooms away from content to offer a wider
then lift. perspective.
41
Touch Screen Controls (2 of 2)
• “Lights-out mode”
o On-screen buttons temporarily disappear: allows full screen viewing without
distractions
o Screen touch: exits lights-out mode
42
User Interface Elements (1 of 3)
• Consistent navigation experience: essential to user satisfaction
o Android developers: highly encouraged to follow the same standards regarding
the icons’ placement and functionality
https://developer .android.com/design/index.html
• “Action bar”: top of each app screen
o Stays in place while app is active
o Provides consistent layout
43
(figure 16.13)
Sample action bar. Its four parts must be programmed in accordance with the published Android
standard so that users can expect a consistent interface from every app.
(Source: https://developer.android.com/design/patterns/actionbar.html)
#1 App icon
#2 View control
#3 Action buttons
#4 Action overflow (additional tasks)
44
(figure 16.15)
A typical action overflow area reveals additional actions. Any actions that are not currently usable,
such as Sort By, are shown in a lighter color.
45
Conclusion
• Android: designed for mobile, multitasking, multipurpose systems that often
have multiple cores
o Powers hundreds of millions of mobile devices around the world
o 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
o Providing users a seamless experience meandering from one app to the next
46

PPT ch16

Uploaded by

Copyright:

Available Formats

PPT ch16

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PPT ch16

Uploaded by

Copyright:

Available Formats

Chapter 16

Android Operating Systems

Year Release Code Name Features

1. Open the email inbox

Design Factor Sample Values What It Means

Technique Security Level

You might also like