Your SlideShare is downloading. ×
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Ubuntu phone engineering
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Ubuntu phone engineering

1,207

Published on

How to build a Ubuntu Phone.

How to build a Ubuntu Phone.

Published in: Software, Technology
0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,207
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
85
Comments
0
Likes
12
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Ubuntu Phone Engineering The Phone Delivery Team 2014-04-30 edited. (2014-04-09) Rex Tsai <rex.tsai@canonical.com> © 2014 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.
  • 2. Architecture overview
  • 3. Ubuntu Stack
  • 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
  • 5. Hardware enablement
  • 6. Boot process
  • 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.
  • 9. Deployment
  • 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
  • 12. Easy customization of look, feel, and behavior
  • 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.
  • 15. Scope
  • 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
  • 22. Scopes registry
  • 23. Scopes data flow
  • 24. References ● Ubuntu Developer http://developer.ubuntu.com/ ○ Scope http://developer.ubuntu.com/scopes/overview/ ● Mir: Welcome to Mir http://unity.ubuntu.com/mir/ ● Touch - Ubuntu Wiki https://wiki.ubuntu.com/Touch ○ Touch/Porting https://wiki.ubuntu.com/Touch/Porting ○ Touch/Deploying https://wiki.ubuntu.com/Touch/Deploying ● OEM Customization http://developer.ubuntu.com/resources/oem/ ○ Ubuntu Image Architecture http://developer.ubuntu.com/resources/oem/architecture/

×