Working with Open Source Software
November 7, 2012 3 Comments
Yesterday I mentioned how I got 7 hours of battery life whilst browsing, this was done at a brightness level of 76. After that I decided to run the test again but set the brightness level to 40. This gave me an extra hour , which is about 14% extra battery life. Was I expecting more? perhaps
..
November 6, 2012 3 Comments
I stumbled upon a Chrome OS test case that includes a chromium-browser extension that simulates user browsing. The extension does a 1 hour test split by:
- [First 60% of the test] Browsing: a new website is loaded every minute. The web page loaded is scrolled down one page every second, then scrolled back up one page every second.
- [Next 20%] Email: Gmail is loaded in the foreground tab and audio is streamed from a background tab.
- [Next 10%] Documents: Various Google Docs are loaded.
- [Final 10%] Video: A full screen 480p YouTube Video is played.
Besides the fact that the audio requires flash, everything else worked in the Nexus 7. After a few tweaks to the extension, I had it running on a loop for 24 hours. Also, I changed it so the auto-browsing would start as soon as you launch chromium.
The next thing to do was to write a simple bash script that would launch the browser and log battery life and screen brightness to a file every 15 min. The assumption was that as the system run out of battery it would shutdown, and that last entry in the file would give me the battery life whilst browsing.
I set it to run overnight at a screen brightness of 99. The good news is that the system suspended rather than just run out of juice at about 4:51 AM (according to the browser history). 3 hours later, I resumed it to find it in a good state.
All and all - the Nexus 7 with Ubuntu was browsing for just over 7 hours (7 hours and 12 minutes), so I am pretty happy with that. Although, for any reliable benchmarking, I would need at least 10 samples of the test run. If you want to check out the test, you can find all the code here: http://bazaar.launchpad.net/~vtuson/+junk/load_test_nexus7/
Here is a graphical representation of the results:
The brightness “auto-dim” was a bit disappointing, not to say erratic, and I have filed a couple of bugs against it.
November 5, 2012 2 Comments
I decided to run some browser performance benchmarks from http://peacekeeper.futuremark.com/ in the Nexus 7 running Ubuntu, mainly to see how it compares with other platforms. Here are my basic conclusions as a result of the test:
Unfortunately, I wasn’t able to access the detailed results (it displays blank), any suggestions why? My results are the bottom firefox (257) results, and the top Chrome (629):
October 25, 2012 23 Comments
I just proposed the following blueprint for UDS-R, and I though I will share it here to give it more visibility:
https://blueprints.launchpad.net/ubuntu/+spec/topic-raring-desktop-targets-for-embedded
What does it take to run Ubuntu Desktop on mobile devices?
It’s time to look at the core of Ubuntu and review it through a mobile lens. During 13.04, we will like to measure and improve how the guts of our platform performs against mobile metrics.
Things like battery life, memory footprint, support for sensors… are areas where needs and expectation widely vary between a PC and a mobile devices. 13.04 will be a cycle of exploration and learning. Because there is no better way to learn that getting your hands dirty, our practical exercise will be to get Ubuntu Desktop working on the Nexus 7.
The Nexus 7 exercise will be less like a 100 meters sprint (if you don’t cross the finish line you don’t get a score) and more like Javelin competition. The further that we can throw it, the higher the score!
On those basis, here are 8 types of Javelins to throw and some distance markers to hit for Ubuntu Desktop on Nexus 7:
*Memory Usage* ->Desktop runs well with 1GB RAM ->Desktop, Web Browser and email app all run well within 1GB -> Desktop runs well with 512MB -> Desktop, Web Browser and email app all run well within 512MB
*Power Mangement* -> Instant on ->Suspend/Resume 100 cycles with only 1 error -> boot up time <1 min -> Sensible Auto Suspend policy
*Battery Life* -> CPU on idle <1% -> Standby battery life is > 150 hours -> Battery life while browsing is > 8 hours -> Battery life playing HD video is > 5 hours -> Standby battery life is > 275 hours
*Testing* -> Functional shell test that can be loaded manually into the ROM ->Performance tests can be run -> Automated battery life test -> Automated battery life test
*Desktop Apps* -> Web browser boots < 3 sec -> Email client (local or web apps) -> Music Player -> Video Player -> Games
*Desktop Unity Performance* -> Fast App-Stack switching -> Launcher Reveal time < 2 secs -> Dash Reveal time < 3 secs ->Dash search < 5 sec ->Unity performs >60 FPS
*Functionality* -> Unity Desktop works ->touch input performs well -> Play a youtube video of a cat -> Play an HD movie -> Ubuntu one
*Sensors* -> Mic & Wifi -> Touch -> Camera -> position awareness sensors -> NFC
Click in the blueprint to see a summary of other releated UDS-R sessions.
October 19, 2012 10 Comments
Oh my, seems that the Canonical team has been busy 
link to youtube video - Here
September 26, 2012 1 Comment
If you thought I had concluded my blog series on demonstrating how Ubuntu is the best environment to write up “connected” or “cloud backend” Android Apps, think again!
So far this is what we covered:
The next step is “How to test that it all works on a production environment”. If you have tested to death both your Android application and your web service locally, it is time to check if they will still work in real life. How do we do this? With few simple commands, we are going to deploy the same web service into the Amazon Cloud, and the application in a mobile phone. All managed from the comfort of my Ubuntu Desktop.
Deploying to Amazon Web Services (AWS)
The only pre-requisite here is that you do have an AWS account. Once you are logged into the AWS website, you can find the credentials that you will need to set up your juju environment. You can find a tutorial on how to set up your Elastic Compute Cloud (ec2) environment –> here.
The required information for Juju is stored in the environment.yaml file in the ~/.juju folder. In the following sample file you can see that two environments have been defined:
default: local environments: aws: type: ec2 access-key: YOUR-ACCESS-KEY-GOES-HERE secret-key: YOUR-SECRET-KEY-GOES-HERE control-bucket: juju-faefb490d69a41f0a3616a4808e0766b admin-secret: 81a1e7429e6847c4941fda7591246594 default-series: precise juju-origin: ppa ssl-hostname-verification: true local: type: local control-bucket: juju-a14dfae3830142d9ac23c499395c2785999 admin-secret: 6608267bbd6b447b8c90934167b2a294999 default-series: precise juju-origin: distro data-dir: /home/victorp/myjuju_data
With my environments now configured, it’s time to deploy my services. This first step is to bootstrap my environment:
juju bootstrap -e aws
With the command completed successfully, I can check the status and I will see that the juju control instance is now up and running in Amazon:
juju status -e aws
2012-09-19 11:43:34,248 INFO Connected to environment.
machines:
0:
agent-state: running
dns-name: ec2-75-101-189-208.compute-1.amazonaws.com
instance-id: i-0e4f7174
instance-state: running
services: {}
2012-09-19 11:43:35,322 INFO 'status' command finished successfully
Lets continue deploying the services. As I am only doing testing, I want to pay the minimum for it, it will ask juju to set a constrain to only use micro instances. Then I will deploy a mysql and a lamp service:
juju set-constraints instance-type=t1.micro -e aws juju deploy mysql -e aws juju deploy --repository ~/mycharm local:lamp -e aws juju set lamp website-database="android_todo" -e aws juju set lamp website-bzr="lp:~vtuson/+junk/mytodo_web" -e aws juju expose lamp -e aws juju add-relation lamp mysql -e aws
With all my services now running I can go to the Amazon EC2 instance console and see how they have been deployed as micro instances. I can now also enter the public address for my lamp service and see the ToDo list table as expected.
Testing the Android App on a real phone
Running Juju status, I can retrieve the public url for the lamp service and I replace the uri vairable in the TodoSourceData class with “ec2-107-22-151-171.compute-1.amazonaws.com/database.php”. The next step is to plug a HTC Desire set up on debug mode into my laptop’s usb port. The rest is taken care by the Android Eclipse plug-ins. When I click the run project button, I am presented with a choice of targets:
I just need to press “OK” and my ToDo app is launched in the handset. Opening the menu options and pressing “Sync” fetches the ToDo data from the Amazon services, as expected:
That is all for today! Let me know if you have any suggestions on what else I should cover on this blog series.
September 18, 2012 Leave a comment
Just a brief post to say that I will be talking at DroidCon on 26th October in London. This is what I will be covering:
Most Android apps nowadays are a front or local client for online services, from backing up data to the cloud to providing a cross platform service. This requires developers to have access to not just an Android environment,
but also to a staging server that they can mess with. This requires the app developer to either gain knowledge of how to set up this complex web, or wait for someone to do it for them.
Juju is a service orchestration tool that allows you to deploy cloud applications like WordPress or Mysql to live clouds such as Amazon Web Services (AWS). Juju Charms package the wisdom of experience Dev Ops so anyone can deploy a complex apps with few simple commands. This can first be done to a local environment running in your laptop, and once you are confident on the service, deploy it to a live cloud. Ubuntu ,the leading linux desktop distribution, brings together the best support for Android app development (used by the Google Android team) with an easy to use cloud deployment toolset.
This talk will explore the simplicity of developing an android app that needs to talk to a cloud service. The talk will be framed around an example of a “TODO list” android app that locally stores information into a SQLite database, and then backs-up user data to the cloud. The talk will show how a android developer can deploy, in his or her laptop, a complex web service with just a handful of commands, and then get the application talking to the service form within the android emulator. Join us to grasp how Ubuntu can provide android developers a full test environment in a box.
