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, Bluetooth Thunderbolt charging

My Views on Code Indentation

I have read many, many articles about the whole tab vs. space indentation thing. Personally, I don't necessarily agree with most of them. They will require the coder to use a specific indentation size and stick with it, even forcing that on other coders. First off, let me outline my method for indenting code. Then I will explain the reasons and advantages/disadvantages. When I indent code, I will use tabs, but only at the beginning of a line. To align something in the rest of the line, I will use spaces. If a line spills to the next line(s), I will indent that line two tabs further. Rationale: Tabs Why tabs? First off, they're compact in the file (1 byte each). This is really insignificant with current disk sizes, but still. If you indent in spaces, then your file will be larger (unless you indent with one space). Another advantage of tabs is that a tab is a tab. It doesn't specify by how many spaces the code is indented, but rather by how many tabs it is indente

JComboBox with Disabled Items

Recently, I was working on a project in Java and needed to have a combo box, but with certain items in the list disabled (e.g. gray and non-selectable). At first, I simply set a custom renderer for the combo box which checked if the item was disabled. That, however, did not prevent the items from being selected. Thus, I set about to find a viable solution. There are plenty of solutions out there, but none seemed to work exactly the way I wanted. In the end, I ended up subclassing JComboBox to provide the functionality of disabling individual items. Here is my result, in under 100 lines: import java.awt.Component; import java.util.ArrayList; import javax.swing.JComboBox; import javax.swing.JList; import javax.swing.plaf.basic.BasicComboBoxRenderer; public class PartialDisableComboBox extends JComboBox { private static final long serialVersionUID = -1690671707274328126L; private ArrayList<boolean> itemsState = new ArrayList<boolean>(); public PartialDisableComboBox