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.


A little change

Hi everybody,

I will change the way this blog works a bit. I want to blog more into the „software development“ / „Android“ direction than about my personal day to day drivers. Also I have the plan to rise the update frequency of this blog and the language changed to English so that users outside Germany can read what I write 🙂

So let’s start off with a little Android exercise. Recently I implemented a new language selector for Minimalistic Text. The old one just used the ListPreference in the Android Settings. My main goal has been to add little flags to each language to make this dialog a little more colored.

A short research on the internet showed me that there is no way to get images into a ListPreference. So I had to implement my own Preference that is capable of a list with images.
My first thought was to derive from ListPreference and add the image functionality. But due to the (lack of) design in the ListPreference there is no way to derive a subclass that implements another visual part. The main reason for this is the fact that the ListPreference stores the selected element index into an internal variable (private) that then gets read by the dialog closed event. So a subclass would have to set the index based on its own view to use the ListPreference functionality like propagating the settings change to all listeners.

So the last possibility has been to copy the ListPreference code to my own class and make images in the list possible.

The solution constists of 6 files:

  • imagelistpreferencelayout.xml
  • empty_content.xml
  • orange_content.xml
  • clickbackground.xml
The ImageListPreference is a copy of the ListPreference and adds an array of resource ids for the images. It sets its own ListAdapter to the Dialog (an instance of ImagePreferenceArrayAdapter). The Adapter then creates the views for the items based on the imagelistpreferencelayout and handles the click events (that set the currently selected index). The 3 drawable xml files are needed to give a visual feedback for tapping on an item (the background gets changed from empty to orange based on the selector in clickbackground.xml.)
You can download the sources for the ImageListPreference here:
That’s how the new language selector looks like:
Sample of the new Minimalistic Text language selector

Language Selector

If you have any questions or feedback for the ImageListPreference then write me an email.

Aktueller Stand / Wiki

Derzeit komme ich nicht sehr oft dazu an Minimalistic Text weiterzuarbeiten.
Der neue Layout Editor befindet sich nach wie vor in einem frĂŒhen Entwicklungsstadium und die Liste der Todo’s wird immer lĂ€nger. So wird mir auf lange Sicht sicherlich nicht langweilig 😉

Ich habe fĂŒr Minimalistic Text ein Wiki eingerichtet. Die Idee ist dass User dort ihre Tipps / Anleitungen / Einstellungen verewigen und mit der Community teilen können. Ich bin gespannt, ob das Wiki Anklang findet.

Das Minimalistic Text Wiki ist unter erreichbar.


Ein neuer Blog

Hallo zusammen,

in diesem Blog wird es um meine Erfahrungen / Meinungen rund um das Thema Softwareentwicklung und im speziellen um Programmierung auf mobilen EndgerÀten gehen.
Der Blog hat kein streng abgegrenztes Thema wie „.NET Entwicklung“ oder „Android Entwicklung“ sondern beschĂ€ftigt sich mit den Themen, mit denen ich mich gerade beschĂ€ftige. Und das kann je nach Lust, Laune und Gegebenheit auch mal wechseln.

Erst neulich ist so eine Kehrtwende passiert.
Die letzten Jahre hat sich sowohl in der Arbeit als auch privat alles, was programmieren anbelangt, um .NET und C# gedreht. Auch die Auswahl meiner Handys war ohne Debatte auf Windows Mobile festgelegt, da ich dafĂŒr mit .NET relativ einfach programme schreiben konnte.
Vor ein paar Monaten hat sich in mir eine Neugierde nach etwas anderem entwickelt, die immer ausgeprĂ€gter wurde. Diese Neugierde zusammen mit einem anstehenden Jobwechsel und zu guter letzt die Details, die ĂŒber Windows Phone 7 bekannt geworden sind, haben mich dazu gebracht meinen Blick von .NET und C# zu lösen und mein mobiles GerĂ€t unabhĂ€ngig der benötigten Programmiersprache, sondern abhĂ€ngig von dem Mehrwert / Nutzen den es mir bringt und den Möglichkeiten die ich damit habe, auszuwĂ€hlen.
Am Ende ist es dann ein Android Handy geworden. Genauer: Ein Samsung Galaxy S I9000
Meine Entscheidung hat ihre Ursachen sowohl aus der Sicht eines Entwicklers als auch als der Sicht eines Power Users:


  • FĂŒr Android muss der Entwickler kein Geld bezahlen, um ein selbstgeschriebenes Programm auf sein GerĂ€t zu bringen. Kein Witz! Kein Geld! 😉 Hintergrund dieser Aussage: Apple und Microsoft verlangen von Entwicklern, die doch tatsĂ€chlich ihr Programm auf dem Handy ausfĂŒhren wollen, dass sie registrierte Entwickler werden. Das kostet dann so 100$ / Jahr. FĂŒr Google muss man erst bezahlen (und auch nur moderate 25€, einmalig) wenn man seine Anwendung im Google Market anbieten will.
  • Anwendungen haben in Android mehr Möglichkeiten. Ein Programm kann ohne groß Aufwand zu betreiben, einen Hintergrunddienst starten um z.B. irgendetwas zu aktualisieren, GPS zu tracken, … Sowas geht (zumindest so einfach) bei Microsoft und Apple nicht. Kann auch Vorteile haben, dazu spĂ€ter mehr in der Nutzersicht.


  • klar ist es ein Vorteil, wenn die Plattform an sich schon eine sehr große Sicherheit bietet um sicherzustellen dass sich Anwendungen korrekt verhalten und nicht unnötig Akku verschwenden oder private Daten ins Internet senden. Die interessante Frage an dieser Stelle ist der Preis dafĂŒr.
    Die Gefahr, dass sich Anwendungen „nicht korrekt“ verhalten sehe ich auf Android schon etwas höher, da keine Instanz die Anwendung prĂŒft. Auf der anderen Seite gibt es auch keine Instanz die Anwendungen auf Grund irgendwelcher firmenpolitischer Entscheidungen verhindert / aufhĂ€lt (Flash + iPhone z.B.).
  • Falls mal irgendwo ein Fehler enthalten ist (was ja in der Softwareentwicklung ab und an mal vorkommen soll) ist man mit Android „freier“ im Sinne von „dann suche ich mir halt eine andere App, die den gleichen Job erledigt“. Dabei ist Android nicht auf die oberflĂ€chlichen Apps beschrĂ€nkt, sondern dann wird halt schon mal der Home Screen oder die Gallerie getauscht. Erfordert mehr Auseinandersetzung mit dem GerĂ€t, eröffnet aber auch deutlich mehr Möglichkeiten (aber: auch was falsch zu machen)

Im Endeffekt wird jeder fĂŒr sich selbst entscheiden mĂŒssen, auf welche Aspekte er/sie mehr Wert legt. Ich fĂŒr meinen Teil kann nur sagen, dass ich mich fĂŒr Android entschieden habe.

Was ich eigentlich damit ausdrĂŒcken wollte: Dieser Blog kann innerhalb von Monaten eine Kehrtwende machen und sich in eine andere Richtung bewegen. Wie mein „Brain“ halt auch.