PPT - Your Projects
Download
Report
Transcript PPT - Your Projects
COM594: Mobile Technology
Lecture – Week 8
Smartphone Architecture and Mobile Apps
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.
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:
Android Version 5.0-5.1 Lollipop
API 20
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 resourceconsuming 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/contributing.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 Android
Interface Definition Language (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