Adobe Flash 10.1 On Android: Is It Sufficiently Adroit?
I hold nothing back, dear readers, in striving to bring you timely and informative tech analyses. This mentality is why, for example, I declined to wait for Verizon to ‘push’ me the latest-and-greatest Android v2.2 (aka ‘Froyo’) update for my Motorola Droid, deciding instead to download a dubious-sourced upgrade image (but only after perusing a sufficient number of successful-report forum posts to assure me that it was legit). And it’s why, after hearing yesterday that the ‘gold’ Adobe Flash v10.1 release for Froyo (versus its beta predecessor) was ‘on the loose’, I threw all caution to the wind and immediately threw it on my Droid. After all the back-and-forth between Adobe (and Google) and Apple, I wanted to see what all the fuss was about.
Dropbox was invaluable in getting the installation image onto my phone. After downloading the file to my MacBook Air, I moved it to the Dropbox folder, where it automatically sync’d to the Dropbox client on the Droid. The Astro file manager enabled me to move it from there to the root directory of the SD card, from whence I ran the installer. I subsequently downloaded and installed Adobe’s Flash Showcase app from the Android Marketplace, which is basically an elaborate means of directing the phone’s browser to Adobe’s mobile Flash home page.
Others have already done exhaustive tests of the plugin’s compatibility with diverse Flash-based sites…and the results are, I must say, troubling (to put it mildly). Consider me simple-minded, if you wish, but from my standpoint the predominant two kinds of content that a Flash player must robustly handle are video clips and advertisements. So I decided to focus my attention in these areas. Specifically, I checked out playback of the trailer for the upcoming film ‘The Social Network‘ (which, in spite of its sketchy historical accuracy, looks intriguing) off Sony’s site:
and I also took a look at the Flash ads (which replace static counterparts when the page is viewed from a Flash plugin-augmented browser) on the Brian’s Brain blog home page:
In addition to validating adequate functionality, I was also interested in assessing CPU utilization while the Flash plugin was running, both because this would tell me how much spare processing horsepower was available for other multitasking functions and because it would provide me a metric as to the battery life impact I might expect. After a bit of Google research, I came across NetMeter, which worked perfectly for my needs. Again, I used Dropbox to get the installer onto my phone.
The video content on Sony’s website, I found, played back adequately well. There was a bit of frame-drop stutter, along with some discernible image artifacts, but nothing so egregious as to make the material unwatchable. Then again, though, I probably wouldn’t be watching it anyway; ever since the first video-augmented iPods came out, my consistent opinion as to the appeal (or lack thereof) of viewing diminutive-sized video material has been one of profound pessimism. And I should also point out that Sony’s stuff was specifically encoded for handsets’ limited processing horsepower and display resolutions (thereby explaining its showcase on Adobe’s website); higher bitrate material probably won’t be as robust on the Droid or its ilk.
Here’s the NetMeter plot:
Note the brief but substantial CPU utilization spike caused by my launch of the browser, followed by another more sustained utilization uptick after I launched the trailer. Note, too, a corresponding network traffic spike in the latter case; as you can see, I conducted my tests with the Droid Internet-connected via Wi-Fi versus sketchy cellular. Due to an apparent abundance of available handset memory resources, the browser/Flash plugin combination downloaded and locally buffered the entire clip.
Next, take a look at the NetMeter profile associated with the Brian’s Brain home page ads:
CPU utilization is lower than with the earlier video playback example, but still significant. Each utilization downturn in the graph corresponds to my transition away from the browser to NetMeter; in the earlier test, I’d allowed the movie trailer to complete playback undisturbed. Clearly, the Android O/S is not attempting to multi-task Flash playback with other functions…I subsequently confirmed this by prematurely terminating ‘The Social Network’ movie trailer playback each time I transitioned from the browser to the home screen or elsewhere:
While I was at it, I tried visiting the Flash-coded Hulu website. I’d heard that Hulu (presumably at the insistence of its content partners) was blocking playback on Android v2.2, but I’d also heard that hackers had figured out a workaround. The Flash-based animation transitions on the home page still worked fine:
but my recollections were correct; the attempt to play back an episode of Fat Albert was unsuccessful:
The workaround involved accessing advanced browser settings in order to alter the user agent string (sound familiar?). Amusingly, the user agent options offered to me were ‘Android’, ‘Desktop’, and…’iPhone’. Unfortunately, Hulu seems to have subsequently plugged that particular hole.
Finally, for grins, I took a look at CPU utilization using the Pandora app for Android. On computers, the Pandora streaming music service relies on a browser-based and Flash-coded website for playback purposes. On handsets such as the Motorola Droid and my Apple iPhone 3GS, on the other hand, Pandora has developed dedicated client utilities. Here’s the NetMeter report:
You can see the network traffic data-queueing spikes, along with a momentary up-tick in CPU utilization, in advance of each sequential track’s playback initiation:
Throughout the measured playback period, CPU utilization consistently hovered at around 40% in spite of my transitions between the Pandora app, NetMeter, my home screen, and elsewhere. The audio presentation smoothly continued throughout this time interval, confirming that Android is treating Pandora as a multitasking-capable application:
and thereby explaining the presence of a dedicated ‘quit’ option in the program UI:
Given the adequate but not overwhelming performance I experienced in my brief experimentation, coupled with others’ less-than-stellar reviews (in spite of being, in some cases, on more advanced hardware than mine) I can’t help but think that Flash for mobile systems is still a silicon generation (or few) ahead of the curve right now. My Droid uses a Texas Instruments OMAP 3430 Arm Cortex A8 600 MHz CPU, under-clocked to 550 MHz, along with a 430MHz TMS320 multimedia processor.
In an encouraging-to-Adobe trend, the follow-on Droid 2 bumps up the processor allocation to a 1 GHz OMAP 3630. TI just announced its license of ARM’s next-generation Eagle core; meanwhile, Qualcomm is hard at work on a dual-core 1.5 GHz ARM design. With a solid embrace from Google and planned support from Microsoft and other O/S developers, Adobe may yet have a chance of getting pervasive Flash capabilities into mobile handsets…Apple be damned.
p.s…in contrast to a recent post, you’ll see above that I finally figured out how to snag screenshots of my Android-based phone. No, I didn’t hack it to gain root access. Instead, I followed these instructions, after first downloading and installing the Android SDK starter package. USB-tethering the phone to my Macbook Air, then capturing the screenshots via a OS X-based utility, did the trick. Truth be told, I conducted my experiments twice; the first time, I took pictures with my iPhone as before (and used Dropbox to get the images off the cameraphone). But unhappy with the results, I re-ran the tests after installing Google’s SDK suite. Anything for you, dear readers…