Week 9 Presentation

Smartphone Architecture and Mobile Apps

Rationale

• More than in any previous machine, the smartphone architecture and the app are closely integrated;

Android (Google)

• Open Source• The OS Architecture is a stack of software

components using a layered abstraction mechanism

Android Architecture

Application Layer

The User-Interaction Layer: Top layer of the Stack:The Software Developer’s chief interaction at this layer is Testing:

Several standard applications come installed with every device, such as:• SMS client app• Dialer• Web browser• Contact manager

Application Framework

Key functionality:• Activity Manager: Manages the Activity Life-cycle of the Application:• Content Providers: Manage data-sharing between applications.• Telephony Manager: Manages Voice Calls• Location Manager: Location management: GPS or Cell-tower or other AP• Resource Manager: manages all of the resources needed to support a project

• Static code content, bitmaps, colours, Layout definitions, animation, etc.

Library Layer

The Native Libraries comprise the software needed to allow the phone to deal with different types of data. For example, the Media Framework Library providesthe support for the recording and playback of various audio and video file formats.

Open Source Libraries

• Surface Manager: Used for compositing Windows Manager with off-screen buffering. Off-screen-buffering means you CAN’T directly draw on the screen, but your drawings go to the off-screen buffer where they can be combined with other drawings to form the final screen the user will see. This buffer is the reason behind the transparency of windows.

• Open GL/ES & SGL: Used to render 3D and 2D graphics on the screen (respectively).

• Media Framework: Supports playback and recording of various audio, video and picture formats.

Open Source Libraries

• Free Type: is used as font renderer

• SSL: used to communicate with a server using these secure network protocols

• SQLite: Database Engine used in Android

• Webkit: Is the browser engine used to display HTML

• libc: Is a derivation of the standard C library code that was originally developed by Google for their Android operating system based on the Linux kernel. It is the System’s C library.

The Android Runtime

On the same layer as the libraries, the Android Runtime Layer includes a set of Core Java Libraries.

Android Apps are constructed via Java. The Runtime includes the Dalvik Virtual Machine

The Dalvik Virtual Machine

The Dalvik Virtual Machine (2) • The Runtime comprises the DVM and the core

libraries• The DVM is a type of JVM• It is optimized for low processing power• It is optimized for low memory environments• It Runs .dex files (Not .class files)• .dex files are built from .class files at compile time• DVM supports multiple instances of the VM• It implements support for:• Security;• Isolation;• Memory Management;• Threading

Architecture including Hardware Abstraction Layer

Hardware Abstraction Layer

The hardware Abstraction Layer is conceptually between the Libraries and the Kernel. It is essentially the lowest layer which the developer accesses.

This layer provides a software abstraction of the physical hardware and provides the access point for an apps hardware implementation.

The Kernel Layer

Essentially the interface to the hardware: The key functions of the kernel are:• Hardware Abstraction;• Memory Management;• Security Management;• Power Management• Hardware Drivers;• Shared-Library support;• The network Stack

The Kernel is never accessed directly by the developer. Access is via the hardware Abstraction layer

Android Kernel Evolution

Android Version 4.4-4.4.4 KitKat: API 20Android Version 5.0-5.1 Lollipop API 21

More detail at: http://en.wikipedia.org/wiki/Android_version_history

Hardware

• The primary Hardware Platform supporting Android is the 32-bit ARMv7 architecture:

• Intel began providing microprocessors for Android in 2012

Architecture and Apps

• Hardware designed to maintain low power:• Apps not in use are suspended automatically• Suspended apps do not consume power• Apps do not require closing and reopening• Automatic memory management• If memory gets low, inactive apps (and

processes) get ‘killed’ in ‘oldest-first’ order;

Memory Management

• The process is supposed to be transparent to the user

• Lack of care by developers has resulted in ‘task-Killer’ apps on the market. ??

Open Source

• Android Development is done ‘in private’ by Google until release:

• Then the source code is made public• Source code is subsequently modified by

OEMs. (original equipment manufacturers)• Source code does NOT contain proprietary

device drivers

Google Upgrade Policy• Upgrades are typically every 9 or 10 Months• Upgrades are slow to roll-out to devices (compared

to iOS)– This is true for devices not under the Nexus brand– This delay is partly due to the extensive variation in

hardware of Android devices, to which each upgrade must be tailored.

• Manufactures implement policy on updates:– official Google source code only runs on their flagship

Nexus devices.

Google Upgrade Policy• Manufactures implement policy on updates (cont’d):– Porting Android to specific hardware is a time- and

resource-consuming process for device manufacturers, who prioritize their newest devices and often leave older ones behind

– Older smartphones are frequently not updated if the manufacturer decides it is not worth their time, regardless of whether the phone is capable of running the update

– Also, A view persists that not upgrading will incentivise the move to new devices

• Difficult for App Developers to maintain quality of provision in such circumstances?

Impact of Wireless on Upgrade Policy

• Additional delays can be introduced by wireless carriers who, after receiving updates from manufacturers, further customize and brand Android to their needs

• They then conduct extensive testing on their networks before sending the upgrade out to users

• These typically take longer to test and evaluate.

Google Play Services

• In 2012, Google began decoupling core applications from the Kernel

• The objective was that they could be updated independently from Android OS

• Google Play Services: A system-level process which provides APIs for Google Services.

• Essentially enables new OS functionality to be added without a complete OS update.

Contribute to the Android Open Source Project (AOSP)

• Companies and Individuals can contribute to Android Development through AOSP

• Largest contributors are Device and chipset manufactures

• Google has the final say!• To join in, visit the Android contribution

discussion:• https://groups.google.com/forum/?

fromgroups#!forum/android-contrib

AOSP

• Want to fix a bug?• Visit the issue tracker:• https://code.google.com/p/android/issues/list• Contributions are described in detail at• http://source.android.com/source/contributin

g.html

AOSP Quality Control

• Contributions must comply with the Android Code Style Guidelines

• http://source.android.com/source/code-style.html

• Be patient– Google get a huge number of contributions– Most submissions never make it– Some do but Google are very careful

• The next slide shows the Workflow of a patch-

Designing Stable and Responsive Mobile Applications (1)

• Don’t perform resource intensive operations on the main UI thread.– Always use asynchronous tasks or threads to offload

blocking operations• Use efficient data structures and algorithms– Responsive aps = happy users

• Use recursion with care– Never use recursion unless it is absolutely necessary

• Recursion is never absolutely necessary

Designing Stable and Responsive Mobile Applications (2)

• Save your state and assume that your application will be stopped or suspended at any moment– If your application is suspended or closed, you

cannot expect the user to do anything (click a button, or whatever!

– Ensure that your application can resume gracefully

Designing Stable and Responsive Mobile Applications (3)

• Start up fast and Resume fast– You cannot afford to have the user waiting (Mostly

they won’t)• During long operations, inform the user by

using progress bars– Consider offloading heavy processing to a server

instead of processing on the device• Better performance• Saves battery drainage

Designing Stable and Responsive Mobile Applications (4)

• Ensure that long operations are likely to succeed before embarking upon them– For example, if your application downloads large

files, check for network connectivity, file size, and available space before attempting the download

Designing Stable and Responsive Mobile Applications (5)

• Minimize use of local storage – Most devices have very limited amounts– Use external storage• Remember that an SD card is ‘external storage’• Remember also that SD cards can be ejected• Remember also that SD cards can be swapped• Your app should handle all of these scenario’s gracefully

Designing Stable and Responsive Mobile Applications (6)

• Understand that data calls to content providers (and across the AIDL boundary) have a performance ‘hit’ so use judiciously– http://developer.android.com/guide/components/aidl.html

• Establish an application resource-consumption model and verify that this matches your target audience.– Gamers might reasonably anticipate and accept shorter

battery life– Productivity app users will expect lightweight power drainage

and in any case won’t always carry a charger!

Common mistakes in app development

• Trusting the emulator– You must test on a real device

• Forgetting to add new application activities and required permissions to the AndroidManifest.xml file

• Forgetting to display Toast messages using the show() method• Hard-coding information, such as network info, test user

information and other data into the application• Forgetting to disable diagnostic logging before release• Distributing live applications with debug enabled

Design for Easy Upgrades and Updates

• Updates: Modifying manifest information and redeploying the updated application on user devices– Schedule updates so that they are frequent enough to

be useful, but not so frequent that the user is constantly interrupted• You must have an update strategy

• Upgrading: Creating a new application package with new features, and deploying it as a separate application that the user must choose to install

Windows Phone 8

• One standard hardware platform• Strictly controlled• Any manufacturer can make a Windows Phone• All functionality including the UI is standard• No manufacturer specific interfaces or system

software• Security Model

Windows Phone 8 Platform Stack

Platform Services

• Package Manager: Responsible for installing/uninstalling apps and maintaining all of their metadata throughout the app lifecycle.– keep track of which apps are installed and licensed– persists information about any app tiles that the user might have

pinned to the start screen• Execution Manager: Controls all of the logic associated with

app’s execution lifetime:– creates the hosting process for the app to run in and raises the

events associated with app startup/shutdowns/deactivations– it performs a similar task for background processes which also

includes proper scheduling of those tasks

Platform Services• Navigation Server: Manages all the movements between foreground apps

on the phone. – i.e. when you tap an app tile on the Start screen, you are navigating

from the “Start app” to the app you choose, the Navigation Server is responsible for relaying that intent to the execution manager so that the chosen app can be launched.

– Similarly, when the back button is pressed the Nav Server is responsible for telling the execution manager which app to reactivate.

• Resource Manager: Responsible for ensuring that the phone is always quick and responsive by monitoring the use of system resources (specially CPU and memory) by all active processes and enforcing a set of constraints on them– If the app or background process exceeds its allotted resource pool, it

is terminated to maintain the overall health of the phone

Security ModelModern smartphones are by far the most personal items that people have ever owned:

In palm of your hand are the names, phone numbers and addresses of al of your family and friend, thousands of photos, location history, email, and increasingly, financial information stored in mobile wallet apps.

Ensuring that all of this info remains safe while the phone moves between physical locations and navigates a variety of websites and apps requires a robust security model

Security Chambers and Principle of Least Privilege

• The Windows Phone Security model is based on the concept of Security Chambers:– Isolated containers in which processes are created

and executed• Chambers are granted ‘Access Rights’• Access Rights are granted on the principle of

Least Privilege– An app should not be granted the rights to do

anything beyond what is strictly necessary to perform its stated functions.

Home Study

• Consider how the understanding of the platform design supports all of the concepts discussed:– For example, How does Windows Phone 8

implement Least Privilege– How does Android compare

• What advantages does learning the OS/Hardware Architecture bring to the app designer and developer?

• Support your views with specific examples

Microsoft Windows Phone 8

• Additional Reading: Windows Phone 8 Development Internals:– Chapter 1: Vision and Architecture– Chapter 2: App Model and Navigation

References:

• http://software.intel.com/en-us/android/blogs/2013/12/11/introducing-4th-generation-intel-atom-processor-baytrail-to-android-developers

• http://www.telegraph.co.uk/technology/mobile-phone-reviews/9314362/Orange-San-Diego-Intel-Android-mobile-phone-review.html