Category Archives: Testing

Google Cloud Test Lab for Android

While it was not the most exciting announcement at Google I/O, one of the most useful services announced was that of the upcoming Cloud Test Lab. Cloud Test Lab allows Android developers to have their apps automatically tested on real physical devices. Sounds pretty cool eh? Well it gets better, on launch it will have 20+ Android devices and it’s free! Well some features will be free anyway. Here is how Google describe the service:

For comprehensive testing before releasing your app, Cloud Test Lab gives you access to physical devices so you can see what’s going on for your users in the real world. Plus, you can run all of your tests across all devices, all at the same time—giving you access to massively parallel testing, bringing you deep and scaled insight.

Cloud Test Lab

What you need to know

Google Cloud Test Lab

Website: https://developers.google.com/cloud-test-lab/

Current Status: Early Access sign up is now open

Estimated Release Date: September 2015

Device support: 20+ devices on launch

Cost: Free for basic functionality

Sign Up: Follow the links from your Google Play Developer Console account, as shown below.

Link to signup to Cloud Test Lab

Figure 1: Signup to Cloud Test Lab from the Developer Console

The Early Access Form is simply a few questions as shown below. You will need to have an app published though the Developer Console to apply.

Cloud Test Lab signup

Figure 2: Early Access Form for Cloud Test Lab

Cloud Test Lab functionality

The Google Cloud Test Lab is based on technology from Appurify, which Google acquired back in June 2014. Appurify have some pretty awesome technology, so this is a service that is packed with potential.

As this is a yet to launch service, details from Google are a bit vague at the moment. Here are a couple of important statements that give a bit more of a hint of what we can expect.

Every APK submitted to Play Store’s Alpha and Beta channels will be automatically scanned on more than 20 physical devices and get a free launch performance report. Developers who want to run customized testing can eventually purchase it through Cloud Test Lab.

My hope is that Google’s strategy won’t be to focus on making money directly from this venture but use the service to drive an improvement in the quality of apps. The service has the potential to make it faster and easier for developers to deal with the issues associated with the fragmentation of Android devices. I see this playing out with a subset of functionality on a subset of devices being provided for free. This will be fantastic for indie developers and small companies that do not make enough money from their apps to spend $1000’s on testing. This free functionality is likely to be the use of basic app crawlers to provide unscripted pseudo-random testing. It will probably be more advanced than letting monkey loose on the app and most likely built from the Appurify robot app crawler functionality.

A much larger set of functionality from a much larger pool of devices is not a cheap service to provide and will come at a cost for developers. This will target the top 1% of apps and provide a method for supplementing the apps existing internal testing. The sort of extra functionality likely to be included would be features such as:

  • Support of automated testing frameworks such as Espresso and UIAutomator
  • Full control of device environment, such as network connection, signal strength, memory, language and location
  • Comprehensive network traffic, memory, CPU, battery and FPS performance profiling
  • Comprehensive device library

Devices I want to be included

Now I don’t ask much, but I want the physical devices to be a range of devices that covers the following:

  • Devices from each manufacturer
  • Flagship devices for each of the past several years
  • Each released CPU architecture
  • Each Android API, including preview APIs
  • Combinations of Feature Sets
  • Android One devices
  • Various physical screen size
  • Various screen densities
  • Various screen resolutions
  • Range of languages
  • Languages with RTL layouts
  • Android Wear devices
  • Android TV devices
  • Android Auto devices

When do we find out more?

More details and a test run of the service is still a month or two away. Stay tuned to the Cloud Test Lab site for updates.

Advertisements

Leave a comment

Filed under Android SDK, Cloud Test Lab, Testing

Help! My custom font does not work on Android 5.0

Issue description

On Android Lollipop versions before 5.1 some custom fonts loaded using the API Typeface.createFromAsset() do not render using the correct font. This issue was fixed with the release of Android 5.1, but will still affect your users running Android Lollipop 5.0.x.

This should not cause a crash in your app, it will just cause your view to render using the default typeface rather than the custom font you have specified.

What causes the issue?

The cause of this issue is badly formed TTF font files. Minor issues in font files may be ignored or tolerated by most systems rendering the font, however the tolerance level in the early builds of Lollipop was not so high and some fonts fail to render causing the system to fall back to using the default font. It is similar to having a badly written audio file that will play in some media apps but is flagged as corrupted in others.

Is my app affected?

The first thing to check is if your app loads custom fonts. Take a look for any font files found in your Android assets/fonts folder. Then look for the code that is loading the font so you can see where in the apps UI the custom font is used. Loading a custom font from your apps Assets folder and setting it into a View is quite straight forward.

Typeface tf = Typeface.createFromAsset(getAssets(), "fonts/myfont.ttf");
myView.setTypeface(tf);

Having custom fonts doesn’t always mean your app will be affected by this issue however. The quickest way to check is to visually verify those custom fonts are being rendered correctly. Another check suggested by the Android team is to run your font through the Sanitiser for OpenType engine. To determine a potential issue look for this in the output:

WARNING at ots-read-only/src/cmap.cc:160: bad id_range_offset

Solution

The root cause of the problem is badly written font files, so it makes sense that the solution is to re-encode the offending font.

If you only have a couple of font files you would like to re-encode a great place to start is with an online converting tool such as http://www.freefontconverter.com/. Upload your dodgy font file and even if you select the same input and output font format (ie. TTF), the file will still be re-encoded and should now be able to be used in your app. This web service has successfully fixed all the non conforming fonts I have thrown at it.

However if that online tool did not help, or you have a huge repository of files you would like to re-encode you may like to use https://github.com/behdad/fonttools/ to convert your TTF to XML and then back to a TTF.

Be careful running any software that will re-encode your font files. As this process will be changing the file there may be side effects such as loss of quality. Also it is possible the tool you are using to re-encode the file will also produce non-compliant font files that fail in some environments.

Why did my Unit tests not catch this error?

If you have had to fix this error then you may be thinking to yourself, Why did my unit test not alert me to this issue? or How can I write a unit test to stop this issue next time?

Don’t be too hard on yourself; for all intents and purposes the code appears to function correctly without visually verifying the rendering. The typeface is loaded correctly and it can be set into a view without issue or complaint. Even after the view has been invalidated and rendered there is still no exceptions or warnings of an issue raised. The problem only becomes obvious on visual inspection of the View.

References

Android issue tracker for this issue:

https://code.google.com/p/android-developer-preview/issues/detail?id=608

Android Typeface documentation:

http://developer.android.com/reference/android/graphics/Typeface.html

Leave a comment

Filed under Android 5.0, Android SDK, Testing

Pseudo-localization testing in Android

Developers localizing Android apps have to contend with the same considerations and issues as with software on any other platform. This article is not a step by step guide to the internationalization process, but simply touches on a couple of Android specific tips and tricks for developing a localized version of your app. Before proceeding you should be familiar with the Android Localization practices described in the official documentation. Localizing with Resources and Localization Checklist are the best place to start.

What is Pseudo-localization?

Pseudo-localization is a method to test the internationalization of text while maintaining readability. The purpose of this testing is to expose issues regarding length and flow of text, layout issues and logic issues.

If you are getting translations done externally it can be a time consuming and expensive process so localization testing should take place long before you get any kind of translator involved. By verifying everything is correct you will save time and iterations back and forth with translators.

Testing with Pseudo-localization on Android

You can test localization in your Android app by using a special developer locale that will lengthen string lengths and add accents to characters while still maintaining readability of the original strings. While documentation from Android regarding these new locales is basically non-existent at the moment, it appears you need to be running Android 5.0+ and have developer options enabled on the device to be able to access these special locales.

On your compatible Android device navigate to the device settings and select Language & Input > Language > English (XA)

locale_english_xa sample_locale_english_xa

After setting the language to English (XA) (above left image) text will start to appear in the pseudo-localization style (above right image). You will notice how the text is still legible in English, while being substantially longer than normal, in order to simulate more verbose languages.

As a broad generalization the Romance languages can be up to 30% longer than the equivalent English, while languages such as Chinese, Japanese and Hebrew languages may be significantly shorter.

Using your Android device after making this locale change you will note that most apps will not take on the same English (XA) appearance as is displayed in the example image. The reason for this is that pseudo locale support is designed simply for testing so must be explicitly enabled for each app individually in the build process. You can do this by setting pseudoLocalesEnabled to true in your gradle build script.

buildTypes {
    debug { 
        pseudoLocalesEnabled true 
    } 
}

Note: Support for pseudoLocalesEnabled was added to the Gradle plugin version 0.14.2.

Simplifying localization using XLIFF

XLIFF is a set of standards to aid in the translations of XML documents. You can use XLIFF to prevent text being translated and also to show formatted examples of string paramters. To use XLIFF in your Android string XML files you need to include the XLIFF 1.2 namespace:

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">

This example shows how you can use XLIFF to help translators by flagging text not to be translated:

<string name="website_url">
    Take a look at our website <xliff:g id="blog_address">https://androidbycode.wordpress.com</xliff:g>
</string>

This example shows how to use XLIFF to display example arguments when using String formatting. It allows translators to understand what the data that will be injected into the string will look like.

<string name="city_longitude">
    Longitude: <xliff:g id="lon" example="37.8° S>%1$s</xliff:g>
</string>

Note: Support for XLIFF is available in Android Studio 0.3 and later

Supporting Right to Left layouts

Native Android support for right to left layouts (RTL) was introduced in API 17 (Android Jelly Bean 4.2). The Android Framework Team covered the introduction of this support in some detail.

Layout Mirroring is a term used to describe the ability of software to reorder the UI elements to match the right to left flow for that locale. It is possible to achieve a mirrored layout by manually creating a layout for RTL locales, but with API 17 automatic layout mirroring was introduced. If you want your app to use layout mirroring then you need to flag this support in the <application> element in your manifest file.

 android:supportsRtl="true"

For some time Android Lint has been generating warnings in layouts to replace or duplicate left/right layout properties to new start/end equivalent properties for RTL support. For example if your layout contains layout alignments for left or right, such as:

 android:layout_alignParentRight="true"

You should also add the equivalent End element to support RTL:

 android:layout_alignParentEnd="true"

The latest versions of the Android Studio layout editor will add these in automatically when you create the items. If you are hand coding the XML or created the layout in an alternative IDE you may have to add them manually.

Mirroring drawables on RTL layouts

Drawables often need to be reversed on locales that use RTL layouts. An example of this is the Notification bar at the top of your Android device. On a RTL layout the icons, ie. signal strength, will be reversed. There are a couple of ways to achieve this.

For API 19+ you can set the the AutoMirrored Flag to indicate if a drawable should automatically be reversed when a RTL locale is selected.

For API 17+ you can specify different drawables in the same manner as you might for different densities using the qualifier “-ldrtl” or “-ldltr”. For example your resource folders may look like this:

res/
    drawable-ldrtl-xhdpi
    drawable-ldltr-xhdpi

Testing with Pseudo-localization on RTL layouts

Earlier in this article I explained how to set your device to language English (XA). There is also another locale (XB) in the languages list which allows testing of pseudo-localization using a mirrored RTL layout.

locale_xb sample_locale_xb

In the images above the Android signal strength icon is AutoMirrored once the RTL layout locale is invoked. Take some time to consider which icons should be mirrored in your app. Also note how layout mirroring has been invoked with the ActionBar to move the search and navigation views.

Summary

Translating large products is a time consuming and expensive exercise that will require at least a few iterations between developer and technical writer. By ensuring your product is fully prepared for localization prior to starting the text translations you will keep the number of iterations and costs of the process down. Add pseudo-localization, visually inspect all layouts and run your full test process to ensure your product not only functions, but looks good in anyone’s language!

2 Comments

Filed under Android SDK, Testing

Android Studio 1.1: Unit Testing on the local JVM

The Android Studio 1.1 update is still filtering onto developers machines. One important improvement is the addition of support for unit testing using the local JVM on your development machine. This feature is still experimental and must be enabled in the IDE settings.  You can read all about it on the official site:

http://tools.android.com/tech-docs/unit-testing-support

This new feature means the most popular open source Android Studio plugin for gradle unit tests will now no longer be developed or maintained:

https://github.com/evant/android-studio-unit-test-plugin

Leave a comment

Filed under Android Studio, Testing