The patents attack Android

Android is on fire. More than 550,000 Android devices are activated every day, through a network of 39 manufacturers and 231 carriers. Android and other platforms are competing hard against each other, and that’s yielding cool new devices and amazing mobile apps for consumers.

But Android’s success has yielded something else: a hostile, organized campaign against Android by Microsoft, Oracle, Apple and other companies, waged through bogus patents.

They’re doing this by banding together to acquire Novell’s old patents (the “CPTN” group including Microsoft and Apple) and Nortel’s old patents (the “Rockstar” group including Microsoft and Apple), to make sure Google didn’t get them; seeking $15 licensing fees for every Android device; attempting to make it more expensive for phone manufacturers to license Android (which we provide free of charge) than Windows Phone 7; and even suing Barnes & Noble, HTC, Motorola, and Samsung. Patents were meant to encourage innovation, but lately they are being used as a weapon to stop it.

A smartphone might involve as many as 250,000 (largely questionable) patent claims, and our competitors want to impose a “tax” for these dubious patents that makes Android devices more expensive for consumers. They want to make it harder for manufacturers to sell Android devices. Instead of competing by building new features or devices, they are fighting through litigation.

This anti-competitive strategy is also escalating the cost of patents way beyond what they’re really worth. The winning $4.5 billion for Nortel’s patent portfolio was nearly five times larger than the pre-auction estimate of $1 billion. Fortunately, the law frowns on the accumulation of dubious patents for anti-competitive means — which means these deals are likely to draw regulatory scrutiny, and this patent bubble will pop.

We’re not naive; technology is a tough and ever-changing industry and we work very hard to stay focused on our own business and make better products. But in this instance we thought it was important to speak out and make it clear that we’re determined to preserve Android as a competitive choice for consumers, by stopping those who are trying to strangle it.

We’re looking intensely at a number of ways to do that. We’re encouraged that the Department of Justice forced the group I mentioned earlier to license the former Novell patents on fair terms, and that it’s looking into whether Microsoft and Apple acquired the Nortel patents for anti-competitive means. We’re also looking at other ways to reduce the anti-competitive threats against Android by strengthening our own patent portfolio. Unless we act, consumers could face rising costs for Android devices — and fewer choices for their next phone.

UPDATE August 4, 2011 – 12:25pm PT

It’s not surprising that Microsoft would want to divert attention by pushing a false “gotcha!” while failing to address the substance of the issues we raised. If you think about it, it’s obvious why we turned down Microsoft’s offer. Microsoft’s objective has been to keep from Google and Android device-makers any patents that might be used to defend against their attacks. A joint acquisition of the Novell patents that gave all parties a license would have eliminated any protection these patents could offer to Android against attacks from Microsoft and its bidding partners. Making sure that we would be unable to assert these patents to defend Android — and having us pay for the privilege — must have seemed like an ingenious strategy to them. We didn’t fall for it.

Ultimately, the U.S. Department of Justice intervened, forcing Microsoft to sell the patents it bought and demanding that the winning group (Microsoft, Oracle, Apple, EMC) give a license to the open-source community, changes the DoJ said were “necessary to protect competition and innovation in the open source software community.” This only reaffirms our point: Our competitors are waging a patent war on Android and working together to keep us from getting patents that would help balance the scales.

Deleting Blank Tiles


Creating raster tilesets almost invariably leads to the creation of some blank tiles – covering those areas of space where no features were present in the underlying dataset. Depending on the image format you use for your tiles, and the method you used to create them, those “blank” tiles may be pure white, or some other solid colour, or they may have an alpha channel set to be fully transparent.

Here’s an example of a directory of tiles I just created. In this particular z/x directory, more than half the tiles are blank. Windows explorer shows them as black but that’s because it doesn’t process the alpha channel correctly. They are actually all 256px x 256px PNG images, filled with ARGB (0, 0, 0, 0):


What to do with these tiles? Well, there’s two schools of thought:

  • The first is that they should be retained. They are, after all, valid image files that can be retrieved and overlaid on the map. Although they aren’t visually perceptible, the very presence of the file demonstrates that the dataset was tested at this location, and confirms that no features exist there. This provides important metadata about the dataset in itself, and confirms the tile generation process was complete. The blank images themselves are generally small, and so storage is not generally an issue.
  • The opposing school of thought is that they should be deleted. It makes no sense to keep multiple copies of exactly the same, blank tile. If a request is received for a tile that is not present in the dataset, the assumption can be made that it contains no data, and a single, generic blank tile can be returned in all such instances – there is no benefit of returning the specific blank tile associated with that tile request. This not only reduces disk space on the tile server itself, but the client needs only cache a single blank tile that can be re-used in all cases where no data is present.

I can see arguments in favour of both sides. But, for my current project, disk and cache space is at a premium, so I decided I wanted to delete any blank tiles from my dataset. To determine which files were blank, I initially thought of testing the filesize of the image. However, even though I knew that every tile was of a fixed dimension (256px x 256px), an empty tile can still vary in filesize according to the compression algorithm used. Then I thought I could loop through each pixel in the image and use GetPixel() to retrieve the data to see whether the entire image was the same colour, but it turns out that GetPixel() is slooooowwwww….

The best solution I’ve found is to use an unsafe method, BitMap.LockBits to provide direct access to the pixel byte data of the image, and then read and compare the byte values directly. In my case, my image tiles are 32bit PNG files, which use 4 bytes per pixel (BGRA), and my “blank” tiles are completely transparent (Alpha channel = 0). Therefore, in my case I used the following function, which returns true if all the pixels in the image are completely transparent, or false otherwise:

public static Boolean IsEmpty(string imageFileName)
  using (Bitmap b = ReadFileAsImage(imageFileName))
    System.Drawing.Imaging.BitmapData bmData = b.LockBits(new Rectangle(0, 0, b.Width, b.Height), System.Drawing.Imaging.ImageLockMode.ReadOnly, b.PixelFormat);
      int PixelSize = 4; // Assume 4Bytes per pixel ARGB
      for (int y = 0; y < b.Height; y++)
        byte* p = (byte*)bmData.Scan0 + (y * bmData.Stride);
        for (int x = 0; x < b.Width; x++)         {           byte blue = p[x * PixelSize]; // Blue value. Just in case needed later           byte green = p[x * PixelSize + 1]; // Green. Ditto           byte red = p[x * PixelSize + 2]; // Red. Ditto           byte alpha = p[x * PixelSize + 3];           if (alpha > 0) return false;

  return true;


It needs to be compiled with the /unsafe option (well, it did say in the title that this post was dangerous!). Then, I just walked through the directory structure of my tile images, passing each file into this function and deleting those where IsEmpty() returned true.


Bing Maps Control for Windows Phone 7 lagging

This is a video showing the Silverlight Bing Maps Control for Windows Phone 7 showing some serious lagging behaviour on my HTC 7 Trophy. As you can see the built-in Windows Phone maps app performs normally (note that it’s a native thing and doesn’t use the Bing Maps Control), but the two user apps, Map Mania and Slim Tanken, both show some serious lagging while pinching/zooming