The Big Rocks of August

Have you ever heard the phrase "If you don't put the big rocks in first, you'll never get them in at all"? It's from an oft repeated parable about life and also project management.

Last week I met with Canonical's Ubuntu Engineering leadership team (me, the Directors, Engineering Managers, Tech Leads, and Architects). We took a close look at the progress of Ubuntu Touch from many points of view. All in all, I left last week feeling quite satisfied that Ubuntu Touch for phones was on track for a very good 1.0 release in October. However, we identified that there were some "big rocks" that we didn't get in the jar yet, and that we needed to get them in asap if we were going to finish with the kind of systematic development process that will be necessary to make 13.10 rock.

So, we set the goal for August to get all the big rocks in. The 5 big rocks ...

Image Based Upgrades

Blueprint is here

The first big rock is Image Based Upgrades. Today, when we "bless" a new image, one must use a tool on your desktop called "phablet-flash" to update to that new image. After August, the phone will download updates over wireless and install them without requiring a connection to the desktop. As you can see in the blueprint, this requires some deep changes to the way Ubuntu works (as well as to our automated testing) in order to do it as robustly as is necessary for this market (a.k.a. no "dpkg --configure -a"). The disks must be partitioned so that the system is total separate from user data. The server must calculate the binary diff of an update for that partition, and the diff must be applied safely and reliably.

All of this work is in place now on the client and server and being tested. Wet need to bring it together and start using it. We will do so in August.

Indicators

Ubuntu touch is designed to support user settings in 2 ways. The most common and dynamic settings are available from the indicators, others from the settings application.

The settings application has a long tail of settings, some more important than others. The indicators, have limited, but critical functionality. By the end of August, all of the indicators will be functional. As a result, most of the back-end work will be in place to finish settings in September and October as well.

Click

Martin Albeseti is working on a new video, but there is as starter one here if you want to see an end to end demo.

How developers write applications, how users install applications, and how those applications run ... what a huge topic. By the end of August, Ubuntu Touch will be doing this in a different and new way.

Of course, we all know that developers will use the sweet Ubuntu SDK to get write their sweet apps ;) However, did you know that developers will not need to package those apps into deb files? Rather they will make a simple click package that includes their code and all of their dependencies (in the case that they have dependencies that are not part of the SDK). Click packages are easy to create with Click, and support for this is even built into Qt Creator. So writing and packaging an app is now, finally, fun and easy for Ubuntu Touch.

But how will users find applications to install in Ubuntu Touch? Developers will be able to upload their applications and after a very quick review to ascertain that the requested permissions (more on that below) are reasonable, users will be able to find their apps in the apps lens! What could be easier. With a simple button click in the dash, the application will be downloaded and installed by Click.

The reason we can do such a light review is due to the something called "application confinement" which has already landed and is running on Ubuntu Touch today. Application confinement causes an application to run under apparmour, which means that the kernel controls what it has access to. As such, it is very very difficult for an application to do anything naughty.

Now, an application that is totally confined may be useful, but it may be desirable for an app to interact with data from other apps. For example, what if you wanted to import a picture from the phone? To support that, there will be a series of trusted helpers and services which can securely provide an application the data that it needs with a few simple SDK calls.

After August, when Click is working end to end on the phone, we can spend September and October adding the rest of the important features, like updating applications.

Application Lifecycle

Speaking of SDK calls, how do applications behave on the phone? On the desktop, an application can just run and run, because they have big batteries and are normally plugged in. So, a traditional Linux desktop does nothing to manage an application's use of resources.

This can't work on a phone. The reason this can't work is that phones have small batteries and are rarely plugged in. So a typical phone OS does not allow applications to just do what they want.

For Ubuntu Touch, when an application is put into the background today, it is stopped. Not killed, just stopped. The app can't use any resources and is essentially "frozen in time" until it comes to the front again. This ensures that a crazy application is only consuming resources when it is in the front, where the user is using.

But we have some work to do in August to finish the application lifestyle. First, what happens when you have so many applications open that there is no more memory? The OS has to do something to make room. In Ubuntu Touch, the OS will kill any stopped applications that haven't been used in a while in the case of low memory. But wait! you say. Won't that mean my apps get killed and I have to relaunch them and lose all my work and everything?

The answer to this problem is simple, when an application goes into the background, it will get a signal and a little time. The application can use the time to save whatever info it needs to rebuild itself in the case it gets killed while it is in the background. When the app gets called to the foreground, it can then use a little time to read whatever info it saved and rebuild itself. The result for the user will be that the app appears to just keep on running. Nice!

But Wait! What about apps that should work in the background? For example, the Music Player should keep playing while it is in the background, right? The answer to this is "sort of". An app shouldn't do anything that it would want to do in the background, but it should rather use services that work outside the scope of any one app. So the Music Player shouldn't make function calls to play music, but should rather call a system service and tell the system service what music to play.

There are several services like this that we will need in place by end of August, these include:

1. Music
2. Download
3. Telephony
4. Alarms (time)
5. Friends
6. Content
7. URI Handler
8. NITZ
9. Contacts

These services are "complete" when one can use them from the Ubuntu SDK.

Unity 8/Mir

Finally, Unity 8 (for phone only right now) is in the archive. Mir is almost in the archive. It's time to get these into the phone images so that we can spend September and October doing some nice refinements!

Conclusion

Of course not everyone in the Ubuntu community is working solely on these big rocks. So lots of other exciting stuff will happen as well. However, It's important that we get these 5 big rocks done in August. That will leave us September and part of October for us to work on the remaining list of features and requirements in priority order. After August, Ubuntu Touch will have made a dramatic step forward, really becoming the architecture that it is meant to be. I can't wait!