Scaled images, the Android fragmentation and a solution

Update 1
It seems like this fix doesn’t work on every device out there. Some users had scaling issues after I published this change. So I made this change optional.
Update 2
The issue seems to be not a scaling problem but a image quality problem. I have changed the source code to produce much better results

While developing an app that needs to interact with the operating system, like Minimalistic Text, every Android developer will get to a point where the Android fragmentation hits him. Sometimes a little bit and sometimes hard 🙂
Minimalistic Text has such a „problem“ since the beginning and today I want to explain what the problem is and what I did to resolve this annoying issue.

Widgets in Android

Widgets in Android get updated through packages that are sent from the application. The application can’t control directly what the widget does but it can throw settings into such a package and send it to the widget. The Launcher app then receives this package and applies it to the widget.
Due to the things Minimalistic Text can do (shadows for example) the options that such a package offers aren’t enough to bring all the settings that a user has set up to the widget.
So Minimalistic Text uses the „Bitmap approach“. The content of the widget gets rendered into a bitmap and then the bitmap gets passed to the widget (through the package). The widget itself is only an ImageView.
This approach works really well. At least on most devices. And at least for certain widget sizes… The story begins.

The problem

From the launch of Minimalistic Text until today there are complaints from users that told me that their widget stops updating. After some investigation I have found out that the package size that the app can send to the widget is limited. I think 1 MB is the maximum. If the app sends a package bigger than that limit the update will fail. The really bad thing is that the app doesn’t notice this. So the update silently fails and Minimalistic Text doesn’t know of any problem.
I worked around this issue by reducing the available widget sizes. If you want to get this problem then simply create a 4×2 Minimalistic Text widget and fill it with data so that the image that has to be sent to the widget gets as big as possible.
The only way to avoid sending such a big image through a package is to save the image as a file and only send an URI to the widget where to find it. Sounds great, doesn’t it?
I have tested this approach on my HTC device and it worked great. So I decided to publish my new bugfix into the wild and shortly after that a e-mail flood has arrived my googlemail account. Many users complained about widgets that are scaled down.
After rolling this bugfix back and googleing around a bit I found out that there is a bug in Android. If the Bitmap isn’t applied directly to a ImageView but through an URI (that gets fed by a ContentProvider) the image gets scaled down by the density of the screen.

Fragmentation everywhere

And here comes the fragmentation into play.
If this bug would be on all devices – not cool but no problem. Minimalistic Text could simply scale the image up so that the bug scales it down again and everything is fine. Well would be is the right term 😉
It seems like some vendors have fixed this bug (for some of their devices). I have a HTC Sensation that doesn’t scale anything. My Galaxy Nexus and the Nexus S do. So thanks to the fragmentation I have no clear way without a bug or with a workaround for this bug.
Pissed off by the fact that my fix doesn’t work on all devices I took this problem as beeing present and limiting the amount of widget sizes that Minimalistic Text can handle.

And it gets worse

As the screen resolutions get bigger and bigger the 1 MB limit comes nearer and nearer. The last days some people had the „widget doesn’t update any more“ issue on 4×1 widgets.
So I had to find any way to avoid this issue.

The solution

After telling this a colleague of mine and complaining about the „bad bad“ Android fragmentation and how developing for Android is like creating big if cascades to check what device is currently executing the app to activate special workarounds or hacks he asked me if it was possible to get the bytes that are displayed on the widget to check if they were scaled or not.
After coming home and bringing the kids to bed I tried to use my own ContentProvider and then checked if the image that the ImageView got from the ContentProvider has been scaled. And yes, it did. So now I have found a way to measure this bug and scale the images for the widgets the same way up as they get scaled down by the ImageView.

Dead simple.

To give you an idea of how to achieve this I will post some source code here. So if you aren’t a developer this place can be a good one to stop reading this post 😉

Some code

The first step is to make your ContentProvider „Sample“-aware. Use some kind of special data to signal the ContentProvider that you need a specified sample image.
I have added the following functions to the Minimalistic Text ContentProvider (the source code is not functional as it is only part of a bigger source file):

public static final Uri CONTENT_URI = Uri.parse("content://"
        + PROVIDER_NAME + "/widgets");

private static String getSampleFileName() {
    return "MT_Sample.png";

public static int getSampleRectangleSize()
    return 100;

public static Uri ensureSampleBitmap(Context context) throws IOException {
    Uri result = Uri.parse(CONTENT_URI.toString() + "/-1/"
            + Long.toString(Calendar.getInstance().getTimeInMillis()));

    File file = new File(context.getFilesDir(), getSampleFileName());
    if (file.exists())
        return result;
    FileOutputStream fOut = context.openFileOutput(getSampleFileName(),
    Bitmap sampleBitmap = Bitmap
            .createBitmap(1, 1, Bitmap.Config.ARGB_8888);
    sampleBitmap.setPixel(0, 0, Color.WHITE);
    Bitmap scaledBitmap = Bitmap.createScaledBitmap(sampleBitmap, 
                                    getSampleRectangleSize(), false);
    scaledBitmap.compress(CompressFormat.PNG, 100, fOut);


    return result;

This methods allow us to create a sample image that has a dimension of 100×100 and get an URI to retrieve the image.
The code for the openFile method of the ContentProvider looks like this:

public ParcelFileDescriptor openFile(Uri uri, String mode)
        throws FileNotFoundException {

    try {
        int widgetId = Integer.parseInt(uri.getPathSegments().get(1));

        File file = null;

        //thie widgetId -1 signals "Sample data"
        if (widgetId == -1) {
            file = new File(getContext().getFilesDir(), 
        } else {
            file = new File(getContext().getFilesDir(),

    } catch (Exception e) {
        return null;

Now the app can measure the amount of wrong scaling by instantiating an ImageView and let the ImageView fetch the sample image:

private float calculateImageContentProviderScale()
    try {
        ImageView imgView = new ImageView(this);
        imgView.measure(MeasureSpec.UNSPECIFIED, MeasureSpec.UNSPECIFIED);
        return (float)WidgetImageContentProvider.getSampleRectangleSize() 
                / (float)imgView.getMeasuredHeight();
    } catch (IOException e) {
        Log.e(TAG, "Error determining the image scale factor", e);
    return 1;

This factor can be stored as a static variable because this value won’t change during the app lifetime.
Everytime a widget gets updated Minimalistic Text now uses this factor to scale the image up.


public static Uri updateWidget(Context context, Bitmap widgetContent,
        int widgetId, boolean useSalt, float scaleFactor)
        throws IOException {
    String fName = getFileName(widgetId);
    FileOutputStream fOut = context.openFileOutput(fName,
    Log.d(TAG, "Using a scale factor of " + Float.toString(scaleFactor));
    if(scaleFactor > 1)
        float scaledHeight = widgetContent.getHeight() * scaleFactor;
        float scaledWidth = widgetContent.getWidth() * scaleFactor;

        Bitmap scaledWidgetContent = Bitmap.createScaledBitmap(
        scaledWidgetContent.compress(CompressFormat.PNG, 100, fOut);
        widgetContent.compress(CompressFormat.PNG, 100, fOut);

    return Uri.parse(CONTENT_URI.toString()
            + "/"
            + Integer.toString(widgetId)
            + "/"
            + (useSalt ? Long.toString(Calendar.getInstance()
                    .getTimeInMillis()) : ""));


Bitmap textBitmap = createTextBitmap(context, settings,
        demoMode, ss.hasBeenPortrait(), events);

Uri imgUri = WidgetImageContentProvider.updateWidget(
remoteView.setImageViewUri(, imgUri);

I hope this helps any poor developer out there that has been stuck on the same problem as I have been until today!
If you have any further questions, simply write me an email.


Android und die Fragmentierung

Es gibt immer wieder Momente an denen wird mir sonnenklar warum Android in der jetzigen Form mehr auf Power User ausgelegt ist.

Ich habe meinen Androiden (Samsung Galaxy S I9000) jetzt seit ca. einem Monat und arbeite mich Tag für Tag tiefer in die Materie „Android“ ein.
Anfang des Monats stand für das Galaxy S ein Update auf FroYo (Android 2.2) an. Zu Glück noch bevor bevor die Version 2.3 (Gingerbread) erschienen ist 🙂 Dadurch habe ich die Update Thematik hautnah miterlebt.

Android ist kein Eigentum von Google, sondern offiziell eine Art Zusammenarbeit verschiedener Hersteller. Der Quellcode ist offen und kann von jedermann eingesehen werden. Die einzelnen Hersteller nehmen diesen Source Code als Basis und stricken eine mehr oder weniger dicke, eigene Schicht darüber (z.B. Hardwaretreiber, spezielle Apps, …). Dann sind da noch die Netzbetreiber die das Android vom Hersteller bekommen und wiederum ihre Besonderheiten einbauen (Werbe-Apps, Theme, Mobilfunkeinstellungen, …).

Man sieht schon: Der Weg ist lang. Aber da hört das Problem noch nicht auf. Die Hersteller arbeiten (verständlicher Weise) gewinnorientiert. Wenn jetzt so ein Handy in die Jahre (oder Monate, wie bei Motorola) kommt, dann wird irgendwann der Support eingestellt. Da nützt es herzlich wenig dass von Google vorangetrieben eine neue Version von Android bereit steht. Wenn der Hersteller keine Treiber dafür anpasst, dann gibt es eben kein Update.
Das Problem heutzutage ist, dass die Systeme (auch auf den Smartphones) viel zu komplex sind als dass sie mit sehr wenigen oder sogar gar keinen Updates auskommen würden. Jeder der auf seinem Rechner Windows, Linux oder MacOS installiert hat, der wird sicher feststellen dass da das ein oder andere Mal Updates zur Verfügung stehen. Diese Updates machen die Betriebssystemhersteller nicht zum Spaß, sondern meistens um Fehler oder gar Sicherheitslücken auszumerzen.
Was macht nun also so ein Motorola Android Besitzer, für den Motorola keine Updates mehr bereit stellt? Dia Apps kann er noch aktualisieren, aber alles was zum Betriebssystem gehört bleibt (normalerweise) so, wie es ist.
Stellt sich also heraus, dass der Android Browser eine Sicherheitslücke hat, dann wird diese Lücke bleiben. Für immer.

An dieser Stelle bleibt dem Android-Besitzer, dessen Support eingestellt wurde, nur der Gang zu diversen einschlägigen Seiten (die bekannteste davon ist wohl in der Hoffnung, dass dort ein paar schlaue Entwickler sitzen die genau das gleiche Handy haben (oder eine Herausforderung brauchen) und das neue Android für das Gerät anpassen.

Erkläre das mal deinem Opa (Ausnahmen bestätigen natürlich die Regel 😉 ).

Derzeit kann man also nur sagen: Android – ja, ohne Zweifel, wenn du ein Power User bist oder werden willst und – nein, auf keinen Fall, wenn du einfach nur ein Handy brauchst, mit dem du telefonieren und ab und an mal E-Mails checken willst.