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.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.


  1. Artem sagt:

    Thanks a lot for your post!
    Run into the same exactly issue and solved the first part using remoteView.setImageViewUri() method but then faced the second trap with scaling. Your idea helped! Thanks again!

    P.S. Maybe someone found out a shorter solution for this issue?

  2. Sergio Viudes sagt:

    Smart solution for a very annoying problem in Android 🙂

    Thanks for sharing