Skip to main content

What Google's Relationship with Vendors Should be like in Regards to Android

I've been watching Android since it was first released, and got myself a Nexus One about half a year ago. The potential this platform has is very nice, and not just for smartphones. I would really like to see the tablets that will come with Android. But this isn't about me discussing Android itself. It's about the vendors who sell Android handsets and tablets, and their relationship with Google.

Android is great for its customizability. Unfortunately, vendors have taken this too far and made a perversion of the platform with forced apps, home screens, missing features, etc.

Forced Apps

If I don't use/want an app on my phone, I should be able to remove it at will, unless it is a system app (e.g. removing the Dialer app would be plain stupid). But carriers and manufacturers insist on putting apps on the users' phones that cannot be removed unless the user roots their phone (which will void the warranty). Why? If the app really is good, I will keep it, use it, and not delete it. If it's not, why have it waste space on my phone? Does it make any sense? Perhaps the app generates revenue by other means (e.g. music store). But if I'm not using it, it's not really generating any revenue, is it?

Google surprised me on this one by forcing the Amazon MP3 app on the Nexus One. Of course, it was no big deal because I rooted it when I got it. Nevertheless, I get all of my music on my computer, so I never have the need to use the app. Why not let me remove it? If Amazon pays Google to preload it, that's fine, but making it irremovable it not.

Custom Home Screen Apps

I toyed around with a Droid X my friend got, and hated their home screen app from the beginning. At first, I thought some of the features were interesting and perhaps even useful, but after a couple minutes, I felt they usually got in my way and made my experience unpleasant. Maybe it's because I'm used to ADW.Launcher, but that resembles the stock launcher a lot, and shouldn't all Android installs have the stock launcher at least available? And if you get ADW.Launcher on the Droid X, you still can't remove the default one, because then the phone would have no fall-back. And so it wastes space, again.

Missing Features

The big name that comes up here is tethering. To me, charging extra for tethering doesn't make any sense. It's simply an extra fee on top of the already-exorbitant prices for cell phone plans. It doesn't cost the carrier anything! Some people will say, "But people use the Internet more on their computers than on their cell phones." That's right. At the same time, does it really cost the company more if I tether my computer to my phone and download half a gig of data than if I download half a gig of data on my phone and then transfer it to my computer? I think not. It's just a cash cow. If carriers are worried about data usage, set transfer limits. It's that simple. If I'm paying for "unlimited" data, I should be getting unlimited data. Whether my phone forwards that right on my computer is none of the carrier's business. If that data isn't really unlimited (tethering fees), then it's just a marketing scam (though that shouldn't come as too much of a surprise).

What Google Should Do

So now we know the problem, but what's the solution? Well, the solution lies with the Android's maker, Google. Google has control over what vendors/carriers can and cannot do with Android. However, Android is open-source. So if Google imposes any restrictions, the vendor will simply use the source code and modify it to suit their needs.

There's one big level Google has over this. It has the power to license (or not) the Market app (and other closed-source apps). So it can basically enforce compliance with a policy if a vendor/carrier wants to include the Android Market on their device. If they get around that and distribute anyway, it will be unauthorized use, as in the case of Augen's GenTouch tablet, and Google could potentially sue (disclaimer: IANAL).

So there is a way for Google to enforce policies. The final part of this is what to enforce. Whether you agree or not (and please let me know), here is what I think Google should enforce:

  • Ship stock Android. No modifications to the core OS. Some will say this defeats the purpose of having Android be open source, but this isn't about open source. Vendors are free to modify just as before, they just can't ship it with the Android Market. My reasons for this are as follows: (1) stock Android will get updated when a new version of Android is released; (2) vendors can't do nasty things like turn off tethering; (3) this eliminates part of the problem with fragmentation.
  • No irremovable apps (except system apps). This one is a no-brainer. If the vendor/carrier wants to include their own home screen or their own or some nifty app or whatever else, that's all good. But if the user does not want it, they have the power to remove it. And Amazon MP3 does not count as a system app - the phone works just fine without it.
  • [optional] no root restrictions. This is optional because the average user doesn't care. And one of the reasons for rooting is to remove those irremovable apps. 
The only change to this would be corporate phones. These need the centralized access control, but not from the vendor of the phone. The control needs to be in the hands of corporations. Then, corporations could force  apps on their phones for security or productivity and still not be bound by vendor limitations. This is a valid concern because: (1) the phone is typically corporate property, not personal; (2) data-sensitive corporate operations may require extra functionality; (3) obviously, security reasons. 

As I was writing this, I noticed a parallel between this and Windows. Windows PCs always ship with stock Windows (though Windows being closed-source does help this point). Windows PCs often include crapware, but it is certainly not irremovable. Windows PCs always have admin access. Windows PCs allow for centralized corporate control. Certainly, if Windows came customized with irremovable crapware and an unavailable admin account, many Windows users would jump ship, right?

So, do you agree with this vision? Or disagree? Maybe a bit of both? Let me know in the comments!


Popular posts from this blog

Linux on XPS 15 9550/9560 with TB16 Dock [Update:3/29]

Finally got a laptop to replace my fat tower at work - Dell XPS 15 9560. I was allowed to choose which one I wanted and chose the XPS for its Linux support since Dell ships developer edition XPS's running Ubuntu so I figured Linux support would be better than other manufacturers. At first they got me the model with the 4K screen but my monitors are 2K and multi-dpi support in Linux is virtually non-existent and even hi-dpi support on its own is pretty terrible. So I got it exchanged for the model with the regular 1080p screen (which happened to also be the updated 9560 model), which works much better. I'm very glad to report that pretty much everything works, including the TB16 desktop dock, with just a bit of settings tweaking. This post is to help anybody considering getting this setup or looking for help getting things working. For now, I am running Kubuntu 16.04 with KDE Neon installed.

List of things I explicitly tested and work:
WiFi, BluetoothThunderbolt charging from T…

Drawing Dashed Lines on an HTML5 Canvas

The canvas element in HTML is great, but has one strange shortcoming: it cannot draw dashed lines (natively). However, dashed lines seem like a pretty common thing to draw, which only highlights the problem.

Looking around, I've noticed several solutions to this problem. Some use trig, and others use their own libraries that must be imported. So in the end, I decided to create my own method.

This code will add the function to all canvas elements, both those already on the page, and any that are dynamically added later.

Here is the code:
CanvasRenderingContext2D.prototype.dashedLine = function(x1, y1, x2, y2, dashLen) { if (dashLen == undefined) dashLen = 2; this.beginPath(); this.moveTo(x1, y1); var dX = x2 - x1; var dY = y2 - y1; var dashes = Math.floor(Math.sqrt(dX * dX + dY * dY) / dashLen); var dashX = dX / dashes; var dashY = dY / dashes; var q = 0; while (q++ < dashes) { x1 += dashX; y1 += dashY; this[q …

Listening for Window Resize events with Prototype

Recently, I came across an issue I had with full-screen (more specifically, full-viewport) canvas drawing. It all worked fine, except that the canvas dimensions must be specified in pixels, as opposed to percentages. This means you can't just set the canvas' width and height to "100%" and be done with it...

The dimensions were automatically set when the page loaded, but if the user resized the browser window after that, the canvas would stay the same size, and would be either too big or too small. Thus, the canvas must be resized every time the browser window is resized.

Prototype makes all of this easy. All that's necessary is to attach a listener to the onresize event of the window object, and then use document.viewport.getDimensions() to determine the new width and height.

Here's some sample code:

Event.observe(window, "resize", function() { var width = document.viewport.getWidth(); var height = document.viewport.getHeight(); var dims …