Android Development in the Enterprise

4 03 2011

Android’s just not ready yet. There I got it off my chest. Just like pulling off a Band-Aid. I’m not even talking about the myth of fragmentation (and for the most part, it is a myth) or the missing Wifi proxy settings issue. It’s what happens after you author that wonderful application your enterprise so desperately needs…how do you distribute it?

Anyone who knows me knows I’m a big evangelist for the platform, borderlining on fanboy-ism. No, I don’t constantly put down that other mobile device OS from the fruit company, I just love Android. It has its shortcomings just like any other device, no device is perfect. But for the most part, I’ve been very happy with my device and the operating system; as a consumer device, it’s wonderful.

However, I got a chance to test the waters as a developer for a proof of concept project for my employer, CapTech. I found all of the development resources for Android to be wonderfully exceptional; I was very surprised. Documentation, working demos, device simulators, support groups, and development tools all already existed and were easily accessible, not to mention very familiar as I had been developing Java/JEE applications for the last 12 years using Eclipse or some derivative of it. While not the most polished UI designer, I felt the shift from web application and server developer to Android developer fairly seamless. I would expect other IT shops to feel the same with backgrounds similar as mine.

Once our application was complete, it came time to determine how to distribute. We had a few beta testers that had Nexus Ones, custom ROMs, or rooted phones so we merely put the application on a web server and gave them the URL. This paradigm worked fine when there are only 3 or 4 users, however we would need to potentially deliver the application to our entire company of 200+ employees (not all are on Android, but hey we plan for the worst). We didn’t want to shove our application into the market and thus exposing it to the entire world for a mere 200 people. We could have housed the apk on a web server just like we did for our beta testers, but how would we manage updates to the application? Email blasts?

These weren’t even our biggest hurdles, it was the choice of carrier for our company, AT&T. Most of our employees are on the company business plan and thus, use an AT&T device. If you don’t know, AT&T blocks installation of Android apps from any other source other than the Android Market itself. Putting our application on a web server wasn’t even an option for most of our employees. I posed this question to the AT&T Developer Forum and received a less than sufficient response, “We’re looking into it”. This essentially means you won’t see something from us in quite some time, if at all.

For Enterprise distribution, Android really needs the ability to add multiple “Markets” or alternative repositories to the existing Android Market. On top of this Google needs to prohibit carriers like AT&T from locking out alternative sources altogether. I understand AT&T’s reasoning, however until a mechanism is in place, Android in the enterprise is completely shut out.

I’m including my post and response to the AT&T developer forum as I was having quite the difficulty obtaining a direct link to the thread.

My post:

My company has a business account with AT&T for our wireless solution. We have roughly 200+ employees on our AT&T wireless plan. We have developed an Android application that we’d like to distribute to our employees and ONLY our employees, so using the Android Market is not an option. However, AT&T has disabled “alternative sources” on AT&T Android devices eliminating the ability to allow our employees to install the application without rooting their phones, installing cooked ROMs, or using something like the Sideload Wonder Machine; all of which are not options in a corporate environment.

How is AT&T suggesting businesses handle this situation? Surely AT&T had foresight into this situation when they decided to cut off end user’s ability to install applications from sources other than the market? We have a legitimate business need to install enterprise applications and currently do not have the means to do so.

AT&T Reps response:

Thank you for explaining your business needs.

AT&T selected Android Market as the exclusive source for applications because it forces developers to be accountable for the apps they submit. If the Android community has issues with an app, the app can be flagged and removed.

As you are probably aware with Android, there is no approval process for applications–they are all accepted by default and Google has stated that they place apps in the Android Market within 24 hours of their submission.

At the same time, we know enterprises prefer not to use consumer storefronts and that that other platforms have methods to distribute applications directly to employees. We are looking at solutions for this now.

Sr Product Marketing Manager
Hsuan-hua Chang ( please join our fan page)




8 responses

5 03 2011
Mark Murphy

“We could have housed the apk on a web server just like we did for our beta testers, but how would we manage updates to the application? Email blasts?”

Add update logic to your app. If you plan on several apps, write your own central updater app to manage updates for all of them, if you wish. Updating an app is not terribly hard (ACTION_VIEW on the APK file with the appropriate MIME type, AFAIK). Determining that you need an update is not terribly hard (hit a well-known URL with version information and compare it to your version). If somebody doesn’t create open source components for this, I’ll be doing it myself before too long, as I expect to have this itch to scratch in the not-too-distant future.

This won’t work on AT&T devices for the reason you cite. For devices distributed within an enterprise, you might be able to temporarily root the device, flip the non-Market apps setting, then undo the root. Whether this works will depend a bit on the device and whether you can get root without replacing the firmware outright.

5 03 2011
Eric Miles


Thanks for the reply. The update logic in the app paradigm has already been discussed within our team and will most likely be implemented. That is certainly one way of circumventing market limitations. Unfortunately in our scenario, our carrier is a bigger barrier and having IT manage the rooting/unrooting and/or using the Sideloading Wonder Machine for 200+ devices is not feasible.

Great feedback!

6 03 2011

I manage APK updates at the enterprise level by hosting the APK with an associated version text file on an internal web server. Any time a user logs in using an old APK the version is checked, if a new version is found an encrypted base64 encoded APK is passed back to the user forcing them to install. This method works pretty well with 600+ users.

7 03 2011

We have a slightly different scenario. Out app is not internal but will only be usable to clients who have a login to our server. Our iPhone app is in the Apple store although it is useless to anyone else. I think we are going to do the same thing with our soon to be release Android application.

We were thinking of just putting in on a server that can be accessed by our clients but reading this and other posts shows that to not be a viable solution.

Crowding the App Store and the Android Market with these sort of applications seems pointless. I hope the providers are able to come up with a solution. Maybe a white list of trusted websites the user controls?

9 03 2011
Eric Miles

As mentioned above, you could code into your app logic to determine when an update is available. However if you need to support any devices on a restricting carrier such as AT&T, you’re out of luck. Not to mention, if you develop numerous apps, you have to bake in this updating logic into every single app you write. It’s feasible but certainly less than desirable.

24 08 2011
Doug Christensen

Greetings Eric,

Thanks for your article. There are a number of mobile device management applications that may address your issue. The link below has supports android app installation base on rules you specify.

11 07 2014
GT Racing 2 hack

I am regular reader, how are you everybody? This post
posted at this site is actually pleasant.

20 01 2016
Free Calendars

Hello, I think your website might be having browser compatibility issues.
When I look at your website in Firefox, it looks fine but when opening in Internet Explorer, it has some overlapping.
I just wanted to give you a quick heads up! Other then that, terrific blog!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: