Google is going to sell an unlocked G1-like phone for Android developers, without ROM signing and without SIM locking. It's not clear if the bundled ROM image will include all the applications of the T-Mobile G1 so it may be not usable as a normal phone, but this is a step in the right direction.
Android has been finally been made fully open source. Previously only a small part of Android was open source and, for example, it was impossible to build it for a new architecture.
The Android SDK 1.0 as been released, and it is now in feature and API parity with the recently released T-Mobile G1 in the USA. The API changes since 0.9 appear to be very small so most current applications will work on the G1, and the rest will be very easily updated. Now let's hope Google and HTC deliver on the promise of open handsets and sell a factory unlocked version of the G1.
The Android version of the App Store, the Android Market, has been announced:
Developers will be able to make their content available on an open service hosted by Google that features a feedback and rating system similar to YouTube. We chose the term "market" rather than "store" because we feel that developers should have an open and unobstructed environment to make their content available.
It will be available as a beta version on the first handsets and will only allow for free applications. On a later version paid content will be allowed along with other features like versioning, multiple device profiles and, analytics.
There is a little gem in the documentation of the latest Android SDK version. A mention of native NPAPI plugins:
WebViews now support plugins. The location of the plugin is set via WebView.setPluginsPath(). Plugins are native (C/C++) code that implement the NPAPI interface.
This opens the door to native plugins on the browser. Including Adobe Flash, if Adobe wants to.
Android is a managed platform running interpreted bytecode. But there is now an explicit mention of native, third-party binaries in the form of NPAPI complaint browser plugins. This is understantable since such plugins often implement audio and video codecs and a bytecode interpreter is probably not fast enough. But this also means it may be possible to develop applications that bundle a native WebView plugin for internal usage.
The SDK is not yet 1.0 but I hope we hear more about this feature. Let's hope it remains here for every developer who wants to use it and on shipping devices.
After 5 months, Google finally makes a new public release of the Android SDK:
However, the APIs are now pretty stable and we don't expect any major changes. If you're one of the many developers who were waiting for something a bit more mature, this might be a good time to take another look.
Looks like some stuff has been cut and ton of new APIs have been added. But the most important thing is that APIs should be now much more stable and similar to the version that is going to ship on devices.
A video of HTC Dream, the much rumored Google Android "launch day" handset from HTC, has been making the rounds in the last 12 hours, and it looks fantastic. Can't wait to see my code running on it!
Google IO Sessions about Android. I'm two months late on discovering this, but given the low profile Android has fallen into any news or newer info is nice to have. Now please Google, update the SDK and give developers equal chances on deploying applications on launch day.
How current smartphone platforms deal with background apps
Developers and the Apple faithful are still arguing about Apple decision to block third party apps from running in the background on the iPhone. I'm going to try to offer a bit of perspective on the issue by explaining how current smartphone platforms deal with background apps.
Going by the classic definition of smartphone, both Google Android and the Blackberry JDE are arguably not smartphone platforms and feature phones with J2ME are sure as hell not one. But I am going to include them for the sake of comparison.
Palm OS
Lacks background process. Anything running "in the background" is in fact an OS interrupt handler or some other hackery. Palm OS is simply obsolete in terms of operating system design, and has been for years.
Symbian
Symbian allows full GUI background processes. When the device runs low on memory the operating system will start shutting down background processes. Additionally many of its APIs have explicit error conditions related to low memory errors and resource sharing. The operating system notifies the application when it needs to close it for memory reasons by sending the EEikCmdExit message.
Windows Mobile
Windows Mobile is similar to Symbian w.r.t. background apps. It allows full GUI applications to run in the background and uses its standard message delivery system to notify the application before closing if it runs out of memory (messages WM_HIBERNATE and WM_CLOSE).
Feature phones with J2ME
Sony Ericsson first, and recently Nokia have added background running for J2ME applications. Midlets are by nature usually very frugal on memory consumption so it works fairly well. In addition J2ME also supports termination notifications issued by the OS, so applications can save their running state on low memory conditions. That said the majority of J2ME feature phones are not from Sony Ericsson or from the high end Nokia range, so in general background running midlets are not supported.
Blackberry JDE
I am not experienced on Blackberry development, but as a platform it has supported background applications since day 1 and they are explicitly supported in the API.
Android
Android probably features the best and most balanced background application support. It has memory warning callbacks, like Symbian, and the explicit guarantee that the operating system will try its best to keep the application around, like Windows Mobile. But its defining feature is the the concept of Services: UI-less processes that run in the background and can be spawned on request by applications or by URI schemes:
A Service is a body of code that runs in the background. It can run in its own process, or in the context of another application's process, depending on its needs. Other components "bind" to a Service and invoke methods on it via remote procedure calls. An example of a Service is a media player; even when the user quits the media-selection UI, she probably still intends for her music to keep playing. A Service keeps the music going even when the UI has completed.
iPhone OS
The iPhone OS is a full Unix-like operating system, with a full blown kernel with memory protection and demand paging, running on a powerful CPU that has full support for all these features. In terms of OS design and features it leaves everything else in the dust. Which only makes the way Apple has chosen to cripple third party applications more painful to accept. The iPhone OS has full support for background applications if you are Apple. If you are not then it will kill your application the moment the user jumps out of it.
How Apple could add backround apps on the iPhone
The official reason is that background apps would kill the iPhone battery in no time, so they are not supported. But there is another way. Instead of keeping the full blown GUI of the application have the OS support the Google Android concept of Services. UI-less processes with access to certain features like the sound and network system, working under CPU and I/O quotas so they play nice to each other. They would be still under a "can be killed anytime" policy, but since they don't need to keep a GUI around they would be much easier on the RAM and CPU of the device.
Full video of a roundtable organized by TechCrunch on the impact of the iPhone on the mobile Web, and how it relates to other (non-)platforms like Android.
AdMob CEO Omar Hamoui (in T-shirt) argued that it indeed represents a fundamental shift because it is the first time most people are actually using the mobile Web, regardless of how long it’s been around.
In case you are left wondering what killed the first ALP smartphone, all clues point towards LiMo, the Linux Mobile Foundation and its pet project. The reply came from Edelman, Orange's PR firm, which also told us to contact Samsung and Access directly, but stated: "just so you know the Samsung i800 has been withdrawn. Since the original project was defined back in February there have been a number of advances in mobile technology."
I love how there is not a single smartphone listed at the LiMo site. LiMo looks like a closed, feature phone software licensor, just like Symbian MOAP.
Ryan Paul from Ars Technica writes:
Third-party Android application developers, who have grown increasingly frustrated with the lack of SDK updates, were shocked to discover that Google has been secretly making new versions of the Android SDK available to the Android Developer Challenge (ADC) finalists under non-disclosure agreements.
Apple published multiple versions of the iPhone SDK, and multiple betas of the 2.0 firmware it supported, in the period of 6 months. Android has been around since November and Google has published 3 versions of the SDK, including one that broke nearly every single application. The last version was released in March and it is in dire need of an update. Not cool Google, not cool at all.