The second application is a game by Konami called X-Men. This game was originally released in the arcades in 1992. The game is a lot of fun but don’t expect to be able to easily finish it without abusing the continue system.

Google I/O was also the occasion for me to give two presentations about Android with my friend and colleague Chet Haase: Honeycomb Highlights and Android Accelerated Rendering. I am happy to announce that the slides for both these sessions are now available.

Our first session, Honeycomb Highlights, is an overview of the new features for users and developers you can find in Android 3.0:

• Watch the video on YouTube
• Watch the slides online
• Download the slides (PDF)
• Download the slides (Apple Keynote)

Our second session, Android Accelerated Rendering, explains how to use the new OpenGL 2D rendering pipeline in your applications:

• Watch the video on YouTube
• Watch the slides online
• Download the slides (PDF)
• Download the slides (PDF, with speaker notes)
• Download the slides (Apple Keynote)

You can also download the source code of our animations demo from Google Code. This demo also shows how to properly use hardware acceleration and hardware layers.

Enjoy!

I published last week a video of a simple Android 3.0 animation demo and I promised I would publish the source code as soon as possible. I am happy to tell you that it is now available on Google Code.

The application is pretty simple and shows how to use some of the new Android 3.0 APIs, including:

• Object animators
• Animations reversal
• New view properties
• Hardware layers

This app also serves as a good example of how to use:

• Custom views
• Custom layouts
• Bitmap drawing

Check it out!

Watch in full 720p. This is a very simple demo that shows how to use some of the new Android 3.0 APIs.

Early Android devices had limited memory and computing power and to optimize the system we chose to draw opaque applications, by default, on 16 bits surfaces. The encoding format we use for 16 bits opaque pixels is called RGB_565: red and blue components have 5 bits of precision, and green has 6 bits of precision. This work relatively well but can lead to severe visual artifacts when drawing with bitmaps encoded in other formats. The two other formats supported by Android are ARGB_8888 and ARGB_4444. Both formats allow the encoding of an alpha channel for translucency and only differ in the precision of the components. ARGB_8888 requires twice the amount of memory, as each pixel is encoded with 32 bits, but provides the best quality. It is also the format we use automatically when loading bitmaps with an alpha channel (PNG resources for instance.) You should ignore ARGB_4444, unless you really know what you are doing, because it looks awful.

What does it all mean for your application? To make it easier to understand, I wrote a simple application you can run on your device, or on the emulator, to compare the quality and performance of various source and destination formats. The application contains two activities, one running in 16 bits, and one running in 32 bits. When launched, each activity lets you switch between bitmaps loaded in the 3 formats I described earlier. You can also enable dithering and profiling.

Let’s start by comparing the three bitmap formats as they appear when drawn on a 16 bits window (click on the image for a full-size version that will make the differences more obvious):

To better compare the three formats, take a close look at the gray gradient on the left side of each screenshot:

You can see three types of artifacts in this image: banding, low precision and dithering. The three bitmaps are loaded from the same resource and converted at load time using BitmapFactory.Options.inPreferredConfig. The first bitmap, ARGB_8888, shows weird bands of colors, particularly visible in the gray gradient. You can also see that the bands have a slight green shift. This artifact appears when the 8 bits of precision are clamped to 5 or 6 bits of precision. ARGB_4444 exhibits a similar behavior because of the upscale from 4 bits of precision to 5 or 6 bits. You can also notice a dithering pattern. Finally, the RGB_565 shows a clear dithering pattern.

These atrocities are unfortunately the default behavior on Android before 2.3. Fortunately, In most situations the user will not notice these artifacts. These artifact show mostly on subtle gradients or very specific types of images. There are also ways to hide these artifacts. For instance, opaque images that will be loaded in RGB_565 can be pre-dithered in a tool like Adobe Photoshop, with more powerful and higher quality filters than the one used by Android. I would however not recommend this approach because it forces you to bake noise in your image, making it harder to reuse in the future. Another solution is apply dithering on 32 bits images. The following screenshot shows an ARGB_8888 bitmap drawn on a 16 bits window with dithering enabled:

The terrible banding artifact we saw earlier is now gone! The only difference is enabling the dither flag on the paint (it also works on drawables.) Of course, because of its very nature, dithering is not perfect. A much better solution is simply to render 32 bits bitmaps on 32 bits surfaces, which Android 2.3 now does by default. The following screenshot shows the result of this new behavior:

The following image shows the difference between the previous approach, a dithered 32 bits bitmap drawn onto a 16 bits surface, and the new approach, a 32 bits bitmap drawn onto a 32 bits surface:

This image clearly shows that dithering introduces a very special type of noise used to trick your eye into seeing a smooth gradient. However, the 32 bits surface shows no artifact whatsoever and clearly provides the best quality. This is why we changed the behavior of Android 2.3 to loads bitmaps and windows in 32 bits by default.

You should also remember that choosing the appropriate bitmap format can lead to better runtime performance. For instance, drawing a 32 bits bitmap onto a 16 bits surface requires a specific conversion that costs CPU time. The following table compares the time taken to draw bitmaps in different formats, with or without dithering, on both 16 and 32 bits windows:

This simple performance test shows very clearly that using a compatible format (32 bits bitmap on a 32 bits window or 16 bits/565 bitmap on a 16 bits window) is the most efficient way to draw bitmaps. For this reason, you should always check the format of your bitmaps and windows and try to make them compatible with each other. You can choose a bitmap’s format when creating an empty bitmap or when decoding a resource or stream. You can of course check the format of an existing bitmap using Bitmap.getConfig(). You can choose and query the format of the window by using getWindow().getAttributes().format from your onCreate() method. You can also refer to this article’s example source code to see how to choose a particular format.

I would like to add a few things regarding this slide:

• Applications can use 32 bits windows today (transparent windows are 32 bits for instance.)
• Applications can force bitmaps to be loaded in 32 bits today.
• Applications can prevent banding today (more about this in my next post.)
• OpenGL windows remain 16 bits in Gingerbread for compatibility reasons. Some games assume this format and should not. But they do, and we don’t like breaking applications.
• OpenGL applications can use 32 bits windows today.

To sum up, Gingerbread does not add 32 bits support to the system, it’s always been there. Gingerbread simply enables 32 bits by default in more situations than before.

• Android Graphics and Animations
• Android UI Development: Tips and Tricks

These two presentations will teach you about development techniques we use every day on the Android team. The second one in particular shows what tools we use to track down performance issues. The videos of these two presentations are available on Parleys for registered users and will be available for free later next year.

Retro Camera by Urbian follows a recent trend in photography. Modern cameras, including entry-level point and shoot cameras, produce gorgeous and near perfect photos. Unfortunately, these pictures are often boring. That’s why more and more photographers use processing techniques to make their photos appear as if they had been taken with crappy cameras, often referred to as “toy cameras.” Retro Camera lets you take crappy yet artsy/interesting photos right away and saves you time in Photoshop, Lightroom, Aperture… The application sports a very realistic user interface centered around film photography. When you launch it, you almost feel like you are actually using a camera, and not a cell phone:

The tiny viewfinder is an especially nice touch and I appreciate the level at the bottom of the screen in the commercial version (replaced by ads in the free version.) Retro Camera is very easy to use, mostly because you do not have to fiddle with settings, knobs and sliders. Instead, the application offers you four virtual cameras, each with its own look and unique results. Of course, choosing a camera is as enjoyable as using them (don’t miss the very useful information panel of each camera):

When you take a picture, it is sent to the dark room for processing and finally saved on your SD card. You can browse the photos using Android’s built-in Gallery application or simply do it from the application itself. The visuals are once again pleasing but the application will only show you photos taken with Retro Camera but you can share them in just one click to post them on Twitter, Facebook, send them by email, etc.

Retro Camera is a fun application that I like to use to take candid snapshots and give them a quirky look. It does not replace other camera applications but acts as a nice companion. I wish processing pictures was faster but overall Retro Camera is worth its price, especially if you enjoy visually rich and polished applications. Finally here is a photo of a real camera taken with one of Retro Camera‘s virtual cameras:

To open this new series of articles, I would like to start by showing you my home screen. I use an unmodified version of “stock” Android running on a NexusOne (and I won’t tell you which version I am running.)

Among these various applications and games, the ones I use the most these days are Gmail, Talk and TweetDeck. Since I work at Google the first two are hardly surprising. I was using the official Twitter application until I saw so many people recommend TweetDeck yesterday. Aside from a few bugs and a couple of minor gripes I really like it so far.

Let’s imagine that your application needs to display a piece of text and a couple of buttons. The length of the text can vary and be longer or shorter than the screen. You want to put the text inside a scroll view and you want the buttons to scroll along with the text, probably to encourage the user to read the text before clicking any of the button. Depending on the length of the text, your application would look like one of the following screenshots:

In attempt to achieve this effect, I have seen several Android developers try to set the height of the view inside the scroll view to fill_parent. Doing so does not work and leads to the following result:

To understand this result, you must remember that android:layout_height=”fill_parent” means “set the height to the height of the parent.” This is obviously not what you want when using a ScrollView. After all, the ScrollView would become useless if its content was always as tall as itself. To work around this, you need to use the ScrollView attribute called android:fillViewport. When set to true, this attribute causes the scroll view’s child to expand to the height of the ScrollView if needed. When the child is taller than the ScrollView, the attribute has no effect.

The XML I wrote to create the correct version of this example can be found below. In line 32, I’ve set the android:layout_weight of the TextView to 1.0. By doing so I am forcing the text to use the available empty space when it is shorter than the ScrollView. This can only work when android:fillViewport=”true” is set on the scroll view.

<?xml version="1.0" encoding="utf-8"?>

<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/scroller"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:fillViewport="true" >
    <LinearLayout
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:orientation="vertical">
        <TextView
            android:layout_width="fill_parent"
            android:layout_height="wrap_content"
            android:paddingLeft="6dip"
            android:paddingRight="6dip"
            android:paddingTop="6dip"
            android:textAppearance="?android:attr/textAppearanceMedium"
            android:text="Welcome to My Application" />

        <View
            android:layout_width="fill_parent"
            android:layout_height="1dip"
            android:background="#ff106510"
            android:layout_marginLeft="6dip"
            android:layout_marginRight="6dip"
            android:layout_marginTop="6dip"
            android:layout_marginBottom="12dip" />

        <TextView
            android:layout_width="fill_parent"
            android:layout_height="wrap_content"
            android:layout_weight="1.0"

            android:paddingLeft="6dip"
            android:paddingRight="6dip"
            android:paddingBottom="6dip"

            android:text="@string/hello" />

        <LinearLayout
            android:layout_width="fill_parent"
            android:layout_height="wrap_content"

            android:background="@android:drawable/bottom_bar"
            android:gravity="center_vertical">
            <Button
                android:layout_width="0dip"
                android:layout_weight="1.0"
                android:layout_height="wrap_content" 

                android:text="Accept" />
            <Button
                android:layout_width="0dip"
                android:layout_weight="1.0"
                android:layout_height="wrap_content" 

                android:text="Refuse" />
        </LinearLayout>
    </LinearLayout>
</ScrollView>

Last but not least, I realized while writing this that the documentation of ScrollView does not mention the fillViewport XML attribute, even though it shows the equivalent Java API, setFillViewport(). This is a stupid mistake on my part that I will fix next week for a future release of Android. In the meantime, please accept my apologies :) just fixed.