Google on Monday disclosed more details about Android 3.0, nicknamed “Honeycomb,” prior to the operating system’s official unveiling, scheduled for Wednesday.
Honeycomb is designed from the ground up for tablets and has a new holographic user interface. It includes a so-called Action Bar to let users control their apps, offers five customizable home screens and has additional connectivity features.
Honeycomb is backwards compatible with applications developed for earlier versions of Android, or apps developed for smaller-screen sizes.
The new OS also offers expanded features for app developers.
Android 3.0 is designed to run on either single or multicore processor architectures.
Google did not respond to requests for comment by press time.
The Sweetness of Honeycomb
In its browser, Honeycomb replaces windows with tabs. It has a new “incognito” mode that allows anonymous browsing. Bookmarks and history are presented and managed in a single unified view. The OS offers multitouch support to JavaScript and plug-ins.
The Honeycomb contacts app has a two-pane user interface (UI) and Fast Scroll so users can organize and locate contacts more easily. Possibly indicating that Android tablet makers might target international business users, the Honeycomb contacts app offers improved formatting of international phone numbers as user types based on home country and an international number parsing library.
Honeycomb’s new UI makes interaction, navigation and customization available to all apps, even those built for earlier versions of Android. Built-in support for Media/Photo Transfer Protocol lets users sync media files with a USB-connected camera or desktop computer directly.
Buzz for the Developers
Android 3.0 offers API support for Bluetooth A2DP and HSP profiles that developers can build on. These features let apps query Bluetooth profiles for connected devices and then notify the user, for example.
Developers of device administration applications in Honeycomb can support new types of policies, including policies for encrypted storage, password expiration and password history.
Further, developers can break the activities of their apps into subcomponents called “fragments,” then recombine these in different ways. Honeycomb also offers an updated set of UI widgets developers can use to quickly add new types of content to their apps. These widgets are redesigned for use on larger screens such as tablets, and they incorporate Honeycomb’s new holographic UI theme.
Honeycomb includes a flexible animation framework that lets developers animate the properties of UI elements such as views, widgets, fragments and drawables. Animations can create fades or movements between states, loop an animated image or an existing animation or change colors, for instance.
Honeycomb Plays on Any Core
Android 3.0 has been designed to run on either single or multicore processor architectures. Changes in the Dalvik virtual machine and elsewhere add support for symmetric multiprocessing in multicore environments.
“The multicore aspect of Honeycomb is key to taking advantage of the latest generation of ARM mobile processors,” Carl Howe of director, anywhere consumer research at the Yankee Group, told LinuxInsider.
New ARM processors are multicore.
“However, this doesn’t necessarily mean that apps will use multicore processors without modification; app developers must code their apps to take advantage of multiple cores,” Howe added.
Apple developers get this functionality for free if they use Apple’s Grand Central Dispatch, but Android devs “will have to use more low-level multithreading techniques,” Howe pointed out.
One Plus One Doesn’t Make Two
Support for symmetric multiprocessing (SMP) might even benefit single-threaded applications, according to the Android developers’ website. For example, with two active cores, a single-threaded app might see a performance boost if the Dalvik garbage collector runs on the second core. The system will arrange for this automatically.
However, SMP support doesn’t necessarily mean single-threaded apps will speed up on multicore systems, Bob O’Donnell, a program vice president at IDC, told LinuxInsider.
“Just like with PCs, multicore PCs don’t give a speed improvement that’s even close to being linear,” O’Donnell pointed out. “Depending on how the software was written, you might only get a 30 to 40 percent speed improvement on the second CPU and maybe 5 to 10 percent on an additional CPU, and maybe even zero. That’s why the core wars on PC CPUs stopped.”
Developers will need to write multi-threaded software to really take advantage of multicore processors, O’Donnell stated.
The App Wars
Apps are recognized as a key driver for both smartphones and tablets, and Google needs to ensure it has enough apps to lure customers into purchasing Android tablets.
Google’s reportedly looking to hire devs to speed up in-house app development.
“Google may be planning to offer Google-generated apps that are preloaded onto tablets,” Mark Beccue, a senior analyst at ABI Research, told LinuxInsider. “But how do you normalize the app store distribution issue for developers?”
Unlike Apple, Google isn’t integrated vertically enough to ensure that its app store comes preloaded on a smartphone or tablet, Beccue remarked. “It will be up to either the OEM who makes the tablet or to carriers to decide that,” he elaborated. “How will Google overcome that?”
That issue might impede Android’s growth because it makes the Android platform less attractive to devs than Apple’s iOS platform.
“I think iOS will likely be a more profitable platform for app developers because of its clean and clear business model and easy payment systems,” Howe said. “Android will be more of a Wild-West commercial environment, requiring developers to stake their claims and spend more time figuring out how to monetize them, since there’s no one way to do it.”
Loading ...
I think your statement, "(Honeycomb) app developers must code their apps to take advantage of multiple cores…Apple developers get this functionality for free" is misleading. App developers on both sides need to take their code and break it into threadable pieces. After that they can turn to the OS threading functions/utilities to schedule and dispatch those pieces.