Samsung i9100 is the dual-core Galaxy 2, sequel to the Galaxy S?

Along with a Sony Ericsson Anzu, the James Bond of cellphones -- alias Eldar Murtazin -- claims to be playing with a Samsung GT-i9100 right now, calling it the "Galaxy 2" and saying it's "so technically advanced" thanks in part to a dual-core processor. It seems like a long shot that this would be the Cortex-A9-based Orion since chips and development boards are just now being sampled -- but considering how far in advance Murtazin tends to score phones, we can't rule anything out. One possible scenario is that the i9100 could be something akin to a TouchWiz-skinned version of the upcoming Nexus S, much as HTC's Desire was essentially a Sense-skinned version of the Nexus One. Samsung, of course, has been pushing TouchWiz very hard across its Galaxy S line this year, and if the Nexus S is as beastly as the rumors are claiming it to be, there's little doubt that Samsung would love to repurpose the hardware for something with a little more of its flavor thrown in. Speaking of the Galaxy S, keep in mind that the original European GSM model goes by the code GT-i9000, so it would stand to reason that the i9100 could be the proper successor -- and with Gingerbread-based TouchWiz and a dual-core processor on board, we'd say they're off to a strong start. [Thanks, Peter]Samsung i9100 is the dual-core Galaxy 2, sequel to the Galaxy S? originally appeared on Engadget on Sun, 14 Nov 2010 18:33:00 EDT. Please see our terms for use of feeds.Permalink Android and Me  |  @eldarmurtazin (Twitter)  | Email this | Comments

Gartner's global phone sales rankings match IDC's, but say the big guys have less of the pie; Android moves to number two overall

At a 30,000-foot level, the global mobile phone sales numbers for the third quarter of 2010 just released by Gartner match up with what IDC posted a few days ago, but you might say the devil's in the details. These guys have all of the top five players -- Nokia, Samsung, LG, Apple, and RIM -- at noticeably lower total market shares than IDC did, suggesting that second-tier players like Sony Ericsson, Motorola, and HTC (if you can really call them "second-tier") are grabbing more hearts and minds. And hey, considering Motorola's prominent role at Verizon and HTC's ever-growing global presence, we could totally believe it. Notably, Nokia is well below 30 percent in Gartner's report at 28.2, a whopping drop of 8.5 percent year-over-year -- way more than the 4.1 percent drop that IDC's got pegged. Of course, there's no way of knowing which of the two reports is more accurate -- and you know how margins of error work with these things. Hey, at least the rankings are the same, right? [Thanks, Tad] Update: As commenters have pointed out, the Gartner report also puts Android at 25.5 percent market share, moving past BlackBerry OS to become the number two smartphone platform behind Symbian (they've got iOS at third, BlackBerry fourth). Considering the platform's trajectory this year and sheer variety of Android phones now being solid worldwide, it's no surprise.Gartner's global phone sales rankings match IDC's, but say the big guys have less of the pie; Android moves to number two overall originally appeared on Engadget on Wed, 10 Nov 2010 12:06:00 EDT. Please see our terms for use of feeds.Permalink   |  Gartner  | Email this | Comments

Top 5 Tips for #adobemax Attendees #androiddev

Hopefully by now you are ready for #adobemax and are cruising to LaLa land as I like to call it.  Tons of great sessions for designers, developers, and really any Adobe and Motorola fan.   Here are the top 5 tips for #adobemax in my mind: Download the MAX Companion app for Mac, Windows, Linux, or Android (2.2 or higher). It has all the sessions listed, maps of the venue, ability to see all the Twitter chatter, speaker list, your personal session schedule, news about MAX, and wireless info.  Search for "MAX Companion" on the Android Market or download the desktop app at http://max.adobe.com/companion/ Attend the two Motorola sessions to learn valuable tips on AIR and the future of mobile content: 10/25 2pm: DROID and Adobe AIR: Creating Stunning Applications for DROID Devices with Suzanne Alexandra, Android developer Adovocate at Motorola 10/26 1:30pm: Future of Mobile Content: Content Owners talk about HTML5, Flash and Apps with Rusti Baker from Motorola Stop by the Motorola booth and meet the team, get your questions answers, and get interviewed for this blog Tweet about everything you see and do at Adobe MAX with the hashtag #adobemax and the # 5 tip....drum roll please...Attend or watch the keynotes live in-person or online. More info at http://max.adobe.com/online/   It's going to be a great week!  Look forward to meeting everyone. Tweet @djksar if you wanna find me with the hashtag #adobemax. To Adobe MAX I go!   -Randy   P.S. Want more #adobemax related content on this blog?  Sign-in as a MOTODEV member and click on the kudos icon at the bottom of this post.    

Dell's Stage UI headed to Streak, also unofficially works on EVO 4G (video)

The first time the words "Stage UI" passed our lips, they were in relation to the Dell Thunder leak, but now we're hearing that Dell's custom Android user interface will actually appear alongside Android 2.2 when the update finally arrives on the five-inch Streak. We've just learned that's going to happen this winter in Japan when the Streak launches on SoftBank at the very least, as both are advertised for early December there, but we expect we'll see the updated OS even sooner in the US and Europe for obvious reasons. What's more, an unofficial build of Froyo that leaked out for the Streak last month has since been found to have Stage UI on board. StreakSmart's got a video of a custom ROM running a series of Dell-specific widgets on the Streak, and sister site Good and Evo managed to trick the very same software to run on a rooted HTC EVO 4G. You can see examples of both on video after the break, but here's the basic idea behind the UI -- giant panes of contacts, apps and shortcuts that fill an entire screen each, but leave your app drawer accessible at a swipe. If you're feeling daring, you can try the ROM for yourself at our more coverage link. Just be careful flashing that new baseband, eh? [Thanks to everyone who sent this in]Continue reading Dell's Stage UI headed to Streak, also unofficially works on EVO 4G (video)Dell's Stage UI headed to Streak, also unofficially works on EVO 4G (video) originally appeared on Engadget on Sat, 06 Nov 2010 19:04:00 EDT. Please see our terms for use of feeds.Permalink @MichaelDell (Twitter)  |  SoftBank, StreakSmart, Good and Evo  | Email this | Comments

DROID Catches Some Air #adobemax

  Things have been so exciting lately. I've been catching some air. Specifically, I've been creating Adobe AIR® apps for Android devices like the DROID X and DROID 2.   I just love this new development environment, where you create apps for Android with Adobe Flash®, Adobe Flex®, and ActionScript. Your app appears in the launcher on the device just like any Android app, but it runs in the AIR runtime environment rather than on the Android platform. So far, I've found AIR apps visually stunning, easy to create, and fun to use.   You can upload AIR apps, either paid or free, to Android Market. Best of all, your AIR app can run on multiple platforms, including desktop, browser, and other mobile devices.   I'll be presenting a developer session on AIR development for Android at Adobe MAX. The conference is October 23-27 in Los Angeles, and my session is DROID and Adobe AIR: Creating Stunning Applications for DROID Devices, Monday Oct 25 at 2pm. We'll talk about how to take advantage of the best features of devices like the DROID X and DROID 2. You'll get valuable, time-saving tips and code samples, on topics like using multitouch and the camera, and also learn how to make sure your app is available in Android Market on the devices of your choice.   If you're already planning to be at MAX, I'd love to see you there. If not, there's still time to register. The array of sessions and labs this year, including those on AIR for Android, is very impressive. Chances are you'll leave ready to take full advantage of Adobe AIR and the popular DROID devices by Motorola.   So you're invited. Come catch some air with us!   -Suzanne    

Exclusive: Samsung 'flagship' phone with Gingerbread and huge display coming in early 2011 (update)

Okay, so you're not feeling Samsung's Nexus S. We'd say that's a little premature, but still, we get it. We understand. How about this, then? Is this more to your liking? We've just been tipped with a few morsels on what should become Samsung's flagship Android device early next year -- February, to be specific, suggesting we could see an unveiling at MWC -- and it's looking promising. Different parts of the slide deck describe it as having either a 4.3- or 4.5-inch "sAMOLED2" display, presumably standing for "Super AMOLED 2" and implying that Sammy's made some advancements over the screens we've been seeing on the Galaxy S series this year. It'll naturally have Android Gingerbread and be equipped with an 8 megapixel camera capable of 1080p video capture, 14.4Mbps HSPA, Bluetooth 3.0, a 1.2GHz core of some sort, and 16GB of storage onboard. The deck describes it as having an "ultra sleek design," and judging from the side shot, we'd tend to agree. So who's holding out for this? Update: We're confident that the above slide comes from Samsung, but one of the pictures therein is most definitely not of a new Samsung phone -- but rather a VoIP handset by Apiotek from several years ago. Considering the image in question pops up right away in a Google Image search for "ultra slim phone," we're inclined to think Samsung got a little hasty putting together the PowerPoint this time round. [Thanks, Nathan H.] Gallery: Samsung 'flagship' phone with Gingerbread and huge display coming in early 2011Exclusive: Samsung 'flagship' phone with Gingerbread and huge display coming in early 2011 (update) originally appeared on Engadget on Thu, 11 Nov 2010 21:13:00 EDT. Please see our terms for use of feeds.Permalink   |   | Email this | Comments

PC World stops selling the Toshiba Folio 100, we go hands-on to find out why (video)

£999.99 ($1,612) for a Toshiba Folio 100?! Either its Tegra 2 chip's made out of gold (which would explain its rarity) or someone got super bored at that PC World store in the British Midlands. Soon after receiving this photo, we put on our detective hat and headed over to our local branch in London, only to find that it had already stopped selling the offending Android tablet merely ten days after its European launch. We quizzed the staff about the aforementioned £999.99 pricing and then all was clear: apparently this is a standard internal convention to stop its folks from selling certain products, so the price tag you see above wasn't supposed to be there at all. Oopsie! So why is PC World (and the whole DSG International chain) pulling the Folio 100? Turns out this has nothing to do with Toshiba; but it's simply because of a high return rate from disappointed customers. In fact, head over to MoDaCo and you'll see a screenshot of PC World's internal memo that confirms this sad news. We had already given the tablet some decent (and disheartening) hands-on time back at IFA, but since our new friends at the store kindly offered to let us unbox a Folio 100 for a giggle, we decided to give it another go. And boy, it sure was a letdown: you'll see in our hands-on video after the break that the 10.1-inch LCD is haunted by an inferior pixel density plus narrow viewing angles; and the cheap plastic casing doesn't help, either. Most importantly, the official Android Market app was still MIA, which is no doubt the biggest turn-off for the buyers. Too bad, Toshiba, but do come back next year when you have Honeycomb and some decent screens. [Thanks, John L. and Adam C.]Gallery: Toshiba Folio 100 in-store unboxingContinue reading PC World stops selling the Toshiba Folio 100, we go hands-on to find out why (video)PC World stops selling the Toshiba Folio 100, we go hands-on to find out why (video) originally appeared on Engadget on Sun, 14 Nov 2010 16:33:00 EDT. Please see our terms for use of feeds.Permalink   |   | Email this | Comments

Market Housekeeping Alert

We’ve had quite a bit of discussion in this space recently about how to make sure that your app is visible in Android Market to any device that can run it, and only to those devices. In particular, check out two recent pieces by Reto Meier, Future-Proofing Your App and The Five Steps to Future Hardware Happiness.As Reto points out, Market used to infer some <uses-feature> settings for older apps that were uploaded before certain device features arrived. This hasn’t been the case for applications uploaded since June of this year; developers have had to be careful about <uses-feature> and its android:required attribute. From what we see, it looks like most of you have got this sorted out and things are working smoothly.However, there are still apps that haven’t been re-uploaded since June. In preparation for introducing some new Market features (that we think you’ll like), we’re about to launch a re-scan of all those legacy apps, looking at their Android Manifests and updating Market’s database. This means that if you have an app that you haven’t updated since June, and it lacks up-to-date <uses-feature> settings, it may stop being visible on certain devices.We think the set of apps that will have this problem will be small, if only since most successful apps are updated regularly. If you want to be sure, check Reto’s advice here under "Android Market Rule #2”. We’ve said it before but it bears repeating: There are a lot of different sizes and shapes and flavors of Android devices in the product pipeline, and you want your app available on every one that can possibly run it. So this is an area that is going to be requiring attention from developers on a continuing basis.

More Countries, More sellers, More buyers

[This post is by Eric Chu, Android Developer Ecosystem. â€" Tim Bray]Since we launched Android and Android Market, we have seen the population of Android users and devices expand into many countries. This widespread adoption has brought with it growing interest in Android Market’s support for the buying and selling of paid applications in these additional countries.We have been hard at work on this and it is my pleasure to announce that effective today, developers from 20 more countries can now sell paid apps on Android Market. Additionally, over the next 2 weeks, users in 18 additional countries will be able to purchase paid apps from Android Market.Support for paid application sales is now expanded to developers in 29 countries, with today’s additions of Argentina, Australia, Belgium, Brazil, Canada, Denmark, Finland, Hong Kong, Ireland, Israel, Mexico, New Zealand, Norway, Portugal, Russia, Singapore, South Korea, Sweden, Switzerland and Taiwan.In addition, Android Market users from 32 countries will be able to buy apps, with the addition of Argentina, Belgium, Brazil, Czech Republic, Denmark, Finland, Hong Kong, India, Ireland, Israel, Mexico, Norway, Poland, Portugal, Russia, Singapore, Sweden, and Taiwan. No action is necessary if you have targeted your paid apps to be available to “All Locations” and would like to launch in these additional countries. If you have not selected “All Locations” and would like to target these additional countries, or if you have selected “All Locations” and do not want to launch your apps in these additional buyer countries, please visit the Android Market publisher site regularly over the next two weeks to make the necessary adjustments as the new buyer countries launch.We remain committed to continuing to improve the buyer and seller experiences on Android Market. Among other initiatives, we look forward to bringing the Android Market paid apps ecosystem to even more countries in the coming months. Please stay tuned.

Licensing Service Technology Highlights

We’ve just announced the introduction of a licensing server for Android Market. This should address one of the concerns we’ve heard repeatedly from the Android developer community.The impact and intent, as outlined in the announcement, are straightforward. If you want to enable your app to use the licensing server, there’s no substitute for reading the authoritative documentation: Licensing Your Applications. Here are some technical highlights.This capability has been in the Android Market client app since 1.5, so you don’t have to be running the latest Android flavor to use it.It’s secure, based on a public/private key pair. Your requests to the server are signed with the public key and the responses from the server with the private key. There’s one key pair per publisher account.Your app doesn’t talk directly to the licensing server; it IPCs to the Android Market client, which in turn takes care of talking to the server.There’s a substantial tool-set that will ship with the SDK, the License Verification Library (LVL). It provides straightforward entry points for querying the server and handling results. Also, it includes modules that you can use to implement certain licensing policies that we expect to be popular.LVL is provided in source form as an Android Library project. It also comes with a testing framework.There’s a Web UI on the publisher-facing part of the Market’s Web site for key management; it includes setup for production and testing.Obviously, you can’t call out to the server when the device is off-network. In this situation you have to decide what to do; one option is to cache licensing status, and LVL includes prebuilt modules to support that.We think this is a major improvement over the copy-protection option we’ve offered up to this point, and look forward to feedback from developers.

Product Specs & SDK Add-ons for the New Motorola #Android Phones #androiddev

  It's a very busy and exciting week here at MOTODEV! We are at CTIA Enterprise and Applications in San Francisco, and Motorola has kicked off the event with announcements of five brand new Android-based mobile devices -- CITRUS, BRAVO, SPICE, FLIPSIDE, and DROID PRO -- as well as announcing that another, the FLIPOUT (already successfully selling in LATAM, China, and Europe) is coming to North America. These feature-rich smartphones expand the choice and variety available to our customers, and broaden the opportunities and markets for innovative applications from you. Here's a quick summary of these new products and where you can learn more about them: All of these devices offer tremendous developer opportunities, and we have the technical resources to support your app development. To learn about and compare each product's technical specifications, look here. SDK add-ons are coming soon for all these devices, and, if you are a member of our App Accelerator Program, some of the SDK add-ons are already available to you. Log-in to MOTODEV and go to http://developer.motorola.com/docstools/tools/ to download them. Not an App Accelerator Program member? Apply to join the program here. You'll get access to technical specs for some pre-release products as well as early versions of the SDK add-ons. App Accelerator Program members can also access real hardware today for these new products in the Virtual Developer Lab.  You also have to check out our Technical Library , where you'll find programming tips for some specific devices as well as great articles and samples to help you create beautiful apps that will run well on the widest variety of devices, whether they have a QVGA or FWVGA display, keyboard or touchscreen, portrait or landscape default orientation, etc.  Join us on our Android development discussion boards to us know how you like these new phones and to get advice as you develop the new applications they inspire.  Happy coding!  

Rough edges cut deep: Android still facing years-old unlock screen bug, Gmail 2.3 attachment woes have Google stumped

So, that new 2.3 version of Gmail that launched in September? Yeah, we'd steer clear if you haven't nabbed it yet. Google's currently trying to track down a bug that's leaving many users (including our own hapless Chris Ziegler) unable to download any attachments. Interestingly, or disconcertingly if you're of the pessimistic sort, Google actually has a "Gmail attachment issues investigation" page set up to allow highly technical users to submit debug reports of the problem. Sure, we're all for crowd sourcing, but we also wouldn't mind a big sturdy "hey guys, we've got this" on an issue of this magnitude. The worst part? You can't revert to the old version of Gmail if you've got the latest OTA update on your fancy new T-Mobile G2. Interestingly, while we were discussing this issue, ensconced in the Engadget HQ jacuzzi, adult beverages in hand, we got a tip from some poor soul detailing a bug that's been in Android since the G1 days. Basically, if you fail at the pattern unlock too many times, the phone will ask you to enter your Google account info to unlock your phone. Sounds like a smart security feature, but unfortunately it doesn't work. The insanely detailed thread on Google's Android bug tracker reads like a history of the Android platform and the futility of man rolled into one, with various workarounds being discovered for different phones, and many desperate users resorting to wiping their phones and starting over. Sure it's minimal in the grand scheme of things, and plenty of platforms have outstanding bugs years after release, but we figured a little *bump* couldn't do anyone any harm. This one's for you, Dylan R.Rough edges cut deep: Android still facing years-old unlock screen bug, Gmail 2.3 attachment woes have Google stumped originally appeared on Engadget on Tue, 09 Nov 2010 20:01:00 EDT. Please see our terms for use of feeds.Permalink   |  Attachments issue, Unlock issue  | Email this | Comments

Licensing Server News

It’s been reported that someone has figured out, and published, a way to hack some Android apps to bypass our new Android Market licensing server. We’ll be saying more on this, but there are a few points that deserve to be made right now:The licensing service, while very young, is a significant step forward in terms of protection over the plain copy-protection facility that used to be the norm. In the how-to-pirate piece, its author wrote: “For now, Google’s Licensing Service is still, in my opinion, the best option for copy protection.”The licensing service provides infrastructure that developers can use to write custom authentication checks for each of their applications. The first release shipped with the simplest, most transparent imaginable sample implementation, which was written to be easy to understand and modify, rather than security-focused. Some developers are using this sample as-is, which makes their applications easier to attack. The attacks we’ve seen so far are also all on applications that have neglected to obfuscate their code, a practice that we strongly recommend. We’ll be publishing detailed instructions for developers on how to do this.The number of apps that have migrated to the licensing server at this point in time is very small. It will grow, because the server is a step forward.100% piracy protection is never possible in any system that runs third-party code, but the licensing server, when correctly implemented and customized for your app, is designed to dramatically increase the cost and difficulty of pirating.The best attack on pirates is to make their work more difficult and expensive, while simultaneously making the legal path to products straightforward, easy, and fast. Piracy is a bad business to be in when the user has a choice between easily purchasing the app and visiting an untrustworthy, black-market site.Android Market is already a responsive, low-friction, safe way for developer to get their products to users. The licensing server makes it safer, and we will continue to improve it. The economics are already working for the developers and against the pirates, and are only going to tilt further in that direction.

Google Nexus S is the Samsung GT-i9020? (update)

We've already established that the Nexus S is almost certainly a Samsung -- but what else do we know about it? Well, a quick search for pictures taken with a Nexus S on Flickr and Picasa produced some 5 megapixel results, believe it or not, and some of those users' albums had been using a Samsung handset with model number GT-i9020 just a few days earlier. If we had to guess, a recent firmware update changed the EXIF identifier for these shots from the code to the actual retail name -- Nexus S, that is -- which explains the switchover. We've got both an FCC filing and a Wi-Fi Alliance certification for the i9020, and it's definitely a smartphone with 802.11 b / g / n (single-band, unfortunately) and AWS 3G, a radio choice that ties it in nicely with T-Mobile as the Best Buy leak would have us believe. Interestingly, a little digging reveals that all of these shots on photo sharing sites are coming from Google employees and families of Google employees -- and Sammy's i9000 series is closely tied to the Galaxy S line, which makes sense considering how much the Nexus S seems to look like a Galaxy S. Oh, and if that wasn't enough, the FCC label documentation for the i9020 lines up perfectly with the leaked picture. So yeah, it's all kind of coming together -- all we need now, Google, is an official Gingerbread and hardware announce. Let's do this thing. Update: It appears there are actually two very similar Nexus S candidates that passed the FCC: the GT-i9020, and the GT-i9020T. We're starting to think one of them might be destined for Europe, as it's labeled "EU" (the other is "TMB") though both appear to support AWS for 3G. In case you need any extra corroboration, Samsung specifically calls out the GT-i9020T as a Google Android handset with a 5 megapixel autofocus camera, Bluetooth, WiFi and dual-band 850/1900 GSM frequencies. [Thanks, Armo]Google Nexus S is the Samsung GT-i9020? (update) originally appeared on Engadget on Thu, 11 Nov 2010 13:56:00 EDT. Please see our terms for use of feeds.Permalink   |  Picasa (1), (2), FCC, Wi-Fi Alliance  | Email this | Comments

YouTube Remote app released, controls Leanback on GTV or PC from your Android phone

We weren't completely in love with Google TV's YouTube Leanback experience when we gave the platform a run through, but that could change now that the YouTube Remote app has been released to the Android Market. Users pair the devices simply by signing into YouTube Leanback on the TV or PC and the app on the phone with the same account, then select a video on the phone and send it to the bigger screen with a press of a button. At least, that's how it should work. TechCrunch got a hands on with the new app and a new Topics sorting system for the site during a demo and found some potential, however trying it on one of our devices elicited a slew of crashes before we eventually got everything synced up and working. QR code's after the break so you can have a go of your own. Update: Once we got everything rolling, we were able to get a better impression of the app. While it was a bit slow to open on our Galaxy S phone, once it is up, it worked smoothly, scrolling side to side through various queues of types of content and our favorites list. While the task of pulling up Leanback in a browser window or even on a Google TV device makes it ill-suited for viewing just one video at a time, where it excels is building a up a queue of videos and sending them over all at once. It will work on multiple screens at the same time as well, but there's no Airplay-style syncing to be had, if one of them starts to slow down or buffer it will simply continue lagging behind, and without any volume controls or ability to reach other functions, you'll still need to keep other remotes handy.Continue reading YouTube Remote app released, controls Leanback on GTV or PC from your Android phoneYouTube Remote app released, controls Leanback on GTV or PC from your Android phone originally appeared on Engadget on Tue, 09 Nov 2010 16:47:00 EDT. Please see our terms for use of feeds.Permalink TechCrunch, GTVHub  |  The Official YouTube Blog  | Email this | Comments

Android Market Action

Almost instantly after I joined Google, it became obvious to me that the number-one area where Android developers wanted to see action and progress was in Android Market; your concerns in this area vastly outweighed whatever issues might be bothering you about the handsets and the framework and the programming tools. In recent months there has been a steady, quiet, incremental flow of improvements and upgrades. They add up. This is by way of a glance back at developments since the arrival of Froyo last summer.First, we introduced error reporting to Market, so developers can see if their apps are locking up or crashing; and if so, exactly where.Second, we upgraded the Market publisher site to include user comments, so you can read what people are saying about you, or at least what they’re saying in a language you understand.Third, we added the licensing server, which, when used properly, tilts the economics of Android apps toward you, the developer, and against the pirates.Fourth, we cranked up the number of countries people can buy and sell apps in: as of now, you can sell them in 29 countries and buy them in 32.Fifth, we rolled in a “recent changes” feature, a place for developers to put their release notes. Android Market has a zero-friction process for app update, and the really great apps have followed the “release early, release often” philosophy. As a developer, I like having a place to write down what’s behind an app release, and as a person who downloads lots of apps, I like to know what the goodies are in each new update.Sixth, Market now has a “draft upload” feature; this removes a lot of the tension and strain from the app-update process. Get your screenshots and feature graphics and text and APK all squared away with as much editing as you need to, then update them all with one click.You’ll notice that I didn’t say “Sixth and last”, because this is a team on a roll and I expect lots more goodness from them; if you care about the larger Android ecosystem, or are already a developer, or are thinking of becoming one, stay tuned to this channel.

Sony Ericsson's Anzu / X12 to be Xperia Gingerbread flagship? (Update: more pics!)

We're not sure what Sony Ericsson's gotten to lately with its mythological codenames, but if Xperia X10 Blog's source is to be trusted, what we're looking at here is supposedly an upcoming handset codenamed "Anzu" (a lesser god of Akkadian mythology), or simply the X12 according to the often reliable Eldar Murtazin. Details are thin right now, but the leakster claims that said device is "very, very slim" yet packing a 4.3-inch display and HDMI output -- sounds very much like the Droid X, if you ask us. Although this particular photo shows an Android 2.1 build on the phone, rumor has it that it'll be shipped with Gingerbread (which is now pretty much officially 2.3) in Q1 next year. Here's another interesting bit of gossip to take with you: we've heard from a couple of reliable sources close to the matter that the Anzu lies in the same category as the PlayStation Phone "Zeus" (also on Gingerbread but lacking the Xperia branding), and that they're being tested alongside each other. Whether this is an indication that the mystical Z-System gaming platform is heading to the Anzu, we don't know, but it makes sense given that both upcoming SE devices appear to bear the same screen size, or at least the same aspect ratio. Either way, we're told the pair will be officially announced some time before or shortly after Christmas, which again supports Xperia X10 Blog's leak. Time to stock up on some fine champagne, folks -- looks like 2011 is going to be a good year. [Thanks to everyone who sent this in] Update: Well that was quick. Xperia X10 Blog's just posted a few more lovely pics of the Anzu, and boy it sure is thin -- check out the profile shot after the break. The site's also just heard that said phone can capture 1080p video and will have a front-facing camera. [Thanks, Tejstar]Continue reading Sony Ericsson's Anzu / X12 to be Xperia Gingerbread flagship? (Update: more pics!)Sony Ericsson's Anzu / X12 to be Xperia Gingerbread flagship? (Update: more pics!) originally appeared on Engadget on Wed, 10 Nov 2010 07:27:00 EDT. Please see our terms for use of feeds.Permalink   |  @eldarmurtazin (Twitter) (1), (2), X10 Blog, IT168 BBS  | Email this | Comments

Powering Chrome to Phone with Android Cloud to Device Messaging

[This post is by Dave Burke, who's an Engineering Manager 80% of the time. â€" Tim Bray]Android Cloud to Device Messaging (C2DM) was launched recently as part of Android 2.2. C2DM enables third-party developers to push lightweight data messages to the phone. C2DM created a nice opportunity for us to pull together different Google developer tools to create a simple but useful application to enable users to push links and other information from their desktop / laptop to their phone. The result was Chrome to Phone - a 20-percent time project at Google.Chrome to Phone comprises a Chrome Extension, an Android Application, and a Google AppEngine server. All of the code is open sourced and serves as a nice example of how to use C2DM.The message flow in Chrome to Phone is fairly typical of a push service:The Android Application registers with the C2DM service and gets a device registration ID for the user. It sends this registration ID along with the user's account name to the AppEngine server. The AppEngine server authenticates the user account and stores the mapping from account name to device registration ID. The Chrome Extension accesses the URL and page title for the current tab, and POSTs it to the AppEngine server. The AppEngine server authenticates the user and looks up the corresponding device registration ID for the user account name. It then HTTP POSTs the URL and title to Google's C2DM servers, which subsequently route the message to the device, resulting in an Intent broadcast.The Android application is woken by its Intent receiver. The Android application then routes the URL to the appropriate application via a new Intent (e.g. browser, dialer, or Google Maps).An interesting design choice in this application was to send the payload (URL and title) as part of the push message. A hash of the URL is used as a collapse_key to prevent multiple button presses resulting in duplicate intents. In principle the whole URL could have been used, but the hash is shorter and avoids unnecessarily exposing payload data. An alternative approach (and indeed the preferred one for larger payloads) is to use the push message service as a tickle to wake up the application, which would subsequently fetch the payload out-of-band, e.g. over HTTP.The code for Chrome to Phone is online. Both the AppEngine and Android Application include a reusable package called com.google.android.c2dm that handles the lower-level C2DM interactions (e.g. configuration, task queues for resilience, etc).Chrome to Phone is useful, but maybe it’s most interesting as an example of how to use Android C2DM.

Ensure your app reaches all Android consumers - learn how to support QVGA devices

  Did you know that Motorola has announced several QVGA-based mass market devices?  The Motorola CHARM and FLIPOUT, announced in the last few months, are bringing the Android experience to a new set of consumers. Unfortunately, based on settings in the Android app manifest, not all of the existing applications in Android Market are available to these devices. There are a few common reasons why your application may not show up in Android Market on CHARM or FLIPOUT: 1.  These are QVGA devices which means the <supports-screens> tag in the AndroidManifest.xml file must include smallScreens="true" for your application to appear in Android Market. 2.  The 3-megapixel camera has a fixed focus and no flash. If your application requests the CAMERA permission with <uses-permission android:name="CAMERA" />, you must also include a <uses-feature> tag with android.hardware.camera. Otherwise, Android assumes your application uses all camera features, including autofocus and flash and will filter your application from these devices. Once you ensure that your app is visible in Android Market, you’ll want to make sure your application displays correctly on a smaller, lower density screen and works on devices on which the primary orientation is landscape rather than portrait.  The following resources are available on MOTODEV to help you address all of these issues: CHARM: Technical specs CHARM Programming Tips - Important tips on how to handle small displays, landscape orientation, the BACKTRACK rear touchpad, and more. SDK add-on - Software image, skin, and hardware configuration for all MOTODEV members. Real hardware in the MOTODEV VDL at DeviceAnywhere for all MOTODEV members  FLIPOUT: Technical specs FLIPOUT Programming Tips - Important tips on how to handle small displays, landscape orientation, and more. SDK add-on - Skin and hardware configuration for all MOTODEV members. The version for AAP members also includes a software image for handset emulation. Real hardware in the MOTODEV VDL at DeviceAnywhere for all MOTODEV members. If your application has international appeal,  we also encourage you to submit it to SHOP4APPS, Motorola’s application storefront in China, Brazil, Mexico, and Argentina. We have a community of experts ready to help you should you experience in any difficulties in optimizing your application for these devices.  Head on over to our discussion boards and ask your fellow developers and our MOTODEV experts your questions. If you are not already a member of our App Accelerator Program, we encourage you to join. Membership is free and will get you access to advance information on unannounced products and technical resources such as SDK add-ons and access to devices at DeviceAnywhere for remote testing ahead of the product ship date. Happy Coding!Lori Fraleigh Developer Platforms, Tools, and Technical Services

Billboard Mobile Entertainment LIVE 2010

Hey devs,    Yesterday I attended Billboard Mobile Entertainment LIVE sponsored by MOTODEV. Christy Wyatt, Corporate Vice President Software Platforms and Ecosystems at Motorola,  gave a keynote about Motorola's strategy around Android and how we see the internet and its use on mobile devices evolving very rapidly. Wyatt says, "There will be more mobile internet users than there will be desktop users in the near future." Motorola keeps this in mind, and thinks of mobile devices as being at the center of their gravity for users when developing different mobile experiences. Wyatt also said that today's "out-of-the-box music experience is boring." She mentioned that connected media player 1.0 interacts with the users by pushing recommendations of artists and songs to the home screen and it promotes music experiences in  a social way.    Another keynote speaker, Matt Murphy from Kleiner Perkins Caufield and Byers gave some good advice for developers just starting out in the mobile space. He said, "Some apps are too complex. Start out simple and then get more complex if you need to. Many mobile users are still trying to figure out mobile apps, so if you start out too complex you can lose users right away." Murphy was also asked if music is doing a good job in the mobile app space. Murphy replied by saying, "Yes, companies like Tapulous and Smule are doing a great job. More and more companies are partnering with labels to bring better experiences, and I believe this is a very good model because money can often constrain the music ecosystem." One of Murphy's last pieces of advice was, "don't try to do too many platforms. Stick to one, do it really well and then move on to other platforms."    One of the most impressive demonstrations of a music app yesterday was when Dr. Ge Wang took the stage. Dr. Ge Wang is Co-Founder, CTO and Chief Creative Officer of Smule, his company is responsible for creating apps like, "I am T-Pain," "Leaf Trombone," "Magic Piano," and "Glee." Wang and his company spend time researching at Stanford University's Center for Computer Research in Music and Acoustics, where they have come up with many ideas for their apps. Smule has been able to make music in the mobile space interactive and social. Dr. Wang gave advice similar to Matt Murphy. Wang said, "Develop your app really really well on one platform, and then move on to other platforms. It's much easier to measure the success of your app that way."    Companies and labels are doing very interesting and innovative things in the mobile space these days. Have you developed a music app, or do you have plans for developing a music app? Let us know in the comments below or tweet us on Twitter @motodev.    -Nicole McMorran 

Samsung Continuum first hands-on (update: video!)

If surprise was the focus of the event, we'd say the Samsung Android-powered, Verizon-exclusive (and, alas, Bing-driven) Continuum reveal was a comedy of errors -- but who cares now that we've got our hands on the Galaxy S phone, secondary ticker and all (at 480 x 96 resolution). The Android buttons themselves, as it turns out, are on the display as well -- basically, it's one huge display. The grip sensor that activates the display seems to work well, although it's pretty easy to squeeze the camera button by accident since it's also on the lower right of the phone. Unfortunately, there's no way for third-party apps to update the ticker -- it's limited to Samsung's stuff right now. We're trying to get some battery life info -- we're curious if turning on a smaller screen more often will result in a longer shelf life, or if it'll just be about even. Update: Video after the break! Update 2: Okay, we got some more info on that screen. The entire front of the phone is one huge four-inch screen, with the Android buttons more or less painted over the lower third -- the screen lights up underneath them in white to illuminate them. Samsung says it's just easier for marketing purposes to say it's two screens, but that they're selectively turning on the bottom portion of the display for the ticker. As far as battery life, it's a 1500mah battery that'll last about a day, we're told -- the lower screen turns on whenever a notification comes in, but since it's a smaller screen the battery life is on par with the Fascinate. We also learned the "grip sensor" isn't really grip-based at all -- it's capacitive, so just lightly touching both sides of the phone lights up the ticker. It's pretty nice, although super easy to set it off by just holding the phone. Samsung says there will eventually be an API for third-party apps to use the ticker, but right now they're just focused on their core experiences. As for Bing, well, no one's saying why some Verizon phones get Binged out and some don't, but every indication is that Verizon calls those shots, not Samsung. We're also told that an Android 2.2 update will eventually arrive, but there's no timeline yet -- and there's a real chance this'll launch with 2.1 after 2.3 hits. Developing... Update 3: Added a quick macro pic of the buttons after the break -- you can see how it's just one big screen. We also took some side-by-sides with a Captivate -- the Continuum is thicker and narrower. Samsung says the narrower size is designed to appeal to women, who generally have smaller hands. Gallery: Samsung Continuum hands-onContinue reading Samsung Continuum first hands-on (update: video!)Samsung Continuum first hands-on (update: video!) originally appeared on Engadget on Mon, 08 Nov 2010 18:48:00 EDT. Please see our terms for use of feeds.Permalink   |   | Email this | Comments

Supporting the new music Voice Action

[This post is by Mike LeBeau, the Tech Lead and architect behind Voice Actions. â€" Tim Bray]We recently launched Voice Actions in the new Google Voice Search for Android — an awesome new way to search, control, and communicate on your phone faster than ever before, by using your voice.One of these new Voice Actions lets users find and automatically play music. By speaking something like “listen to They Might Be Giants” into the new Voice Search, users can quickly find the music they want online and play it, using any number of different apps. (Pandora, Last.fm, Spotify, mSpot, and Rdio are among the first apps to support this.)To do this, we leveraged a very common little piece of Android magic: a new Intent. If you develop a music app that supports open-ended music search, you can make it work with users speaking “listen to” Voice Actions simply by registering for the new intent we’ve defined. This new intent isn’t defined as a constant in the SDK yet, but we wanted to make sure music app developers had all the information needed to use it right away.Here’s all you should need to know:In your AndroidManifest.xml, just register one of your activities for the new intent android.media.action.MEDIA_PLAY_FROM_SEARCH:<application android:label="@string/app_name" android:icon="@drawable/icon"> <activity android:name="MusicActivity" android:label="@string/app_name"> <intent-filter> <action android:name="android.media.action.MEDIA_PLAY_FROM_SEARCH" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> </activity> </application>When your activity receives this intent, you can find the user’s search query inside the SearchManager.QUERY string extra:import android.app.Activity; import android.app.SearchManager; public class MusicActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); String query = getIntent().getStringExtra(SearchManager.QUERY); // Do something with query... } }This will represent everything the user spoke after “listen to”. This is totally open-ended voice recognition, and it expects very flexible search — so, for example, the string could be the name of any artist (“they might be giants”), an album (“factory showroom”), a song (“metal detector”), or a combination of any of these (“metal detector by they might be giants”).A few subtle details worth understanding about this intent:Your app should do its best to quickly find and automatically play music corresponding to the user’s search query. The intention here is to get users to their desired result as fast as possible, and in this case, that means playing music quickly.This will really only work well for music apps that can find music across a very large corpus of options. Because our voice recognition doesn’t currently support any way to provide a list of specific songs to be recognized, trying to use it against a small set of music choices will work poorly — things which are not in the set will be over-recognized, and things which are in the set may not be recognized well. So if you’re not the developer of a large-scale cloud music application, this intent is probably not for you.We think you’ll find this new intent can greatly enhance your music app’s experience for users. And we hope you enjoy our new Voice Actions as much as we do!

The Five Steps to Future Hardware Happiness

[This post is by Reto Meier AKA @retomeier, who wrote the book on Android App development. â€"Tim Bray]Two questions I regularly get asked are “Why isn’t my app visible on the Market on the (insert device name here)?” and “How can I prepare for GoogleTV and Android tablets?” If you care about how broadly your app is available, pay attention now. Seriously. I don’t want to hear anyone telling me they weren’t told. [Seems a little combative? -Ed. Take it up a notch! -RM]By now you’ve probably heard of Google TV, the Samsung Galaxy Tab, and the Dell Streak. These are only the vanguard — Android is quickly moving to hardware that is increasingly different from the smartphone devices we’re used to. The variations in hardware — including lack of features like GPS, accelerometers, and video cameras — means it’s time for you to think about what hardware your app needs, and what it can function without.To make life easier every API includes a FEATURE_* constant. To control your app’s availability on the Android Market, you specify the features required for your app to work. I’d like to encourage you to add manifest Feature nodes for every API you use, specifying them as optional, or not, as appropriate using a manifest uses-feature nodes as shown below:<uses-feature android:name="android.hardware.microphone" android:required="true"/>Market won’t be inferring any future API featuresMy earlier post on future proofing your apps describes a process of feature inferring that used your app’s permissions to help us ensure apps were only visible on the appropriate hardware.This process has evolved over time. From now on Market won’t be inferring future API features and we have no way to infer some previously available APIs (eg. sensors). As a result you’ll need to specify your mandatory and optional feature requirements — or risk your app either breaking or not being available for some users.The 5 steps to future hardware happinessSpecify a uses-feature node for every API feature used by your app. This forces you to think about what your app uses, allowing you to:Decide which features are necessary for your app to be useful and mark those featured with the attribute required=true. This lets Market hide your app from any device that doesn’t support the hardware features your app requires.<uses-feature android:name="android.hardware.telephony"              android:required="true"/>For features that aren’t strictly required, set required=false.<uses-feature android:name="android.hardware.bluetooth"              android:required="false"/>Then go in to your code and find where you have used the optional features. Use the hasSystemFeature method from the PackageManager to determine if the hardware is available and provide alternative paths for your code as appropriate.PackageManager pm = getPackageManager();boolean hasCompass = pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS);Now you can sleep soundly in the knowledge that no matter what variation in Android compatible hardware comes to market, your app will always (and only) be available on those it supports.You can find more details on how the Android Market uses filters to determine whether to show your application to a user who is browsing or searching for applications on a given device at the Market Filters page on the Android Developer Site.

Brace for the Future

[This post is by Dan Morrill, Open Source & Compatibility Program Manager. â€" Tim Bray]Way back in November 2007 when Google announced Android, Andy Rubin said “We hope thousands of different phones will be powered by Android.” But now, Android’s growing beyond phones to new kinds of devices. (For instance, you might have read about the new 7” Galaxy Tab that our partners at Samsung just announced.) So, I wanted to point out a few interesting new gadgets that are coming soon running the latest versions of Android, 2.1 and 2.2.For starters, the first Android-based non-phone handheld devices will be shipping over the next few months. Some people call these Mobile Internet Devices or Personal Media Players — MIDs or PMPs. Except for the phone part, PMP/MID devices look and work just like smartphones, but if your app really does require phone hardware to work correctly, you can follow some simple steps to make sure your app only appears on phones.Next up are tablets. Besides the Samsung Galaxy Tab I mentioned, the Dell Streak is now on sale, which has a 5” screen and blurs the line between a phone and a tablet. Of course, Android has supported screens of any size since version 1.6, but these are the first large-screen devices to actually ship with Android Market. A tablet’s biggest quirk, of course, is its larger screen.It’s pretty rare that we see problems with existing apps running on large-screen devices, but at the same time many apps would benefit from making better use of the additional screen space. For instance, an email app might be improved by changing its UI from a list-oriented layout to a two-pane view. Fortunately, Android and the SDK make it easy to support multiple screen sizes in your app, so you can read up on our documentation and make sure your app makes the best use of the extra space on large screens.Speaking of screen quirks, we’re also seeing the first devices whose natural screen orientation is landscape. For instance, Motorola’s CHARM and FLIPOUT phones have screens which are wider than they are tall, when used in the natural orientation. The majority of apps won’t even notice the difference, but if your app uses sensors like accelerometer or compass, you might need to double-check your code.Now, the devices I’ve mentioned so far still have the same hardware that Android phones have, like compass and accelerometer sensors, cameras, and so on. However, there are also devices coming that will omit some of this hardware. For instance, you’ve probably heard of Google TV, which will get Android Market in 2011. Since Google TV is, you know, a stationary object, it won’t have a compass and accelerometer. It also won’t have a standard camera, since we decided there wasn’t a big audience for pictures of the dust bunnies behind your TV.Fortunately, you can use our built-in tools to handle these cases and control which devices your app appears to in Android Market. Android lets you provide versions of your UI optimized for various screen configurations, and each device will pick the one that runs best. Meanwhile, Android Market will make sure your apps only appear to devices that can run them, by matching those features you list as required (via tags) only with devices that have those features.Android started on phones, but we’re growing to fit new kinds of devices. Now your Android app can run on almost anything, and the potential size of your audience is growing fast. But to fully unlock this additional reach, you should double-check your app and tweak it if you need to, so that it puts its best foot forward. Watch this blog over the next few weeks, as we post a series of detailed “tips and tricks” articles on how to get the most out of the new gadgets.It’s official folks: we’re living in the future! Happy coding.

Reflections on G-Kenya

[This post is by Reto Meier AKA @retomeier, who wrote the book on Android App development. â€" Tim Bray]Recently I visited Kenya for the three-day G-Kenya event. I was there for two reasons:To talk about Android and the emerging mobile opportunities for African developers.To ask questions and find out more about the reality of mobiles and writing code from the people there.Of the countries I’ve visited to talk about Android, nowhere have people had such a close connection to their mobile phones as in Africa. While most Kenyans own feature phones, those mobiles are already used as much more than simple phones. Mobile payments are already common, and cheap data plans mean that many people access the Internet exclusively through mobile handsets.There were two Android announcements while I was in town: a new low-cost Android handset (the Huawei U8220), and Android Market access for Kenyans. I can’t wait to see the kind of apps that come from developers who live in an environment where mobile is so pervasive.Day 1: StudentsG-Kenya was set within the beautiful campus of the Strathmore Business School, so it was fitting that day one was addressed to students.Of the three groups, the students where the most enthusiastic about Android. This was likely influenced by their confidence that by the time they graduate, modern smartphones in Africa will have become the norm.I love talking to student developers — without the commercial pressures of finding customers or a monetization model — they're free to innovate on whatever technology platforms they think are interesting.Day 2: DevelopersModern smartphones are not yet prevalent in Africa, so it wasn’t surprising that many of the developers are currently focusing on feature phones. That said, it was generally acknowledged that it was a question of when rather than if smartphones would come to dominate. The trick will be picking the right time to invest in Android so that they're ready to take advantage.Plenty of developers believe that time is right now. It was a pleasure to meet the guys behind Ushahidi, creators of an Android app created to report and record incidents during the 2008 election violence. Since their launch they’ve expanded to offer a global platform for crowd-sourced news where timeliness is critical.I love opportunity the Android Market delivers to developers like the idea of developers like Ushahidi and Little Fluffy Toys (of London Cycle Hire fame). An app the solves a problem for your local community can easily be expanded to offer solutions to similar problems across the world.Developer focus in Kenya seemed to follow similar lines:Create products and services targeted at local communities (such as the developers creating a distributed system to help health-care workers record medical information in the field.)Build robust cloud-based services that provide access to users from any mobile platform.Expand from feature phones to Android to incorporate features like GPS positioning, maps, and recording video and audio.Day 3: Entrepreneurs and MarketersNo one was surprised to see a lot of the developers from the previous day return for entrepreneur day, and the apparent lack of Android questions from Day 2 was more than made up for on day 3; the “AppEngine Challenge” on Day 2 fielded a record 30 entries, so it seems everyone was working on their entries rather than asking questions!I didn’t speak on Day 3, but spent all day fielding questions from eager mobile developers hoping to catch the Android wave as early innovators and first movers. That included a team who were working to provide real-time public transit tracking of Matatu via GPS and Android devices.ReflectionsIt’s an exciting time to be a developer in Kenya. I regularly asked developers how long they thought it would take for Android devices to become common place. Many suggested if I came back this time next year I'd see a flood of Android devices. Even the more pessimistic predicted no more than 3 years.As I traveled back towards Jomo Kenyatta International, listening to the radio offering a free Sony Ericsson X10 Mini to one lucky caller, the future didn’t seem very far away.

Develop Android Apps for the New Motorola Android Phones in China

Hi,   I’m Jinnan Sun, product manager within MOTODEV - Motorola's ecosystem organization. My day to day role is focused on delivering SDK add-ons for Motorola Android devices. I also help drive the growth of the Android ecosystem in China and the greater Chicago area. Today, I will talk about about four new Androidâ„¢ smartphones we just launched for the China market, along with the resources available on MOTODEV that will help you develop apps that deliver compelling user experiences on these Motorola devices.     Three of these four new smart phones are from the successful and iconic MINGâ„¢ series designed for China. The phones combine a superior Android touchscreen experience with updated MING styling and features, and include the A1680 for China Unicom's WCDMA network, the MT810 for China Mobile's TD-SCDMA network, and the XT806 for China Telecom's CDMA-2000 network.      A1680: Iconic MING Redefined for China Unicom   A1680 brings Android together with a design that reflects the classic and elegant MING heritage. A 3.1-inch AMOLED touchscreen offers a crystal clear display and excellent touch capabilities. A1680 supports China Unicom's WCDMA network, as well as WAPI and WIFI(1) high-speed connectivity for easy access to the mobile Internet. Motorola's acclaimed intelligent handwriting recognition software has been perfected for the A1680 while a sixth-generation SoftStylusâ„¢ handwriting system easily captures your personal penmanship style. The A1680 also has a 5MP camera and GPS navigation services. You can access Motorola's application storefront SHOP4APPS on the A1680. For the complete A1680 spec, please visit http://developer.motorola.com/products/a1680.   For the A1680 SDK add-on, please visit http://developer.motorola.com/docstools/tools     MT810: Social Meets Business for China Mobile   MT810 has been jointly launched with China Mobile, the world's largest mobile telephone operator by subscribers, and uses China Mobile's OPhone OS 2.0â„¢ implementation of Android. The MT810 has a unique dual-touch system in which the 3.2-inch display is a resistive touchscreen perfect for stylus or finger input and the transparent cover is a second capacitive touchscreen that offers full finger touch functionality even when the phone is closed. A suite of pre-loaded intelligent business applications enables you to stay successful on the go while D1 (720 x 480) video capture, 720p HD video playback and powerful audio-video functionality, including support for China's CMMB mobile television format, offer an unparalleled mobile entertainment experience. Access China Mobile's Mobile Market to download applications. For the complete XT810 specification, please visit  http://developer.motorola.com/products/mt810   XT806: An Internet Powerhouse for China Telecom   XT806 is an Internet-connected powerhouse built on Android 2.1 and offered by Motorola and China Telecom. Easy connectivity and dual-mode/dual-standby support for CDMA EVDO and GSM enable seamless roaming so you can receive information around the world. XT806 also provides integrated mobile business application tools such as Quicknotesâ„¢, and innovative application that allows you to easily work on text, voice recording, videos, pictures, sketches and screen snapshots. With these features, the XT806 becomes a multimedia notebook that can help you search and work at any critical moment. It also has a transparent flip design and a 3.2-inch screen with a super-sharp 300dpi display, powerful GPS navigation services and 720p HD video capture and playback. Access Motorola's application storefront SHOP4APPS to download many applications. For the complete XT806 specification, please visit  http://developer.motorola.com/products/xt806   XT502(QUENCH XT 5)     XT502 is an affordable Androidâ„¢-powered touch tablet with a 5-megapixel camera and flash. It  features a large 3.2-inch HVGA display and capacitive touch screen. With high-speed internet via 3G/WAPI/WiFi, a full web browser. XT502 gives you the tools you need to manage your busy life and have fun doing it.  You can access Motorola Android application storefront SHOP4APPS from XT502. For the complete specs of XT502, please visit  http://developer.motorola.com/products/quenchxt5/     Other resources    For developing Andorid apps for our China users, you may also want to visit the following links -   ● Develop map-based applications using AutoNavi map APIs   ● Chinese PinYin IME tips   ● Submit your apps to our SHOP4APPS storefront   Thanks, Jinnan     

Proguard, Android, and the Licensing Server

[This post is by Dan Galpin, an Android Developer Advocate specializing in games and comics. â€" Tim Bray]The Securing Android LVL Applications blog post makes it clear that an Android developer should use an obfuscation tool such as Proguard in order to help safeguard their applications when using License Server. Of course, this does present another question. How should one integrate such a tool with the Android build process? We’re specifically going to detail integrating Proguard in this post.Before you BeginYou must be running the latest version of the Android SDK Tools (at least v7). The new Ant build rules file included with v7 contains hooks to support user-created pre and post compile steps in order to make it easier to integrate tools such as Proguard into an Android build. It also integrates a single rules file for building against all versions of the Android SDK.Adding an Optimization Step to build.xmlFirst, you’ll have to get Proguard if you don’t yet have it.If you’ve been using Eclipse to do your development, you’ll have to switch to using the command line. Android builds are done using Apache Ant. A version of Ant ships along with Eclipse, but I recommend installing your own version.The Android SDK can build you a starter build.xml file. Here is how it’s done:android update project --path ./MyAndroidAppProjectIf all works well, you’ll have a shiny new build.xml file sitting in your path. Let’s try doing a build.ant releaseYou should end up with an unsigned release build. The command-line tools can also sign your build for you. You’ll notice that the android tool created a local.properties file in your directory. It will contain the sdk.dir property. You can have it make you a signed build by adding the location of your keystore and alias to this file.key.store=/Path/to/my/keystore/MyKeystore.ks key.alias=myaliasSo, now you have a signed build from the command line, but still no obfuscated build. To make things easy, you’re going to want to get two helper files: add-proguard-release.xml and procfg.txt.Copy these files into your root directory (where the build.xml file sits). To add Proguard to your build, you first need to edit your local properties file to add the location of the directory that Proguard is installed in:proguard.dir=/Directory/Proguard/Is/Installed/InFinally... you need to add our script to your build file and have it override a few targets. To do this, we use the XML “entity” construct. At the top of your build.xml file, add an entity that references our script file:<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE project [ <!ENTITY add-proguard-release SYSTEM "add-proguard-release.xml"> ]>You’re not done yet. Somewhere within the project tag add the reference to our entity to include our script.<project name="MyProjectName" default="help"> &add-proguard-release;That’s it! In many cases, callingant releaseWill give you an obfuscated build. Now test and make sure that it hasn’t broken anything.But Wait, My App is Crashing NowMost crashes happen because Proguard has obfuscated away something that your application needs, such as a class that is referenced in the AndroidManifest or within a layout, or perhaps something called from JNI or reflection. The Proguard configuration provided here tries to avoid obfuscating most of these cases, but it’s still possible that in edge cases you’ll end up seeing something like a ClassNotFoundException.You can make edits to the procfg.txt file to keep classes that have been obfuscated away. Adding: -keep public class * [my classname]should help. For more information about how to prevent Proguard from obfuscating specific things, see the Proguard manual. Specifically, the keep section. In the interest of security, try to keep as little of your application unobfuscated as possible.The standard settings provided in procfg.txt will be good for many applications, and will catch many common cases, but they are by no means comprehensive. One of the things that we’ve done is had Proguard create a bunch of output files in the obf directory to help you debug these problems.The mapping.txt file explains how your classes have been obfuscated. You’ll want to make sure to keep this around once you have submitted your build to Market, as you’ll need this to decipher your stack traces.ConclusionTools such as Proguard make the binary of your application harder to understand, and make your application slightly smaller and more efficient at the same time, at the cost of making it slightly more challenging to debug problems in the field. For many applications, the tradeoff is more than worthwhile.

Best Practices for Handling Android User Data

[This post is by Nick Kralevich, an engineer on the Android Security Team. â€" Tim Bray]As the use of mobile applications grows, people are paying more attention to how these applications use their data. While the Android platform contains extensive permissions designed to protect users, application developers are ultimately responsible for how they handle users’ information. It’s important for developers to understand the code they include, and consider the permissions they request, as mishandling these issues can result in users perceiving a violation of trust.Maintaining a healthy and trustworthy ecosystem is in every Android developer’s best interest.Here are a few tips for writing trustworthy Android applications:Maintain a privacy policyMinimize permissionsGive your users a choice regarding data collectionDon’t collect unnecessary informationDon’t send data off the device... but if you have to, use encryption and data minimization Don’t use code you don’t understandDon’t log device or user specific information.Maintain a privacy policyTrustworthy applications are up-front about the data they collect and the reasons for collecting it. Users are generally happy to share information via such apps if they believe they will personally benefit. A clear and concise privacy policy, with details about the type of information collected and how it’s used, goes a long way towards generating trust and good will.Minimize permissionsAndroid is unique among mobile operating systems for its simple, straightforward, operating-system-enforced permission model. All Android applications must declare the permissions they require, and users must approve these permissions before the application is installed. Users tend to distrust applications that require excessive permissions.For example, a user installing this tic-tac-toe game might reasonably wonder why it needs to take pictures.Give your users a choice regarding data collectionIt’s called the paradox of privacy [PDF, 890K]. Users are often happy to share their information, but they want control over that sharing. Trustworthy applications give users control over their information. For example, the Android Browser has privacy settings which enable users to control how their information is shared.Don’t collect unnecessary informationTrustworthy applications limit the kinds of data they collect. Collecting unnecessary information, especially if you never use it, just invites suspicion. When in doubt, don’t collect it.Don’t send data off the deviceIf you have to handle user data, ensure that the data remains on the device whenever possible. Users are comforted knowing that their private information strictly resides in the phone. Sending data outside the phone, even if done for the user’s benefit, tends to draw suspicion.... but if you have to, use encryption and data minimizationSometimes, the collection of data is necessary. In that case, applications need to ensure that it is handled safely. A privacy policy will avoid leading to surprised and irritated users; in some cases, it may be advisable to prompt the user before transmitting data off-device.First, minimize the amount of data you collect. Do you really need the user’s full phone number, or would the area code be sufficient? Can you use a one-way cryptographic hash function on the data before sending it to the server to help protect the user’s confidential information?A case study: User FavoritesSuppose you want your app to maintain a list of “favorites” for each of your users, without going through a full registration process. In theory, you could do this by sending your server some combination of their phone number, device ID, or SIM ID. But why take the chance of worrying people about privacy issues; why not send a one-way hashed signature of whatever the identifying information is? Or even better, create a random unique id and store it on the phone, and use this unique id as the registration key for your application.In the end, you’ll will still be able to retrieve their favorites, but you won’t need to send or store anything sensitive.Second, encryption is critical to the safe handling of user data. Phones often operate on untrusted networks where attackers can sniff confidential traffic. Encrypting data in transit is a critical part of protecting user information.Finally, when communicating with a server over HTTP, it’s a good idea to avoid encoding user information in a URL that is used with HTTP GET; rather, POST it in a message body. While using POST doesn’t guarantee that your information won’t be sniffed, putting it in the URL increases the likelihood that it will be automatically logged; out of the box, most web server software logs all the URLs that are received.Don’t use code you don’t understandIn the open-source Android environment, it’s common (and good) practice to rely heavily on other people’s code, in the form of libraries and frameworks. But if that code is handling your users’ information inappropriately, it’s your problem. So make a point of checking code before you rely on it.Don’t log user or device specific informationApplication developers should be careful about on-device logs. Android makes it easy to write to the phone’s log, and anyone who has looked at “logcat” output knows that it is full of important but seemingly random debugging information from many applications. In Android, logs are a shared resource, and are available to an application with the READ_LOGS permission (only with user consent, of course!). Even though the phone log data is temporary and erased on reboot, inappropriate logging of user information could inadvertently leak user data to other applications.

Screen Geometry Fun

The recent announcement of the Samsung Galaxy Tab should be a wake-up call for Android developers. What’s scary is that we’ve never seen a screen like this on an Android device before. What’s reassuring is that most apps Just Work (in fact, a lot of the ones I’ve tried so far have looked terrific) and the potential problems are easy to avoid. Here’s what you need to do to take advantage of not just the Tab, but all the new form factors that are coming down the pipe.Let’s consider the Tab as a “teachable moment”:Its screen is 1024x600; no compatible device’s screen has ever had a thousand pixels in any dimension before.A lot of people are going to want to hold it sideways, in “landscape” mode, most of the time.We recommend spending quality time with the Developers’-guide discussion of supporting multiple screens; we'll be revising that regularly when required as the device landscape changes. Also, this blog recently ran Dan Morrill’s One Screen Turn Deserves Another, which should help out in handling the landscape default.What density meansWhen you build your app, you can provide layouts and assets (graphics) which vary by screen density, screen size, and landscape or portrait orientation. Clearly, pulling these together is not as much fun as designing groovy layouts and clever Intent filters; but there’s no way around it.In this context, the Samsung has another little surprise: If you do the arithmetic, its screen has 170 DPI, which is far from the densest among Android devices. Still, it declares itself as “hdpi” (and as having a “large” screen size). The reason is simple: It looks better that way.Samsung found that if you rendered your graphical resources bit-for-bit using medium-density sources, they looked great, but most large-screen designs ended up looking sparse, with too much space between buttons and icons. At high resolution, the framework scales up the resources an amount that turns out to be just enough.As a photography hobbyist, I’m reminded of how you juggle aperture and shutter speed and ISO sensitivity. If, for example, you want a fast shutter speed to capture a dancer in mid-leap, you’d better compensate with a wider aperture or more sensitivity. Similarly, the Galaxy Tab’s screen is at the large end of “large”, so declaring it as high-density applies a useful compensation.The good news is that the scaling code in the framework is smart enough and fast enough that it comes out well; the graphics in my own apps look remarkably good on the Tab. Here is the front page of my “LifeSaver 2” app; first the Nexus One, then the Galaxy Tab, resized for presentation here. Different densities, different geometries, and the only important difference is that the version on the big screen looks prettier.Your take-away should be what I said above: Make sure you provide your graphics at all three resolutions, and chances are the Android framework will find a way to make them look great on a huge variety of devices.Other Ways To Go WrongAs I noted, most apps work just fine on this kind of device, out of the box, no changes required. However, we have run across a few Worst Practices that can make your app look dorky or even broken; for example:Using AbsoluteLayout; this is a recipe for trouble.Using absolute rather than density-independent pixels.One member of my group ran across a couple of apps that suffered a Null Pointer Exception because they were calculating screen size when their Activity started, and doing their own resource loading rather than letting the framework take care of it. The problem was that they hadn't built in handling for the 1024x600 screen. The problem would vanish if they'd hand the work to the framework (or at least make sure that all their switch statements had default cases).Escape the ShoeboxI've observed that a certain number of applications appear “shoeboxed”, running in a handset-like number of pixels in the center of the screen, surrounded by a wide black band. They work fine, but this is silly, and easy to avoid. It turns out that this happens when you have a targetSdkVersion value less than four; this is interpreted to mean that you’re targeting the legacy Cupcake flavor of Android, which only supported HVGA.In any case, if you want to make 100% sure that your app doesn’t get pushed into the shoebox, the supports-screens element is your friend; here’s what we recommend:<supports-screens android:largeScreens="true" android:anyDensity="true" />(Both those attributes default to "false" for API levels less than 4.) Given a chance, the framework gets a good result on almost any Android screen imaginable.TestingWhen a device comes along that’s different in one way or another from what’s been available before, and you don’t have one, the only way to be sure your app will treat it properly is to run it on an Android emulator; the emulator code is flexible enough to model anything we’ve seen or know is coming down the pipe.In the case of the Galaxy Tab, Samsung will be providing an add-on including a custom AVD and skin as an SDK add-on, to make your life easier; I used a pre-release to make the LifeSaver screenshot above.Why All the Extra Work?Because, as 2010 winds down, Android isn’t just for phones, and isn’t just for things that fit in your pocket. The minor effort required to deal with this should pay off big-time in terms of giving your apps access to a universe of new kinds of devices.

Traceview War Story

I recently took my first serious look at Traceview, and it occurred to me, first, that there are probably a few other Android developers who haven’t used it and, second, that this is an opportunity to lecture sternly on one of my favorite subjects: performance improvement and profiling. This is perhaps a little bit Android-101; If you already know all about Traceview, you can stop here and go back to coding.Making Apps FastHere’s a belief that I think I share with most experienced developers: For any app that is even moderately complex, you’re not smart enough to predict what the slow parts are going to be, because nobody is smart enough to predict where software bottlenecks will turn up.So the smart way to write a fast app is to build it in the simplest way that could possibly work, avoiding egregiously-stupid thing like order-N-squared algorithms and doing I/O on the Android UI thread. Who knows, it might be fast enough, and then you’re done!If it isn’t fast enough, don’t guess why. Measure it and find out, using a profiler. Actually I’ve been known to do this, when backed into a corner, using things like System.err.println("Entered at" + System.currentTimeMillis()); Fortunately, Android comes with a reasonably decent profiler, so you don’t have to get ugly like that.Case Study: LifeSaver 2I have this little utility in Android Market called LifeSaver 2, the details are on my personal blog. At one point, it reads the SMS and phone-call logs out of the system and persists them in a JSON text file on the SD card. Since this is kind of slow, it shows a nice dynamic progress bar. It occurred to me to wonder why it was kind of slow to write a few hundred records into a text file on a device that, after all, has a gigahertz processor.Somebody who foolishly disregarded my advice above might assume that the slowdown had to be due to the ContentProvider Cursor machinery reading the system logs, or failing that, the overhead of writing to the SD card. A wiser person would instrument the code and find out. Let’s do that.Turning On TracingI went into Saver.java and bracketed the code in its run() method like so: public void run() { android.os.Debug.startMethodTracing("lsd"); // ... method body elided android.os.Debug.stopMethodTracing(); }The first call turns tracing on, the argument "lsd" (stands for Life Saver Debug, of course) tells the system to put the trace log in /sdcard/lsd.trace. Remember that doing this means you have to add the WRITE_EXTERNAL_STORAGE permission so you can save the trace info; don‘t forget to remove that before you ship.[Update:] Android engineer Xavier Ducrohet writes to remind me: “DDMS has a start/stop profiling button in the ‘device view’. Upon clicking stop it launches TraceView with the trace file. This is not as fine grained as putting start/stopMethodTracing in your code but can be quite useful. For VMs earlier than froyo, the permission is required as well (DDMS basically automate getting the trace from the sd card and saving it locally before calling traceview). For Froyo+ VMs, the VM is able to send the trace file through the JDWP connection and the permission is not needed anymore (which is really useful).” Thanks, Xav!Then you run your app, then you copy the output over to your computer, and fire up Traceview.540> adb pull /sdcard/lsd.trace 541> traceview lsdAt this point, you will have noticed three things. First, turning tracing on really slows down your app. Second, the tracefile is big; in this case, 8.6M for a run that took like four seconds. Third, that traceview looks pretty cool.The bars across the top show the app’s threads and how they dealt out the time; since the Nexus One is single-threaded CPU, they have to take turns. Let’s zero in on one 100-msec segment.The top line is where my app code is running (the red segment is GC happening), the middle line is the UI thread and the bursts of activity are the ProgressBar updating, and I have no idea what the third thread, named HeapWorker, does, but it doesn’t seem a major contributor to the app’s runtime, so let’s ignore it.The bottom of the screen is where the really interesting data is; it shows which of your methods burned the time, and can be sorted in a bunch of different ways. Let’s zero in on the first two lines.Translated into English, this tells us that the top-level routine consumed 100% of the time if you include everything it called (well, yeah), but only 0.9% of the time itself. The next line suddenly starts to get real interesting: java.io.PrintStream.println(Object) and whatever it calls are using 65.2% of the app’s time. This is the code that writes the JSON out to the SD card. Right away, we know that apparently the task of pulling the data out of the phone’s ContentProviders doesn’t seem to be very expensive; it’s the output that’s hurting.Can we conclude that the app is limited by the sluggish write performance of the SD card? Let’s drill down, which is done in the most obvious point-and-click way imaginable.Ooh, there’s a nasty surprise. Of course, println calls (in effect) toString() on all its arguments. It looks like turning the arguments to strings is taking over half the time, before it even dispatches from println(Object) to println(String).I’ll skip the step of drilling down into println(String) but it does suggest that yes, there is some slow I/O happening there, to the SD card. But let’s look inside that String.valueOf() call.There’s your smoking pistol. It turns out that org.json.JSONObject.toString() is what we professional programmers call a, well, this is a family-friendly operation so I won’t go there. You can poke around inside it, but it’s just depressing.What you can do, however, is sort all the routines by their “Exclusive” times, as in the number of CPU circles burned right there in the routine. Here are all of them that use 1% or more of the total execution time.There’s a little bit of GC and Android framework View-wrangling stuff in there, but the display is dominated by org.jason and java.lang.StringBuilder code.The ConclusionThe real conclusion is that in the case of this app, I actually don’t care about the performance. A user runs it a grand total of two times, once on the old phone and once on the new phone, and it’s got lots of eye candy, so I just don’t think there’s a problem.If I did want to speed this up, it’s obvious what to do. First, either stop using JSON, or find a cheaper way to serialize it. Second, do fewer println() calls; glom the data together in one big buffer and just blast it out with a single I/O call. But, and here’s the key point, if I’d guessed where the bottlenecks were, I’d have been wrong, mostly.Traceview is a nice tool, and if you don’t already know it, you owe it to yourself to learn it.

One Screen Turn Deserves Another

[This post is by Dan Morrill, Open Source & Compatibility Program Manager. â€" Tim Bray]Android has an API for accessing a variety of sensor types, such as an accelerometer or light sensor. Two of the most commonly-used sensors are accelerometers and magnetometers (that is, compasses.) Applications and devices frequently use these as forms of user input, and to determine which way to orient the screen.However, there’s a new wrinkle: recently, a few devices have shipped (see here and here) that run Android on screens that are naturally landscape in their orientation. That is, when held in the default position, the screens are wider than they are tall. This introduces a few fairly subtle issues that we’ve noticed causing problems in some apps. Now, part of the reason for this is that the Android SDK docs on the sensor API left a couple things unsaid, leading many developers to use them incorrectly. Even a couple of our own samples did the wrong thing. Sorry about that!Fortunately, using these APIs correctly is pretty simple, if you keep three rules in mind:The sensor coordinate system used by the API for the natural orientation of the device does not change as the device moves, and is the same as the OpenGL coordinate system.Applications must not assume that the natural orientation is portrait. That's not true on all devices.Applications that match sensor data to on-screen display must always use android.view.Display.getRotation() to map sensor coordinates to screen coordinates — even if their manifest specifies portrait-only display.If you have a strong background in math, the three rules above may be all you need to work out the rest. But if that’s not you, the rest of this post explains things step-by-step, and gives some tips for using sensors correctly.The Basic ProblemBefore we dive in, here’s a tip that I personally have found to be helpful: always remember that the sensor data’s coordinate system never changes. Ever. The rest of this post is going to talk about coordinate systems and rotations and so on. But sometimes when your head is deep in 3D transforms, you can get disoriented, so I’ve found it helps to frequently remind myself that no matter what is happening to the screen, the sensor coordinate system never changes.Now with that tip in mind, we need an example to talk about. Let’s consider a simple app that draws an arrow that always points in the direction of gravity, animating the arrow as the user moves the phone around, like a plumb-bob. When a typical phone is held normally, the arrow points down, as shown in Figure A:(Note: In the figures in this post, the letter “G” means the direction of gravity in the sensor coordinate system. In Figure A, for example, “G = -y” means that gravity is aligned with the device’s negative-Y axis, as measured by the accelerometer. And remember — the sensor coordinate system never changes!)This app is pretty straightforward to implement in OpenGL: you simply need to draw an arrow on a GL SurfaceView, after rotating the coordinate space in response to the sensor data returned by the accelerometer. This “just works” because — in this basic case — the OpenGL screen coordinate system lines up with the sensor coordinate system.So, this technique works, and the arrow will always point down — until you turn the phone too far.So What’s the Problem?Most Android devices use the accelerometer to detect when the device is being held sideways, and rotate the screen accordingly. This normally causes the apps to display horizontally, from the point of view of the user.What this reorientation actually does is remap the X and Y axes, causing the app to draw itself horizontally. However, the Android sensor APIs define the sensor coordinate space to be relative to the top and side of the device — not the short and long sides. When the system reorients the screen in response to holding the phone sideways, the sensor coordinate system no longer lines up with the screen’s coordinate system, and you get unexpected rotations in the display of your app. Figure B shows an example:There are are a couple different fixes for this problem that are commonly used today, but we’ve noticed that these often don’t work properly on landscape-default devices.A common first attempt to solve the auto-rotation problem is to simply lock the screen to portrait mode, via the android:screenOrientation attribute in AndroidManifest.xml. This prevents the system from performing a screen coordinate system remap in response to device orientation, and so the sensor and screen coordinate systems remain in sync. However, locking the screen to portrait mode this way prevents the coordinate systems from getting out of sync on portrait-default devices, but causes them to become out of sync on landscape-default devices. This is because it forces a screen reorientation on those devices.The second common technique is to detect when the device is in landscape mode, and compensate for it by adding a rotation to the graphics that are displayed. Unfortunately, this technique is often only a partial fix, because if you aren’t careful about detecting landscape mode, you will again cause an unnecessary compensation on landscape-default devices.The Correct FixSo what’s a poor developer to do? This seems like a catch-22: you can’t prevent screen reorientation, but you can’t compensate for it, either.Or can you? Actually, you can compensate — you just have to make sure you’re correctly detecting when compensation is necessary. The question is, how does the device tell you that it’s been reoriented? And the answer is: android.view.Display.getRotation().That method will return one of four values, indicating that either the device has not been reoriented (ROTATION_0), or that it has been reoriented by 90 degrees, 180 degrees, or 270 degrees (which respectively are ROTATION_90, ROTATION_180, and ROTATION_270.)Pay special attention to those last two. ROTATION_180 and ROTATION_270 mean that each device actually has two portrait and two landscape modes: normal portrait and landscape, and the upside-down versions of each. Some Android devices that do “360 reorientation” will use these rotation modes as well, so you need to handle this generally, beyond just accounting for portrait or landscape mode.Once you have the screen orientation info in hand, you can treat it as a rotation around the screen’s Z axis when rendering graphics. By applying the rotation to the values you get from your SensorEventListener, you can correctly and reliably compensate for screen reorientations on all devices.Note that Display.getRotation() will tell you if the screen has been reoriented at all, not that it was reoriented specifically in response to the accelerometer. For example, even if you disable accelerometer-based reorientation by using android:screenOrientation=”nosensor", your app might still be reoriented if the user has opened a hard keyboard on the device.Because handling all this involves some math that can be a bit of a chore, as a convenience we’ve provided the android.hardware.sensor.SensorManager.remapCoordinateSystem() method to do much of this remapping work for you. If you choose not to do use this method, you can achieve a similar effect by essentially swapping axes, along with the rule of thumb that 2 axis swaps requires that you negate the third axis. (Since this is a bit error-prone, we do recommend that you use remapCoordinateSystem() when you can.)Recipes for Sensuous DelightsOkay, now we’ve got a technique that we can rely on to work on all devices. But how do you update your app? To give you a more explicit helping hand on how to fix your apps, I’ve whipped up a few recipes for updating your apps.Apps That Never Draw Sensor DataApps that never display graphics derived from sensor data usually don’t need to make any changes. Examples of this type of app are those that detect for bumps to the device, those that use sensors for gesture input, apps that monitor g-forces (watching for free-fall or acceleration), and so on. These apps aren’t drawing images that vary according to the device’s orientation.This isn’t a hard and fast rule; there probably are some apps out there that do need to take screen orientation into consideration, even though they don’t draw graphics depicting the sensor data. But, if your app just uses sensors in the background, there’s a good chance you won’t need to make any changes.Apps That Work in Both Portrait and LandscapeMost Android apps work fine in both portrait and landscape, using the standard tools. If your app is one of these and you also use sensors, the only change your app probably requires is a tweak to use the behavior I outlined above. That is:Don’t assume that portrait is the default mode.Don’t assume that locking your app to portrait mode solves this issue.Don’t assume that disabling sensor-based reorientation solves this issue (since reorientations also occur on some devices when the user opens a keyboard.)Check for the current device orientation via getRotation(), and compensate accordingly, as detailed earlier.Apps That Only Work in One OrientationSome apps — notably, many games — only work well (or at all!) in either portrait or landscape mode. It’s perfectly okay, of course, for such apps to lock themselves to the appropriate mode, and doing so simplifies the sensors quite a bit.However, because Android devices actually support two landscape and two portrait modes, these apps still need to check the current orientation. That is, if an app locks itself to landscape mode, it will need to perform a compensation on portrait-default devices, but not on landscape-default devices. And of course — are you sick of hearing this yet? — this can be accomplished by checking the result of getRotation().Phew! Quite a mouthful for what is a fairly straightforward notion, once you understand what’s going on. But if I had to distill all that down into a single sentence, it would be this: android.view.Display.getRotation() is your friend.I hope you’ve found this information useful; what’s more, I hope you’ve found it practical. We’ll keep improving our SDK and docs, and I hope you’ll keep improving your apps.Happy coding!

Multithreading For Performance

[This post is by Gilles Debunne, an engineer in the Android group who loves to get multitasked. â€" Tim Bray]A good practice in creating responsive applications is to make sure your main UI thread does the minimum amount of work. Any potentially long task that may hang your application should be handled in a different thread. Typical examples of such tasks are network operations, which involve unpredictable delays. Users will tolerate some pauses, especially if you provide feedback that something is in progress, but a frozen application gives them no clue.In this article, we will create a simple image downloader that illustrates this pattern. We will populate a ListView with thumbnail images downloaded from the internet. Creating an asynchronous task that downloads in the background will keep our application fast. An Image downloaderDownloading an image from the web is fairly simple, using the HTTP-related classes provided by the framework. Here is a possible implementation:static Bitmap downloadBitmap(String url) { final AndroidHttpClient client = AndroidHttpClient.newInstance("Android"); final HttpGet getRequest = new HttpGet(url); try { HttpResponse response = client.execute(getRequest); final int statusCode = response.getStatusLine().getStatusCode(); if (statusCode != HttpStatus.SC_OK) { Log.w("ImageDownloader", "Error " + statusCode + " while retrieving bitmap from " + url); return null; } final HttpEntity entity = response.getEntity(); if (entity != null) { InputStream inputStream = null; try { inputStream = entity.getContent(); final Bitmap bitmap = BitmapFactory.decodeStream(inputStream); return bitmap; } finally { if (inputStream != null) { inputStream.close(); } entity.consumeContent(); } } } catch (Exception e) { // Could provide a more explicit error message for IOException or IllegalStateException getRequest.abort(); Log.w("ImageDownloader", "Error while retrieving bitmap from " + url, e.toString()); } finally { if (client != null) { client.close(); } } return null; }A client and an HTTP request are created. If the request succeeds, the response entity stream containing the image is decoded to create the resulting Bitmap. Your applications' manifest must ask for the INTERNET to make this possible.Note: a bug in the previous versions of BitmapFactory.decodeStream may prevent this code from working over a slow connection. Decode a new FlushedInputStream(inputStream) instead to fix the problem. Here is the implementation of this helper class:static class FlushedInputStream extends FilterInputStream { public FlushedInputStream(InputStream inputStream) { super(inputStream); } @Override public long skip(long n) throws IOException { long totalBytesSkipped = 0L; while (totalBytesSkipped < n) { long bytesSkipped = in.skip(n - totalBytesSkipped); if (bytesSkipped == 0L) { int byte = read(); if (byte < 0) { break; // we reached EOF } else { bytesSkipped = 1; // we read one byte } } totalBytesSkipped += bytesSkipped; } return totalBytesSkipped; } }This ensures that skip() actually skips the provided number of bytes, unless we reach the end of file.If you were to directly use this method in your ListAdapter's getView method, the resulting scrolling would be unpleasantly jaggy. Each display of a new view has to wait for an image download, which prevents smooth scrolling.Indeed, this is such a bad idea that the AndroidHttpClient does not allow itself to be started from the main thread. The above code will display "This thread forbids HTTP requests" error messages instead. Use the DefaultHttpClient instead if you really want to shoot yourself in the foot.Introducing asynchronous tasksThe AsyncTask class provides one of the simplest ways to fire off a new task from the UI thread. Let's create an ImageDownloader class which will be in charge of creating these tasks. It will provide a download method which will assign an image downloaded from its URL to an ImageView:public class ImageDownloader { public void download(String url, ImageView imageView) { BitmapDownloaderTask task = new BitmapDownloaderTask(imageView); task.execute(url); } } /* class BitmapDownloaderTask, see below */ }The BitmapDownloaderTask is the AsyncTask which will actually download the image. It is started using execute, which returns immediately hence making this method really fast which is the whole purpose since it will be called from the UI thread. Here is the implementation of this class:class BitmapDownloaderTask extends AsyncTask<String, Void, Bitmap> { private String url; private final WeakReference<ImageView> imageViewReference; public BitmapDownloaderTask(ImageView imageView) { imageViewReference = new WeakReference<ImageView>(imageView); } @Override // Actual download method, run in the task thread protected Bitmap doInBackground(String... params) { // params comes from the execute() call: params[0] is the url. return downloadBitmap(params[0]); } @Override // Once the image is downloaded, associates it to the imageView protected void onPostExecute(Bitmap bitmap) { if (isCancelled()) { bitmap = null; } if (imageViewReference != null) { ImageView imageView = imageViewReference.get(); if (imageView != null) { imageView.setImageBitmap(bitmap); } } } }The doInBackground method is the one which is actually run in its own process by the task. It simply uses the downloadBitmap method we implemented at the beginning of this article.onPostExecute is run in the calling UI thread when the task is finished. It takes the resulting Bitmap as a parameter, which is simply associated with the imageView that was provided to download and was stored in the BitmapDownloaderTask. Note that this ImageView is stored as a WeakReference, so that a download in progress does not prevent a killed activity's ImageView from being garbage collected. This explains why we have to check that both the weak reference and the imageView are not null (i.e. were not collected) before using them in onPostExecute.This simplified example illustrates the use on an AsyncTask, and if you try it, you'll see that these few lines of code actually dramatically improved the performance of the ListView which now scrolls smoothly. Read Painless threading for more details on AsyncTasks.However, a ListView-specific behavior reveals a problem with our current implementation. Indeed, for memory efficiency reasons, ListView recycles the views that are displayed when the user scrolls. If one flings the list, a given ImageView object will be used many times. Each time it is displayed the ImageView correctly triggers an image download task, which will eventually change its image. So where is the problem? As with most parallel applications, the key issue is in the ordering. In our case, there's no guarantee that the download tasks will finish in the order in which they were started. The result is that the image finally displayed in the list may come from a previous item, which simply happened to have taken longer to download. This is not an issue if the images you download are bound once and for all to given ImageViews, but let's fix it for the common case where they are used in a list.Handling concurrencyTo solve this issue, we should remember the order of the downloads, so that the last started one is the one that will effectively be displayed. It is indeed sufficient for each ImageView to remember its last download. We will add this extra information in the ImageView using a dedicated Drawable subclass, which will be temporarily bind to the ImageView while the download is in progress. Here is the code of our DownloadedDrawable class:static class DownloadedDrawable extends ColorDrawable { private final WeakReference<BitmapDownloaderTask> bitmapDownloaderTaskReference; public DownloadedDrawable(BitmapDownloaderTask bitmapDownloaderTask) { super(Color.BLACK); bitmapDownloaderTaskReference = new WeakReference<BitmapDownloaderTask>(bitmapDownloaderTask); } public BitmapDownloaderTask getBitmapDownloaderTask() { return bitmapDownloaderTaskReference.get(); } }This implementation is backed by a ColorDrawable, which will result in the ImageView displaying a black background while its download is in progress. One could use a “download in progress” image instead, which would provide feedback to the user. Once again, note the use of a WeakReference to limit object dependencies.Let's change our code to take this new class into account. First, the download method will now create an instance of this class and associate it with the imageView:public void download(String url, ImageView imageView) { if (cancelPotentialDownload(url, imageView)) { BitmapDownloaderTask task = new BitmapDownloaderTask(imageView); DownloadedDrawable downloadedDrawable = new DownloadedDrawable(task); imageView.setImageDrawable(downloadedDrawable); task.execute(url, cookie); } }The cancelPotentialDownload method will stop the possible download in progress on this imageView since a new one is about to start. Note that this is not sufficient to guarantee that the newest download is always displayed, since the task may be finished, waiting in its onPostExecute method, which may still may be executed after the one of this new download.private static boolean cancelPotentialDownload(String url, ImageView imageView) { BitmapDownloaderTask bitmapDownloaderTask = getBitmapDownloaderTask(imageView); if (bitmapDownloaderTask != null) { String bitmapUrl = bitmapDownloaderTask.url; if ((bitmapUrl == null) || (!bitmapUrl.equals(url))) { bitmapDownloaderTask.cancel(true); } else { // The same URL is already being downloaded. return false; } } return true; }cancelPotentialDownload uses the cancel method of the AsyncTask class to stop the download in progress. It returns true most of the time, so that the download can be started in download. The only reason we don't want this to happen is when a download is already in progress on the same URL in which case we let it continue. Note that with this implementation, if an ImageView is garbage collected, its associated download is not stopped. A RecyclerListener might be used for that.This method uses a helper getBitmapDownloaderTask function, which is pretty straigthforward:private static BitmapDownloaderTask getBitmapDownloaderTask(ImageView imageView) { if (imageView != null) { Drawable drawable = imageView.getDrawable(); if (drawable instanceof DownloadedDrawable) { DownloadedDrawable downloadedDrawable = (DownloadedDrawable)drawable; return downloadedDrawable.getBitmapDownloaderTask(); } } return null; }Finally, onPostExecute has to be modified so that it will bind the Bitmap only if this ImageView is still associated with this download process:if (imageViewReference != null) { ImageView imageView = imageViewReference.get(); BitmapDownloaderTask bitmapDownloaderTask = getBitmapDownloaderTask(imageView); // Change bitmap only if this process is still associated with it if (this == bitmapDownloaderTask) { imageView.setImageBitmap(bitmap); } }With these modifications, our ImageDownloader class provides the basic services we expect from it. Feel free to use it or the asynchronous pattern it illustrates in your applications to ensure their responsiveness.DemoThe source code of this article is available online on Google Code. You can switch between and compare the three different implementations that are described in this article (no asynchronous task, no bitmap to task association and the final correct version). Note that the cache size has been limited to 10 images to better demonstrate the issues.Future workThis code was simplified to focus on its parallel aspects and many useful features are missing from our implementation. The ImageDownloader class would first clearly benefit from a cache, especially if it is used in conjuction with a ListView, which will probably display the same image many times as the user scrolls back and forth. This can easily be implemented using a Least Recently Used cache backed by a LinkedHashMap of URL to Bitmap SoftReferences. More involved cache mechanism could also rely on a local disk storage of the image. Thumbnails creation and image resizing could also be added if needed.Download errors and time-outs are correctly handled by our implementation, which will return a null Bitmap in these case. One may want to display an error image instead.Our HTTP request is pretty simple. One may want to add parameters or cookies to the request as required by certain web sites.The AsyncTask class used in this article is a really convenient and easy way to defer some work from the UI thread. You may want to use the Handler class to have a finer control on what you do, such as controlling the total number of download threads which are running in parallel in this case.