Android-1

Can Android be truly ‘open’ on the T-Mobile-locked G1?

All the way up until the official announcement of the T-Mobile G1 phone, we constantly heard about T-Mobile's status as a founding member of the Open Handset Alliance and how Android was to be a truly open piece of software, allowing third-party developers to not only create applications for Android, but to actually change the software itself for improved functioning. And while this all has been confirmed as of this morning we also learned that the G1 would be locked to T-Mobile. And while it's pretty standard these days for phones to be locked to specific carriers, it still raises some questions. For instance, can you truly have an "open" piece of software if it is officially restricted to just one carrier? There's already a thread going about the subject in our Forums and many seem to think there will be an iPhone-style rush to unlock the G1 in the coming days and weeks. Does this mean there will be a G1 Dev Team, too? And while a mad dash to unlock the G1 still remains to be seen, the fact that we even have to have this conversation is a tad bit unsettling. After all, isn't the entire point of an Open Handset Alliance to maintain an open attitude and allow for the free exchange of ideas for the betterment of the final product? That's what I took it to mean, anyway. What do you think? If the G1 is locked to T-Mobile can Android be truly allowed to grow to its fullest potential? Or am I just overreacting?

T-Mobile G1 using multi-core Qualcomm processor?

A forum user has tipped off Android Community on the G1 chipset. It appears the chipset used in the G1 will be made by Qualcomm, and is one of the company's 7201 multi-core processors, a dual core to be precise. It is said to be more stable and energy efficient than most processors; however, unusually, the two cores are not the same.

The first core is a speciality core dedicated solely to phone functionality such as making phone calls. The second core is a general purpose core intended for applications, in order to accommodate more application processing load. The end result should be less lag due to overloaded phone processors. According to the tip, clock speed for both cores will be the same. Because of this, overclocking the G1 will not have much of an increase in performance. There are reportedly still some problems with the multi-core setup that, under specific situations, may cause the phone to crash; Qualcomm is apparently "working around the clock" to fix the drivers at the root of this.

Google explains Advanced Bluetooth & GTalk API omissions

After the news of the latest Android SDK release, Google came in for some criticism over a number of APIs the company removed and that, as a result, would not be present in the eventual Android 1.0 platform.  Headlines suggested that Android would have no Bluetooth support, for instance, and the whole OS was accused of not being ready for primetime.  Now the Developers Blog have spoken up to explain two of the most prominent omissions - the advanced Bluetooth API and the GTalkService - and justify the reasons for their being (temporarily) left behind. Despite the rumors, Android will support the usual array of Bluetooth headsets and dongles.  You'll be able to use it with your hands-free or tether it to your laptop (carrier T&Cs permitting).  What won't be there is the API that exposes Bluetooth functionality to developers:
"The reason is that we plain ran out of time. The Android Bluetooth API was pretty far along, but needs some clean-up before we can commit to it for the SDK. Keep in mind that putting it in the 1.0 SDK would have locked us into that API for years to come" Nick Pelly, Android engineer responsible for Bluetooth API
That means, initially, developers won't be able to use Bluetooth for, say, short-range wireless gaming between Android handsets.  It's a disappointing omission, but the Android team are promising it'll make an appearance in a future release. Secondly, the GTalkService API, which would have presented a straightforward interface for the exchange of messages between Android devices.  Rather than time shortages, it's security that scuppered that particular API, both of personal details (communicating with other mobile users would then see them added to your Google Talk friends list, whereupon they could see your email address and other information) and of application security.
"Although we would have loved to ship this service, in the end, the Android team decided to pull the API instead of exposing users to risk and breaking compatibility with a future, more secure version of the feature. We think it's obvious that this kind of functionality would be incredibly useful, and would open lots of new doors for developers. One of our top priorities after the first devices ship is to develop a device-to-device (and possibly device-to-server) RPC mechanism that is fast, reliable, and protective of developers and users alike" Dan Morrill, Developer Advocate, Android
Although on first glance it's easy to criticise Google for snipping out features, if poorly executed APIs led to future security or privacy breaches then the frustration would be even greater.
1 2