State of Mobile Linux

1. State of Mobile Linux Juha-MattiLiukkonen, Jan 5, 2011

2. Contents • Why is this interesting in a Qt course? • Mobile devices vs. desktop/server systems • Android, Maemo, and MeeGo today • Designing software for mobile environments

3. Why is this interesting in a Qt course?

4. Rationale • Advances in technology make computers mobile • Low-power processors, displays, wireless network chipsets, … • Laptops outsell desktop computers • High-end smartphones = mobile computers • Need to know how to make software function well in a mobile device • Qt is big part of Symbian & Maemo/MeeGo API iSuppli, Dec 2008 Nokia terminology

5. Developing software for mobiles In desktop/server computing: Java :== serverC/C++ :== desktop Qt was initially developedfor desktop applications. Mobile devices today aremore powerful than thedesktops 10 years ago. • Android smartphones • Eclipse, Java • Symbiansmartphones • NetBeans / Eclipse, Java ME • Qt Creator, C/C++ • Maemo / MeeGosmartphones • Qt Creator, C/C++ Of particular interestin this course.

6. The elephant in the room • In 2007, Apple change the mobile world with the iPhone • Touch user interface, excellent developer tools, seamless services integration, … • Modern operating system, shared with iPod and Mac product lines • Caught “industry regulars” with their pants down • Nokia, Google, Samsung, et al – what choice do they have? Linux! We don’t talk about the iPhone here.

7. iPad “killed the netbook” • In 2010, Apple introduced another mobile game changer • iPad = basically, a scaled-up iPhone with a 10” touch screen • Bigger case = can fit bigger battery, for~10 hours of intensive use • 7,5 million sold as of Sep 30, 2010 • Phenomenal netbook sales growth fizzled Apple, 2010 NPD, Morgan StanleyResearch, 2010

8. App ecosystems • Powerful mobile computers can run variety of software • Dynamic availability of applications to provide added value over device lifetime • Devices become multi-purpose and adaptable • Voice call functionality a secondary feature • New software design challenges • New user interaction models • Preservation of battery Nokia was ahead of itstime with the Communicatorconcept back in 1996.

9. Mobile device constraints • Mobility = situations change • May lose network coverage • May run out of battery • Software needs to adapt to situation at hand • Mobility = limited resources • CPUs, GPUs not as fast as on desktop systems • Smaller screens, different input devices • Limited amount of battery power Network connections error out. Your app dies while writing to a file. Your app is frozen to let a call through.

10. Cross development • Cannot compile software in the target device • Not enough memory, disk space, CPU power • Poor input/output devices for development • Must use a cross-compile environment • SDK = Software Development Kit • Build software in e.g. QtCreator, compile with SDK tools, install & run in the target device Debugging softwarein target is often abit tricky. Most SDKscome with a deviceemulator.

11. Mobile Linux distributions

12. Linux Distribution • Linux is the operating system kernel • Deals with hardware abstraction • A distribution is a managed collection of software, including the kernel • Device drivers, middleware, user applications • Comes with distributor-defined default settings and applications • Often optimized for specific use(s) • E.g. Ubuntu, Red Hat Enterprise Linux, Maemo

13. Mobile Linux distributions • Maemo • Nokia’s Linux distribution for Internet tablets and high-end smartphones • Powers the N770, N800, N810, N900 • Android • Google’s Linux distribution for Internet tablets and smartphones • Powers many HTC devices, Nexus One, etc.

14. Mobile Linux distributions • OpenEmbedded • Open source project • Best suited for custom adaptations to very small devices • MeeGo • New kid on the block • Combines Intel’s Moblinnetbook Linux and Nokia’s Maemo Linux • First MeeGo devices out in fall 2010

15. Android details • Uses custom Linux kernel • Google maintains a set of Android patches • Applications developed using Java • Google’s custom Dalvik Java VM • 6 versions in active use • 1.5, 1.6, 2.0, 2.1, 2.2 and now 2.3 • Used in various smartphones by HTC, Google, Motorola, LG, etc. There is also a NativeDevelopment Kit (NDK)for building native Linuxapplications. The devices have a bitdifferent resolutions andfeature sets.

16. Android architecture

17. Android points of interest • Custom C library • C library = system calls (interface to kernel), POSIX & ANSI standard library routines • Linux standard is glibc, which is a bit bloated • Android has a stripped down libc • Compatibility issues for generic Linux code • Custom application installation • Apps bundled into .apk “Android packages”

18. Android points of interest • Programming model • Activity • Impements an application view • Service • Background program with no UI • Broadcast receiver • Listens for e.g. battery notifications • Content provider • Shares data from an app

19. Android and Qt • Project Lighthouse = Qt for Android • Project ongoing… not ready for prime time yet • Some limitations of Android Native SDK (NDK) cause problems • Should eventually allow Qt to be the universal (mobile) Linux toolkit! • Google is not very supportive ;-)

20. Maemo details • Uses standard Linux kernel • Applications developed using Qt, C/C++ • Maemo 4 & 5 are GTK based, but even there Qt is the recommended development toolkit • Maemo 4 used in Nokia N800 tablet (deprecated) • Maemo 5 used in Nokia N900 smartphone • Maemo 6 this fall -> MeeGo

21. Maemo 5 architecture

22. Maemo points of interest • Very regular Linux in most ways • Debian based, uses dpkg & apt-get • Uses glibc, gstreamer, X.org, etc. • User interface based on Hildon/GTK+ • Clutter backend for fancy effects • Qt natively supported • Qt apps for Maemo 5 have the Maemo look & feel, support touch input, etc. Nokia SDK = QtCreator +SDKs for Symbian/Maemo

23. MeeGo details • Uses standard Linux kernel • Applications developed using Qt, C/C++ • Replaces both Moblin from Intel, and Maemo from Nokia • Some products released already • Alpha quality 1.0 release May 2010 • Beta quality 1.1 release Oct 2010 • Product quality 1.2 release Apr 2011

24. MeeGo architecture

25. MeeGo points of interest • Mostly regular Linux • Glibc, gstreamer, ALSA, etc. • Not based on any existing distribution, but uses rpm & zypper for package management • User interface modules separated from base platform • Different user interaction models for different use scenarios • Qt is the primary application interface

26. MeeGo points of interest • UX modules • Handheld: touchscreen (meegotouch toolkit on top of Qt) • Netbook: keyboard/mouse • Connected TV: remote control • In-Vehicle Information: touchscreen, joystick • Reference applications for each UX model • System vendors can customize as needed

27. MeeGo points of interest • Stable API • Any MeeGo application can run on any MeeGo certified system • Main part of API is Qt (Core, Gui, Mobility, …) • Also: gstreamer, sqlite, ALSA, D-BUS interfaces to various frameworks, etc. • Goal is to encourage an App Store ecosystem rivaling Apple

28. Why MeeGo is interesting to us • Only credible challenger to Android • Backed by Nokia -> direct impact to Finnish software development scene • Innovative architectural solutions • Aims to become the “industry standard” Linux for modern embedded systems • Will drive Qt development in mobile space You can participatein building MeeGo:go to meego.comand become active!

29. Participate to MeeGo! • Go to meego.com and register as a developer • Participate in community working groups • Discuss in #meego at freenode • Contribute code, documentation, tests • Gain reputation, become a component maintainer • Steering group meetings in #meego-meeting • Help us create the future of mobile Linux!

30. Developing software for mobile Linux

31. Software design considerations • Mobile environment constraints • Limited battery power • Limited CPU power • Limited screen size • Changing situations • Not that difficult to work with, once you know what to avoid • Mobile optimized software runs fast on higher end hardware Design your appfor a CPU from 1990,graphics from 2005, but use modern toolsand techniques.

32. Limited battery power • Typical smartphone battery is around 1300-1500 mAh • An ARM Cortex A8 @ 600 MHz draws 300 mW - an Intel XEON @ 3 GHz draws 130W • Software must do as little as possible • Must not poll for network traffic, user input, ambient light sensors, … • Must not update the screen when in background • Use platform services for notifications Applications mustbecome contextaware.

33. Tools: powertop

34. Limited CPU power • Desktop machines today use 2-4 CPU cores of 2-3 GHz each (4x3 GHz) • Server machines have 3-4x that • Netbooks and smartphones have 1-2 cores of 0.5-1 GHz • Level of parallelization is very different • Maximum throughput is very different • Efficient algorithms work on smartphone level CPUs, and scream on high-end computers

35. Tools: htop

36. Limited screen size • Laptops may have 17”, 1920x1200 screens • Netbooks have 7-13”, max 1280x800 • Smartphones have 3-4”, max 860x480 • Designing a scaling application UI is hard • Dialogs designed for 860x480 may look tiny on 1920x1200 • Dialogs designed for 1920x1200 may simply not fit in 860x480 • Also, what is the input mechanism?

37. Changing situations • May lose network coverage • Applications must degrade gracefully • May start to run out of power • Must absolutely minimize what apps do • Must survive power outages gracefully • Incoming phone call • Applications must yield immediately to allow the high priority task to run You always do checkfor error values fromAPI calls, right? Database transactionsand journaling file sys-tems are your friends.

38. User interaction • Device rotation • Mobile devices often have accelerometers – can tell whether it is in landscape or portrait mode • Applications should register for orientation change notifications and re-layout accordingly • Input methods • Hardware keyboard, virtual keyboard, finger input, Bluetooth keyboards and mice, … • Extra controls such as microphone buttons

39. Catching rotation on Maemo MyReceiverClassinherits QObject, andimplements slot orientationChanged(). MyReceiverClass * receiver = new MyReceiverClass(this); QDBusConnectionsystemBus = QDBusConnection::systemBus(); systemBus.connect("com.nokia.mce", "/com/nokia/mce/signal", "com.nokia.mce.signal", "sig_device_orientation_ind", receiver, SLOT(orientationChanged(QString))); DBus is a messagepassing system. MCE is the Mode ControlEntity (a system process)in Maemo. When MCE sends the sig_device_orientation_indvia the system message bus, your object’s slotorientationChanged() will get called with argument“portrait” or “landscape”.

40. Memory management • Memory leaks cause device to reboot • User will not like this! (user = you) • Careful weeding out of dynamic memory allocation problems is needed • Use QObjects, tools such as valgrind • Limited amount of memory in device • Swapping is slow and expensive power-wise • Use as little memory as you can, free memory when not needed Arguably, Java is betterthan C/C++ in this regardas it handles memorydeallocation automatically.

41. Tool: valgrind • Supports x86, older ARM chips • Full ARMv7 support coming soon • Multiple GUI front-ends

42. Multitasking • Running multiple applications simultaneously requires special care • You run out of memory, and device reboots • Background apps eat all your CPU, and you can’t answer phone calls • iPhone OS just tells your app it’s about to be killed • Your app must save state information to disk, so that it can resume smoothly when restarted This is clever,because onlyone app at atime is in memory.

43. Multitasking • Android does automatic suspend/resume • Stores idle app state on disk automatically • Reloads app state when app is resumed, which causes occasional stalls • Maemo/MeeGo does regular Linux multitasking • cgroups to prioritize process groups in memory • Uses swap to extend physical memory, which causes occasional stalls Android 2.2 hasa task manager,where you can killidle apps by hand.

44. User interface design • Mobile design patterns • Mobilize, Don’t Miniaturize • The Carry Principle • Context Sensitivity • New research coming out all the time • Including 3D interfaces in 1-2 years • Tricky to combine 3D and touch…

45. Multiplatform applications • Qt is supported “everywhere” • Encourages creation of multiplatform applications • But: even if the core application works everywhere, the user interface may not • #ifdef statements in code to instantiate different UI code for different UX environments? • QtMobility APIs to query system features

46. Web widgets • WebKit is the standard web runtime (WRT) • Provided by Android, Symbian, Maemo/MeeGo • Differences in JIT support • Platform service interfaces visible in JavaScript • Applications as widgets run in a WRT process context • Similar considerations as for native applications • Often possible to embed to native applications, sometimes just use in homescreen etc.