6 thoughts on “Google’s Android cell phone SDK is now out

  1. 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

  2. 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

  3. 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.

  4. 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.

Comments are closed.