Google's Android cell phone SDK is now out

The Google Android SDK just shipped, along with a video explaining how to use it.

I’m watching it now and will come back shortly with some feedback.

Published by

Robert Scoble

As Startup Liaison for Rackspace, the Open Cloud Computing Company, Scoble travels the world looking for what's happening on the bleeding edge of technology for Rackspace's startup program. He's interviewed thousands of executives and technology innovators and reports what he learns in books ("The Age of Context," a book coauthored with Forbes author Shel Israel, has been released at http://amzn.to/AgeOfContext ), YouTube, and many social media sites where he's followed by millions of people. Best place to watch me is on Facebook at http://www.facebook.com/RobertScoble

Comments

  1. Ensuring apps can access a phone’s “private” or sensitive resources (camera, gallery, network) is setup to be a hindrance for developers using BREW, JavaME, and just about every carrier out there.

    How will manufacturers and carriers define security realms under Android? Ie when a carrier decides to ship an Android cell phone, what will developers have access to from the manufacturer of the Android handset describing the kinds of applications allowed on the phone, and will this information be accessible programmatically so developers can offer users the appropriately digitally-signed application?

    Java ME uses the concept of security realms which apps can be considered for membership in based on the kind of certificate it’s signed with, if any. Some certificates cost $$$ and require business relationships between developer and carrier. The Realms represent various levels of trust, from Very trusted (the Carrier itself) to completely untrusted (anonymous 3rd party).

    Carrier’s and manufacturer’s Java ME’s certificate privelage settings are not easy to programmatically work with: the matrix of features vs certificate authority vs handset model/carrier customization vs carrier’s network setup is not documented in one place. It must be discovered by hand, scraped from wiki’s, forums, or by purchasing and inspecting a sample handset. It’s a hindrance for app developers.

    I’d like to see Android encompass technology for distributing programmatically translatable security requirements for each handset. Perhaps a keyword sent by the handset in its User Agent String during Web connections, like some already do for age-appropriate content filtration.

  2. Ensuring apps can access a phone’s “private” or sensitive resources (camera, gallery, network) is setup to be a hindrance for developers using BREW, JavaME, and just about every carrier out there.

    How will manufacturers and carriers define security realms under Android? Ie when a carrier decides to ship an Android cell phone, what will developers have access to from the manufacturer of the Android handset describing the kinds of applications allowed on the phone, and will this information be accessible programmatically so developers can offer users the appropriately digitally-signed application?

    Java ME uses the concept of security realms which apps can be considered for membership in based on the kind of certificate it’s signed with, if any. Some certificates cost $$$ and require business relationships between developer and carrier. The Realms represent various levels of trust, from Very trusted (the Carrier itself) to completely untrusted (anonymous 3rd party).

    Carrier’s and manufacturer’s Java ME’s certificate privelage settings are not easy to programmatically work with: the matrix of features vs certificate authority vs handset model/carrier customization vs carrier’s network setup is not documented in one place. It must be discovered by hand, scraped from wiki’s, forums, or by purchasing and inspecting a sample handset. It’s a hindrance for app developers.

    I’d like to see Android encompass technology for distributing programmatically translatable security requirements for each handset. Perhaps a keyword sent by the handset in its User Agent String during Web connections, like some already do for age-appropriate content filtration.

  3. I am sure some people are excited but, this is so lame of you as a blogger. How many SDK come out that you happen to mention (unless its about iPhone or gPhone). You are become shallow, do some soul searching

  4. I am sure some people are excited but, this is so lame of you as a blogger. How many SDK come out that you happen to mention (unless its about iPhone or gPhone). You are become shallow, do some soul searching