Google announced new project to help developers. They called it “Android Design”. This is a website where Google present how to create good application with actual GUI patterns. In Android 4.0 Google presented new UI, new Robot font and improved Holo Theme from Android 3.x. Now is a moment to standardize UI in old and new applications, so please read all new information from Android Design and create simpler and good looking application.

One of the most common causes of fragmentation is limited hardware specs, whether it’s small RAM, slow processor or low resolution screen, they all create a challenging environment for Android application developers aiming for ultimate device compatibility. A lot of Android developers face memory issues on low costs devices and this is how it usually goes: You created a bitmap and your application throws an OutOfMemory exception but there is still a lot of free memory and you are left wondering: What is the source of problem? How to limit this? Let me explain.

Android has two kinds of stacks – one for application and one for graphics. In an activity method setContentView(int i) Android inflates XML layout and initializes all objects. In this part of code every graphics object is located in a memory. This same situation happens when your application creates a Bitmap object. Android creates object in the graphics stack and sends reference to it and sometimes, for one reason or another,  you will receive an OutOfMemory exception.

I discovered this problem when I was testing my application with our product – Testroid Cloud ( Online cloud of real Android devices for running automated tests for Android applications).

When I was running my automated tests on all Android devices, I was constantly getting OOM exceptions on same devices – mostly  on low spec ones. It was very strange because when I started debugging, I found out that there was still free memory left but my application just could not access it. I tried to search for a solution but all tracks pointed to a comment from a Google staff: “Your application uses too much graphics and you don’t manage your memory”. It was a strange answer because Java has garbage collector and, because of that,  I thought I don’t have to delete objects manually.

On the behalf of everyone here at Bitbar, allow me to thank each of you for  participating in the Testdroid story this past year—and take a moment to share some of the highlights.

2011 Highlights

• Testdroid Cloud service with real Android devices was launched about 6 weeks ago and our user base has grown dramatically.
• In only 6 weeks we passed the 20,000 completed tests mark on Testdroid Cloud.
• We also saw over 1,000 different customers using our products, including most of the leading technology companies and start-ups around the world.
• We have rapidly increased the number of Android devices in our device cloud and are adding new devices every day.
• Our current range of devices cover over 90% of the Android user base.

Testdroid Cloud has now been in closed beta for 6 weeks and we have had a great opportunity to iron out most of the obvious technical and operational challenges. We have been adding new devices to Testdroid Cloud on weekly basis and well will continue to do so. We have made several usability improvements and introduced several new features based on beta user requests. Please keep sending new feature suggestions – we will implement them as you can see from the list below. Now that the scalability is proven we are opening the beta for everyone. You can sign up by leaving your e-mail address here.

One of reasons for running a beta is to gather feedback from users to make the service more fit for purpose for real users. This is what we have done and we will continue to do this in the future as well. The features added during the beta include:

Screenshot baseline:
The screenshot feature of Testdroid Cloud seems to be one of the most popular ones. It is true that it is quite amazing to see your app exactly how it looks on each real Android device – pixel to pixel. Based on a user recommendation the screenshot view is now even better with Screenshot Baseline feature. Now for every screenshot on every device you can mark a screenshot to be a baseline (i.e. this screenshot looks exactly as it should) and then every time you run your tests the new screenshots will be compared to your baseline screenshot and if they are not exactly the same you will be notified. To make things even better, this feature can show you exactly how the screenshots differ from each other!

Running a specified subset of tests:
Sometimes you may may want run only certain subset of your tests or you want to run your tests in a specific order. With Testdroid Cloud you can now specify exactly which test classes or test packages will be run and you can even specify the execution order by using a comma between the test class or test package names. This feature was also suggested by an active Testdroid Cloud beta user and now everyone can benefit from it.

Recording timeline:
Recording timeline feature is actually an improvement in Testdroid Recorder but Testdroid Cloud users reap the most benefit out of this feature request. Now Testdroid Recorder has an option to capture the time between user actions during recording and then repeat the same user actions with exactly same time intervals during the playback. This feature is very useful for instance when your application accesses a web service to retrieve some data or does some other time consuming processing before the the user can continue. Especially when you are running the same test on very different kinds devices with wildly different performance this feature makes sure that the user inputs in tests are not entered too early.

How do we do all this?
A lot of people are asking how we are able to automatically control all these devices and what is the exact setup. Here are some answers: Yes, all the devices are real physical Android devices connected to clusters of Testdroid Servers. Before every test run Testdroid Server uninstalls all non system applications, formats the SD-card and reboots each phone. All this is done to ensure that each phone has a consistent starting state and to ensure that there are no data or processes running from previous test. Then when the test execution starts, Testdroid Server installs the application under test and starts executing the tests. (This in done in parallel in asynchronus way to optimise the capacity of Testdroid Cloud) Once tests are finished Testdroid Server copies the results from each phone and publishes them on Testdroid cloud. Below is a screenshot of the device management view of Testdroid Server to show how easy it is to manage tens of Android devices in one server.

And last but not least this is how our device racks look like. The sound of all these phones rebooting at the same time is amazing

Pricing
Some users have been asking about the pricing of Testdroid Cloud and we can tell you at this point that there will be always some free user level and some features and higher test execution priority will cost something. We are currently working on the pricing model but we want to take our time to ensure it will be fair and that there will be options for developers of all shapes and sizes. If you like what you see on Testdroid Cloud but would prefer to run your tests on your own phones you can contact sales (at) bitbar.com for more details.

And here it is! Testdroid Recorder 1.1.12 arrived. In this release we add great new timeline recording feature. Robotium and monkeyrunner tends to playback tests as fast as they can. However, if your application needs to do something time consuming after the action, it may not keep the pace of a test. For example, when your application fetches data from a server, the delay caused by network latency and server reaction might cause test to fail.

The new version of Recorder observes not only your actions but the intervals between them. It places sleep() between test commands, so they will be executed with the pace they were recorded. It prevents tests from failing due to too fast execution. Please note that when you are pausing the recording, the time spent in pause is not taken into delay interval.

However, if the situation is different – test is Wile E. Coyote and your application is a Road Runner – the timeline recording can be turned off. Go to Eclipse->Window->Preferences->Testdroid->Robotium and tick off checkbox Preserve intervals between actions.

Have fun with the new Recorder!