Transcript Smartphone Architecture and Mobile Apps

COM811 2016 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 provides
the support for the recording and playback of various audio and video file formats.
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 KitKat:
Kernel Version:
More detail at: http://en.wikipedia.org/wiki/Android_version_history
Android Version History
Hardware
• The primary Hardware Platform supporting
Android is the 33-bit ARMv7 architecture:
• The Android
• 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.
• 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
– (Except Google Nexus ?)
• Manufactures implement policy on updates
• Older Smartphones may not be updated
• 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
• Wireless Carriers must update Android with
their comms ‘apps’.
• 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/?fromgroup
s#!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/codestyle.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 apps = 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
• 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
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.
Case Study
• Consider how the understanding 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
• Case Study: Windows Phone 8 Development
Internals:
• http://scisweb.ulster.ac.uk/~derek/com594_2
014/Reading2014/
• Chapter 1: Vision and Architecture
• Chapter 2: App Model and Navigation
References:
• http://scisweb.ulster.ac.uk/~derek/com594_2014
/Reading2014/
• http://software.intel.com/enus/android/blogs/2013/12/11/introducing-4thgeneration-intel-atom-processor-baytrail-toandroid-developers
• http://www.telegraph.co.uk/technology/mobilephone-reviews/9314362/Orange-San-Diego-IntelAndroid-mobile-phone-review.html