4. High level architecture using ARM or x86 Android chipset
Using Android BSP
We recommend choosing
a stable and proven
hardware platform
Hardware bring up and validation
significantly shortened due to
common architecture
1 2
Apps Scopes Shell, Home
Linux Kernel
Ubuntu Platform
Libraries: OpenGL ES, WiFi, Sensors
Unity 8, QT, Application Services
AAL
Android Devices Drivers
7. Stages
1. Kernel enablement & Ubuntu core.
○ A busybox shell through adb
console
○ Test disk I/O using gzip
compression/decompression on
various partitions. This process can
help find driver level errors
2. Integrate LXC & Android system service.
○ A Ubuntu prompt through adb, and
LXC is running properly
○ Observe upstart-property-watcher
running in the background
3. Full system integration.
○ Ubuntu Unity UI appears on the
screen
○ Start verifying higher level
functionality such as Wifi, telephony,
etc.
8. Image Components
Device tarball
The Device tarball contains the Ubuntu equivalent of an Android BSP. Each individual mobile device
will have its own specific device tarball.
Ubuntu tarball
The Ubuntu tarball is considered the “standard” Ubuntu Touch image. As much as possible, it is
common across all Ubuntu Touch devices. This design helps to prevent fragmentation of deployed
devices.
Custom tarball
The Custom tarball is the officially supported method for all Ubuntu Touch downstream consumers,
ranging from commercial OEMs to community remixes, to modify the look, feel, and behavior of
Ubuntu Touch.
10. Images
○ Boot image
This is flashed to the boot partition and is given control by the bootloader in ROM. This is a device dependent image containing the kernel and the initramfs needed
to boot Ubuntu. The initramfs userland bits follow the armhf ABI since it is built from Ubuntu sources. The kernel is ABI agnostic since it does not use floating point
functionality.
○ Recovery (Clockworkmod Recovery image)
Optional for running the device but necessary for OTA upgrades and also usually a good first step when porting Android to a device. This is a Clockworkmod Recovery
image with Ubuntu patches, so it is built from the Android tree.
git://phablet.ubuntu.com/CyanogenMod/android_bootable_recovery
○ System images
This is built from the Android source tree and contains only the bare minimum needed for Ubuntu (Android HAL, initramfs, bionic, vendor blobs and daemons).
Building Android apps, assets and the Dalvik runtime are disabled among other things.
This image is mounted inside an LXC container in the Ubuntu host filesystem and it contains the Android proprietary drivers and is running the Android helper
daemons needed to have proper support for all the hardware peripherals that are not natively supported by Ubuntu and open source drivers. Executables in this
image use the armel ABI.
○ The Ubuntu root file system image
This is a device independent image containing the Ubuntu Touch userland, the closes equivalent to a regular Ubuntu Desktop filesystem. This gets booted to, and in
turn mounts and runs the Android system image inside an LXC container. This is built from the official Ubuntu package archives and by adding a few prebuilt Click
packages.
11. Deploying Ubuntu system
Recovery utils
● ubuntu-device-flash (lp:/ubuntu/goget-ubuntu-touch)
○ File upload & config protocol - adb
Recovery system
○ based on CWM.
○ adb is always on.
○ system-image-upgrader
■ /cache
● Read restore script from /cache/recovery/ubuntu_command
○ GPG verification
■ archive-master.tar.xz
■ archive-master.tar.xz.asc
13. Image Components
Device tarball
The Device tarball contains the Ubuntu equivalent of an Android BSP. Each individual mobile device
will have its own specific device tarball.
Ubuntu tarball
The Ubuntu tarball is considered the “standard” Ubuntu Touch image. As much as possible, it is
common across all Ubuntu Touch devices. This design helps to prevent fragmentation of deployed
devices.
Custom tarball
The Custom tarball is the officially supported method for all Ubuntu Touch downstream consumers,
ranging from commercial OEMs to community remixes, to modify the look, feel, and behavior of
Ubuntu Touch.
14. Customization
● Backgrounds
Normal Unity Shell background and the Welcome Screen background.
○ Shell background
○ Welcome Screen background
● Color Schemes
○ Customized themes
○ Infographic color scheme
the series of circles on the Welcome Screen that displays user’s data
● Audio
● Default Browser settings
○ Bookmarks
○ home page
● Preinstalling Content
○ click packages
○ sample content.
16. Developers have multiple entry points on Ubuntu
Scopes
C++ backend code (no UI)
Lowest effort
Greatest visibility
HTML5
Native/QML
Declarative Language (C++ optional)
Great developer support/Documentation (Digia)
High Developer productivity
Aligned with HTML5 developer critical mass :
• Chrome, Android, iOS
• Webkit/Blink rendering engine
• Apache/Cordova API for offline
17. Scopes terminology
Scope
The search engine itself, talking to a web service or a local database. Its visible representation is a
Dash page.
Standalone scope
A scope that presents a single set of results and queries one single source
Aggregating scope
A scope that acts as a container for multiple standalone scopes. Every scope can be an aggregating
scope, which enable richer content on their Dash pages
Dash page
The visible part of the scope: dash pages present the scope’s search interface and its results. Dash
pages can be marked as favourites, so that they are always pinned in the Dash.
18. Ubuntu is designed to allow for OEM and
Operator differentiation, at the default
service layer, without fragmentation
Ubuntu enables partners to build their own
footprint on Ubuntu devices, creating a rich
core OS experience with scopes
Unprecedented customization capabilities
in comparison to Android and other platforms:
● user account - own user identity
● default UX - with scopes and default apps
● branding and theming - own visual identity
● backend integration -i.e. carrier billing
Differentiate where it matters with Ubuntu
2
3
1
19. Scopes are a a UI toolkit to present
local or remote content and services
in the home screen
Differentiate your device with scopes
to deliver your own default experience
Discoverability of apps, services and
content from multiple sources:
● users are no longer forced to decide
which store to use
● users can focus on finding content
quickly
Scopes | A New UI Paradigm
A user experience where content is front and center
20. Scopes are fast and engaging
Scopes are a fast and engaging way to embed your services in Ubuntu
Self Service Deal finder LBS Service
21. Scopes expose content and services in a rich and engaging
way - allowing OEMs and Operators to differentiate their
offerings in an unprecedented fashion.
Scopes are the tool that defines the core OS experience
delivering content as part of the device UI - a direct channel
to the user.
● The default pages use Scopes to deliver music, video and
apps curated from a number of different sources.
● A scope can deliver information and content to existing
pages or can exist as dedicated device pages.
● Harness the power of Scopes to mix and match a variety of
content to create targeted services (e.g. dedicated pages
for sports fans, city guides, operator self-service etc.)
● Scopes are a breeze to develop. Through a common UI
toolkit, pages are easy to design and layout and the results
are always elegant.
Scopes explained