Android; The not-so-open open platform

If you’ve taken an interest in Googles Android platform before you’ll be familiar with phrases such as “Android is the first truly open and comprehensive platform for mobile devices” from when the Android and Open Handset Alliance initiative was started, and if you’ve attended talks by some of the Evangelists you’ll have been told that you can replace any part of the ‘phones software, but, this morning, it would appear that you won’t be on a level playing field.

It is true that the Android source code is available to everyone, and it is true that you can write apps which provide the functionality of the contacts app, dialler, Marketplace, or whatever, but what hasn’t come to light until now is that you may not be able to get your application to run on an Android device because some functionality will only be provided to applications signed with a code signing certificate which is specific to each platform.

This basically gives Google and the ‘phone manufacturers the ability to lock down functionality and make it only available to their applications. You might see this as a slightly out-there scenario, but there are already applications on the G1 which are using functionality which will Google have no intention of making available to third-party developers giving it an unfair advantage over any competing app.

We’re not talking about marginal functionality which will be rarely used (such as the ability to change the operating system and hardware configuration), we’re looking at things like Googles Marketplace offering seamless upgrades but any third party updating software being prevented from installing new versions of an application (and even if it could it would be forced to put the user through the permission granting system for every single update). In another post it’s mentioned that dialling emergency services isn’t available to third party applications, so if you were thinking of writing a trendy replacement for the in-built dialling application, well, you’ll just need to make sure your users know how to revert to the “approved” one shipped with the phone if they need the police, ambulance, or fire services.

So remember, although Apple may reject third-party apps because they duplicate functionality, if you’re developing for Android you may find that although you can write an app which offers a better dialler, browser, or whatever, you may find it won’t run on a device purely because of the way the platform has been designed.

17 thoughts on “Android; The not-so-open open platform

Add yours

  1. You seem a bit mistaken. The limitation is not on the Android Platform but actually on the G1 operating system.

    And as a G1 user I want only trusted apps to be able to place emergency calls. Same as installing. It’s a core functionality. And most of the G1 “limitations” are actually T-Mobile requirements to keep their phone usable and safe.

  2. It’s been confirmed that these are not G1 issues, they are intential design “features” of the Android platform.

    The problem is that there are better ways to do this which allow third party apps access to the same functionality. In the case of emergency calls the OS can pop up a confirmation window whenever the number is dialled, this would allow the James Bond dialler and the default dialler to access emergency calls with the same restrictions.

    Android has been publicised as an open platform. How open is it when bundled apps have preferrential access to features?

  3. alf, right now I’m using phone with not one, but two applications that do something verboten in Android world:

    – one application plugs-in into default dialer – it provides rule-based filtering of incoming calls (Smartphoneware Best Blacklist) – api for this was deliberately left out of Android and the replacements or default dialer forks will never be able to have funcionality of supplied dialer.

    – another modifies in-call screen (Smartphoneware FSCaller). This is also something that you will be never able to do without rebuilding platform with your key.

    So isn’t it strange, that such closed platform as Series60 provides more opportunities to customize your phone to your needs than supposedly open platform like Android?

    And don’t pull T-Mobile into this – they were perfectly happy to allow S60 on their network for years. If it conforms to GSM or UMTS, they don’t have a say in it anyway.

  4. Just to give a little balance here:

    1. For dialing emergency numbers, as I have already said in our “discussion” on the group, if you are okay with the user confirming the call then there is nothing here that is an issue: you can just bring up the dialer with the emergency number, for the user to confirm and place the call. I really don’t understand why you are harping on this when you can do exactly what you seem to be complaining about. (And note that the ONLY limit is on directly starting an emergency call — you can write a dialer, doing whatever kind of filtering you want, that allows the user to directly start any other kind of call with no confirmation at all.)

    2. For installing applications, again we have had this discussion, and again the ONLY difference is that the Market app that ships with the phone is able to confirm application permissions before actually downloading the app. When market installs an update, it will re-confirm the permissions with the user, as any other market-like app must do when they go through the public API for performing an install. And there is no “even if it could” here thing at all — WHY in the world do you think you can’t instigate updates? You can. Just download the new .apk, and have the system install it for you. The ONLY difference between these two is that the third party app will need to download first and then install, but especially in the case of updates the user experience will be pretty much exactly the same as the Market app.

    3. On the other issue of modifying the in-call screen, as I have said now repeatedly this is simply a matter of is not having time to do this in 1.0. The in-call screen is closely tied to the telephony subsystem and phone locking facilities, and it is not simple to provide an SDK API to replace it that can be maintained for the rest of Android’s life. This wasn’t done not because we didn’t want people to do it, we just didn’t have time for 1.0.

    Finally, Tom, surely you must be aware that Symbian requires that you get a certificate from them in order to use most of the interesting functionality of the phone. Android has no such requirement — we only require self-signed certificates (ones a developer can make on their own without having to deal with anyone else), and these give you full access to the entire SDK.

    This is fundamental to Android’s position of being open, that there is no gatekeeper deciding what apps are allowed to use various features. This does, however, require a lot of care in how features are exposed: since there is no regulation, there is a lot more fear of malware and other bad applications. I believe strongly that Android is pushing the phone industry to be more open, and we will continue to do so in future releases. At the same time, we also want to create an environment that is much less conducive to malware and viruses than is accepted in a desktop kind of system.

  5. One last comment, on the whole “but there are already applications on the G1 which are using functionality which will Google have no intention of making available to third-party developers” thing.

    There are many things that are simply part of the system and that applications have no business doing, such as:

    – We do not allow any application to intercept the home key, so the user can always get out of an application (so the system implements a bunch of functionality around the home key that apps simply can’t change).

    – We do not allow applications to send input events to other applications (so they can’t drive the application out of the user’s control and bypass security by sending events to modify settings, send e-mails to themselves, etc, etc).

    – We do not allow applications to directly install other applications without going through the systems user interface for the user to confirm (so they can’t install whatever app they want with whatever permissions they want, effectively giving them permission to do every possible thing on the phone even though they didn’t explicitly request them).

    The vast majority of the built-in applications on the phone only need and use the regular permissions that are available to third party applications. This is, in fact, a key aspect of our design for Android: if we couldn’t take the entire Google application suite and install it as a third party application on an Android phone that didn’t ship with those apps pre-installed, then somewhere along the way we have failed.

    There are, however, a few select apps that due to their nature are allowed to have some closer interaction with the system. These can behave more like parts of the system than like regular applications, because they are built in to the system image and so (a) are always built against a specific version of the platform so can use APIs that are not yet stable enough to expose in the SDK, and (b) can be trusted to do system things since they are bundled with the system itself.

    The main apps that exist in this gray world between system code and application code are the in-call screen and phone UI, the settings application, and to a lesser extend the Market app. These are doing things that are very core to the system: placing and managing phone calls, providing access to all of your global settings (and such key things as the security and lock settings), and installing third party applications.

    So the Market, as being part of the system itself, can implement a slightly different flow than a third party app could, since the system can trust the Market itself to correctly confirm permissions with the user before starting an install. That said, the Market really isn’t a whole lot more special than that: if it wasn’t included on a phone, and we wanted to allow people to download and use it, all we would need to do would be to have it download apps before going through the permission UI. It’s a little less smooth, but in no way the end of the world.

    And, you know, at the end of the day it -is- an open platform. The Android source code is available. You can write your own marketplace app against the full open-source platform, and take it to carriers and convince them to bundle your app with their phones.

    And if they don’t bite… well, you still have your marketplace app that people can download to their phone, and it just can’t check permissions with the user before downloading other apps and needs to confirm with them before removing apps.

  6. @Dianne

    You still seem to be missing the point. This is about the “openness” of functionality available to apps in the version of Android that is now shipping to the general public. We’re not talking about a work in progress, we’re talking about a version of Android that is now in the hands of consumers as a finished product (unless you want to tell me that everyone who bought a G1 should have been told they’re part of a beta test programme?).

    Yes, third party diallers can call the default dialler when need to call emegency services, but why should they have to? The default dialler doesn’t so why isn’t the OS doing the emergency call protection and applying it to the default dialler as well?

    Yes, Third party apps can start the system installer to show the user which permissions are available, but if this is what third-party apps have to do shouldn’t you be eating your own cake and forcing Marketplace to do the same?

    You also seem to have even contradicted your self in the above posts. First you said;

    “This is fundamental to Android’s position of being open, that there is no gatekeeper deciding what apps are allowed to use various features.”

    But then you say;

    “There are, however, a few select apps that due to their nature are allowed to have some closer interaction with the system.”

    Thats nice if you’re the gatekeeper who decices which apps are allowed to have the closer interaction. Not so nice if you’re a developer working on a competing product.

    There has already been one request for a third party alternative to Marketplace to show the permissions before downloading the app, but it can’t whereas Marketplace can because of decision made bye Google, HTC, and/or T-Mobile.

    Let’s also get one thing clear; Marketplace isn’t a core feature of the ‘phone, it’s a core feature of the Android revenue model. Users have many ways to download apps, but the one that has a deal offering a cut of sales to the carrier is the one thats getting preferrential access to ‘phone features.

    So I’m not sure how you can say it’s a truely open platform where functionality is limited unless you’re with the in crowd or generating cash for the carriers.

  7. Al,
    I followed a link on Wikipedia to this article.Thought I’d throw in my two cents worth.

    You seem really angry about this and I don’t really understand why. Of the few areas where developers are restricted, the reasons seem to enhance the user experience. If any program can take over basic phone functions completely, then potentially a nefarious developer could completely destroy the purpose of the phone, that of being a phone.

    In regards to not being able to call 911 from an a custom app, I can only say “good.” If it could call 911, how long do you think it’d be before someone develops a program to start calling 911 repeatedly? 911 could be jammed up because of it.

    The only area where I think your point is valid is for the Marketplace. It’s not fair that non-Marketplace developers have a less pleasant installation environment than approved ones. That said, I don’t think the difference is that huge.

    I don’t think you can claim that any cell phone operating system (one that’s actually used) is more open than Android. Developers can’t do everything but the restrictions are pretty limited.

  8. “I don’t think you can claim that any cell phone operating system (one that’s actually used) is more open than Android.”

    That’s easy to refute: OpenMoko has been running on many phones for a while now. It’s completely open-source. The primary hardware for it is the FreeRunner, which was specially designed for it, is itself open-source hardware (!), and even has a debug board available.

    In fact, the FreeRunner (second revision) has been available to consumers since July. Remember, that was about 2 weeks before Google accidentally emailed everybody that there was a special private SDK release for some developers (apparently intended to be kept a secret), and almost 4 months before (most of) Android was made open-source and you could actually buy any phone that ran Android.

    You could say OpenMoko has a less mature UI, but the reviews I’ve read of the G1 say it’s no iPhone, either. The G1 seems to be trying to occupy the sweet spot between “completely open” (Openmoko) and “awesome UI” (iPhone). You can argue that it’s open-enough or good-enough-UI, but it’s clear that there are more-open and better-UI phones available. It’s middle-ground, not best-of.

    I’m not getting the “angry” vibe, so much as a “misleading” vibe. It’s easy to see why. Steve Jobs has always been honest about what developers can’t do with the iPhone. The Openmoko guys have always been “100% open source, full stop”. Google has been promoting Android as being open-source, until you get to the fine print. (You can modify anything! … except the parts you can’t.) If the policy is going to be “*mostly* open-source”, then don’t try to sell it to us as “open-source”.

  9. @Eric; I’m more dissapointed than mislead. There are better mays to protect users from malicious apps than restricting functionality to approved applications as I pointed out in a previous reply.

    @Mokomoko Good points, you also missed though that the Android emulator is still, even after the release of the G1, missing functionality which only exists on the real hardware (Ability to install non-marketplace apps, ability to return a unique ID from the system properties, etc.).

  10. “”In regards to not being able to call 911 from an a custom app, I can only say “good.” If it could call 911, how long do you think it’d be before someone develops a program to start calling 911 repeatedly? 911 could be jammed up because of it.””

    Funny, my PC has this ability, but yet I do not see regular repeated calls to 911 jamming up the system, do you?

  11. Huh. Android is not too open. It’s weird. It’s Java-only. It allows to vendor and operator more control than to device owner who payed moneys. And Linux is USELESS in Android. It just used to launch Java crap…

  12. Hi,

    I’ve read all of this, and I’m confused to the point that I won’t by investing into Android, hence buy an Android phone.

    The only interest in Android is its openness. Either it’s open, or it’s not. And it doesn’t seem to be, otherwise discussions like these woulnd’t be taking place.

    I’ve been trying to simply replace the default contacts applications with my own. Straight forward, and announced officially in the past (as one of the real advantages of the open platforom. “All applications are equal”.

    Today, after facing problems in doing this, and after reading stuff like above I am disappointed and have to say “It’s all a marketing lie”.

    Nohing more, nothing less.

    Thanks God, things like Apple or Microsoft at least tell you openly, without confusion about what you’re allowed to do, and what not.

    Sorry, but this is silly and not professional.

    I’m out of the whole Android mess.

    Regards, Marc

Leave a Reply

Your email address will not be published. Required fields are marked *

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑