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?
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.
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 APIThat 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, AndroidAlthough 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.