Here is a simple Video Chat application I built with Flex 4 and deployed on AIR for Android. The Application is just 30 lines of code and allows multiple users to join a chat room and “video chat”. Video streaming is powered by LiveCycle Collaboration Services, a set of hosted Flash Services that enable developers [...]
A few weeks ago, I posted a video of a Mobile Trader Desktop application I built using Flex 4 and AIR for Android. I recently updated the application for Froyo (Android 2.2), and I can now share the application file and the source code. Watch the video: Download the Application and Source Code You can [...]
I finally took the time to rebuild the Employee Directory application with the latest version of AIR for Android (available here) to run on Froyo. See the links below to download the apk and the source code. (If you are still running Eclair see my original post). The Employee Directory application demonstrates how to build [...]
Writing Flash Platform applications for Android, or designing Flash content for mobile users and want to see the content emulated on specific mobile devices? Adobe Device Central CS5 has profiles for many mobile devices so you can test your applications without owning the device.
Since Adobe just released the official Motorola X profile for Android, you can test your Android 2.2 (aka “Froyo”) apps and sites now and get the phone later.
To test apps In Flash Professional CS5
With your FLA file open, select Control > Test Movie > in Device Central. Select the device you want in the Test Devices panel. The application appears in the emulator:
To get new devices
In Device Central, click Browse and then search for a keyword, like “Droid” to see what’s available:
Click and drag new profiles, like the Motorola Droid or Motorola X, to your list of Test Devices.
If you don’t see the profile you want, come back soon; the community is posting new profiles daily and Adobe posts official profiles as they are finalized.
To get back to the list of devices at any time
Click Browse and the Home button:
Click Emulate Flash to get back to testing in the emulator
To test mobile-specific features, like the Accelerometer
If a phone’s profile supports accelerometer or other mobile features, you can test them in Device Central. The Accelerometer panel lets you simulate moving the device in three
dimensions. Alt+Click simulates multiple finger touches and the Multitouch panel lets you set touch size and pressure. The Geolocation panel lets you test GPS features, and other panels
provide even more information:
Device Central works with Dreamweaver and several other Adobe products. Test your entire Flash-enabled Web site for mobile browsing using Device Central (including HTML5 sites).
Sweet video description of organizing classes, implementing mobile feature APIs and using Device Central by Adobe’s Mark Doherty: http://www.flashmobileblog.com/2010/04/14/device-central-cs5-multitouch-and-debugger/
Device Central Support page: http://www.adobe.com/support/devicecentral/
Twitter updates for Device Central profiles: http://twitter.com/devicecentral
Dreamweaver HTML5 Pack extension: http://labs.adobe.com/downloads/html5pack.html
Dreamwever testing mobile content in Device Central Adobe TV page: http://tv.adobe.com/watch/learn-dreamweaver-cs5/testing-mobile-content-with-adobe-device-central/
Using Device Anywhere (an alternative to Device Central) for testing: http://www.adobe.com/devnet/devices/articles/device_anywhere.html
We have released Flash Player 10.1 to our OEM partners in what has been an incredible engineering effort working with our Open Screen Project partners. One of the problems with the Flash Player generally, is that it is invisbile. As a user its so easy to forget that a single web technology is powering billions of videos, games, Rich Internet Applications and now desktop applications with AIR.
So we have been working with the worlds leading content providers, alongside our OEM partners to create experiences that shine. With that, we’ve aggregated these together over at m.flash.com so that you can enjoy them on your mobile phones. I think it will really help to sell those mobile and device projects that we’ve all been thinking about.
If I’m honest, this is the one that I have been most excited about, and this week the BBC launched iPlayer 3.0. with support for Android Froyo devices and Flash Player 10.1. As I live in the UK, and I know many of you don’t, let’s take a look at just how huge the service has become.
Simply put, iPlayer is like Hulu for BBC content providing video on demand services for UK citizens. Using the service we can watch BBC content that we’ve missed, across 10 TV channels and 11 radio stations. On top of that, we can also watch TV live using iPlayer online to work around poor terrestrial signals – or in my case, a tiny television
In perspective (BBC iStats for May 2010)
- 130m radio and television streams watched, across PCs, consoles and mobile phones
- 13m live streams were broadcast, including a huge amount of live radio proportional to video streams
- 6.5m video/radio requests from mobile phones
- Peak usage tracks linear broadcast usage almost exactly – the shape of things to come
Currently the iPlayer is available on the Nintendo Wii, PS3, Mac, Windows, Linux, Symbian, Windows Mobile and iOS devices. As you would expect, when it comes to scaling the iPlayer platform across all of these devices, the task is huge. That’s where Flash comes in, if you look at the list above (and more still) we have demonstrated Flash on all of them.
When you test your Flash-enabled site, why not let me know? Let’s add it to m.flash.com
I was at the Droid X launch event in SF today and it’s a pretty slick device. Big screen, fast, HDMI output for streaming HD video to your TV. (It also comes with a HD camcorder). Although the device will first ship with Android 2.1, and not Froyo until later this summer, the team’s demo unit had an early version of Froyo and we were demo-ing Flash Player 10.1. Of course, I work for Adobe and the Flash Player team and I’m biased, but Flash content runs great on that device. We were showing off Kongregate and Mochi games, replays of the USA win on ESPN, videos from Sony Pictures — and as long as we had a good signal we had great content.
Read more about the Droid X in the press release. Paul Betlem, Flash Player engineering, also discusses some of the specs of the Droid X on the Flash Player team blog.
Thinking about optimizing your Flash content ready for the slew of devices coming to market in the next few months? Start here.
This video showcases an absolutely astounding capability of the new Google Nexus One smartphone running the Android operating system (FroYo 2.2) with Adobe Flash Player 10.1. Mingleverse.com is a 3D immersion technology which allows individuals to tele-port their avatars into virtual universes.
When I did my video of various bits of Flash content running on the Nexus One, the overwhelming theme that kept coming up was battery life. I know battery life is something that both users and Flash developers are curious about. Flash provides access to a wealth of rich content. Video, games, and animation are all things that are much more processor intensive than rendering static images and text. In general, Flash content’s impact on battery life is comparable to other similar multimedia technologies. Where Flash really shines though, is that it uses the same amount of battery as other technologies, while providing a much richer experience with significantly better performance.
With all of the questions I wanted to provide some numbers about battery life but didn’t think that my rudimentary tests would be very good so I asked Vinay Ramani, the group product manager for mobile runtimes if his team had any data. These are very early initial tests but I thought they were worth sharing. You’ll be seeing more in-depth stress tests from us soon but hopefully these early numbers give you an idea of the fairly small impact that Flash Player in the browser has on battery life.
These are pretty close to clean-room tests. The team hooked up the meters and performed each test under a strict set of conditions:
- Wi-Fi – off
- 3G – on
- OTA Push – off
- Volume – on, at one notch
- Bluetooth – off
- Only browser is loaded, nothing else
- 3G, lying flat on a table
Also, keep in mind that this is ALL done in software. Hardware acceleration is coming down the road but we wanted to make sure that this thing ran lean and mean in software without hardware acceleration at first. We also have ways that developers can control how SWF content loads on their pages so they can give certain SWF files priority and the Flash Player will give those a higher percentage of the resources. This should result in a smoother browsing experience.
Video is probably the thing I get asked the most about with respect to battery life and it’s a good thing to compare because since both Flash Player and the Nexus One’s native player support H.264 you can get a good feel for how the battery life stacks up between native H.264 and H.264 video played through the Flash Player. The team used the same YouTube video, one encoded at H.264 baseline level 2.1 at 30 fps with a resolution of 480 x 270. They did two sets of tests, one was on full brightness and the other was on half brightness. Then they just kept playing the video over and over again.
On full brightness, the Nexus One without Flash Player got 3 hours and 45 minutes. Playing the video through the Flash Player gave a battery life of 3 hours and 8 minutes. Not a big dropoff. At half brightness it was even better. The Nexus One without Flash got 3 hours 56 minutes and the Flash version got 3 hours and 31 minutes. Just an 10.5% change which isn’t bad at all considering everything the Flash Player does.
As you can see from the Flash/non-Flash tests, video is pretty intensive no matter what. What was even better was the battery life around games. There wasn’t a good way to test non-Flash versus Flash, but the team took a couple of popular Flash games, Tic-Tac-Toe and Alchemist, and played them until the battery died.
Tic-Tac-Toe lasted 6 hours and 49 minutes while the device could play Alchemist on the Nexus One for 7 hours and 7 minutes. While they aren’t intense 3D games, that’s pretty spectacular battery life and this was on full screen brightness. If you’re a game developer you can be sure that people playing your Flash game are going to be able to play it for a loooong time.
Let’s also quickly talk about HTML5 and Flash Player on mobile devices both in terms of performance and battery life. The team used the exploding balls test from Cameron Adams and tested the Canvas versions and the Flash versions. This one is a little tricky because part of the impact on battery life is how many CPU cycles are being used. And the higher the frame rate, the more CPU content is going to use. So it’s tough to compare HTML5 and Flash content directly because right now HTML5 content just doesn’t run very well on devices. The canvas example runs at 6.7 frames per second while the Flash version runs at about 24 frames per second. The difference between those ends up being minimal even though Flash has so many more frames per second. With the canvas test you get about 3.1 hours of battery life and with Flash Player you get 2.9 hours of battery life. A difference of about 12 minutes. We’re going to be doing some more exact tests around this where we equalize frames per second, so you should see some dramatic improvements once the test can be normalized.
This is just a sample of some of the early numbers that we’re getting. As I said, we’ll have some more detailed tests soon, but this should show that the hit for running richer content isn’t as big as one would think. The teams have done an absolutely phenomenal job of creating a runtime that performs on par with the desktop player and doesn’t sacrifice much at all in the way of battery life. If you’re a Flash developer, the exact same things that got you excited about Flash Player on the desktop now apply to mobile devices. The mobile world is your oyster Flashers.
Now Flash on.
Surprise! Today at Google I/O Vic Gundotra, Google VP Engineering announced Flash Player 10.1 and Adobe AIR 2.5 running on FroYo. The launch today represents a milestone that we’ve been working towards for some time, and all of us at Adobe are hugely excited to see Flash Player 10.1 finally get into the hands of consumers.
The beta is now waiting on the Android Market for Nexus One and Motorola Droid users with Froyo to test out. General availability is expected on June 17th 2010.
While today’s announcement is all about Android, our target mobile operating systems for Flash Player also include Windows Phone 7, webOS, Symbian, and BlackBerry. Adobe provides a porting kit and Linux-based reference implementation to Open Screen Project partners to allow them to port Flash Player 10.1 to other platforms. These ports are subject to Adobe certification and must pass our standards for compatibility, performance and usability in order for devices to be marketed as “Includes Adobe Flash Player.”
Flash Player 10.1 on Android
In all, Flash Player 10.1 has been built from the ground up, and not just for mobile phones but for the desktops, tablets, netbooks and even televisions, consoles and set-top boxes. We have been working extremely hard on the runtime of course, but on top of that many of you have been working with us to optimize your web content for Flash Player 10.1.
Here is a landing page that features a number of websites that highlight the variety of Flash Player user experiences available on a mobile device. These sites and most popular websites that use Flash can now be accessed on smartphones supporting Flash Player 10.1.
Since we demonstrated the Flash Player on Android at the Mobile World Congress there have been a number of decisions made, changes implemented and tweaks applied to Flash Player 10.1. These changes focused on usability, integration, performance and power management – so let’s look at some of these in more detail.
Installation and updates
I have documented the process over here in another post. Suffice to say, the process is simple and demonstrates our commitment with the Open Screen Project to ensuring the evolution of Flash Player on mobile and devices.
Due to time constraints with shipping FroYo it hasn’t been possible to make all of the Android browser changes required to enable multi-touch in Flash Player. Web enablement has always been the top priority and so this (extremely complex) integration will happen later. AIR 2.5 on Android is multi-touch enabled and so it’s still possible to use your fingers, thumbs and toes as necessary on Android.
One of the cool new feature of Flash Player 10.1 is the accelerometer API, making Flash Player the first browser technology to support access to this hardware. In Device Central CS5 we have added some emulation support for the API, you can read more here.
Focused Mode (single tap)
The Android and other browsers support multi-touch for viewing web pages, so that you can pan and zoom around non-optimized sites with ease. To ensure that touch events are received by Flash or the browser appropriately we have created focused mode. It works very simply using a priority system, so if you tap the Flash content that you want to interact with Flash receives the touch events, if Flash doesn’t pick up the event then it’s passed to the browser. Tapping on the HTML will revert this focus priority back to the browser.
Smartzoom (double tap)
When a user double taps a piece of Flash content it will zoom to fit the screen, while maintaining the correct aspect ratio. The content is still viewed in the context of the HTML, rather than launching into full screen mode. This ensures that content remains in embedded mode – which makes sense given that this is the predominant usage of Flash on the web.
Another change to our previous showing is that FullScreen mode is now controlled via actionscript, just as it is on the desktop. So if you want your video player or game to playback using the full screen, then you’ll need to use this code:
We have already seen some of the benefits of this effort on the desktop version of Flash Player 10.1. Essentially it means that Flash content that’s not visible to the user will not be rendered and will receive limited CPU time. SWFs that are off-screen and/or consuming required resources can also be put to sleep and resumed on demand. You can control this behaviour by applying priority values to SWF files using the embed tag.
Video Hardware Decoding
One of the hardest features to get right has been video hardware decoding, and for the beta version this will not be enabled.
The player will be put to sleep along with the device to conserve power. So if you fall asleep watching youtube then you won’t wake up to talking cats at 4am – tried and tested. cats…
For me, this is the kick-ass feature that should always have been arbitrating the use of the Flash Player. If your content is not optimized correctly, has serious memory leaks and manages to use too much CPU power then it’ll go in the “sin bin” These SWFs will render with a “click-to-play” button that the user can control as necessary.
As with Flash Lite before it, Flash Player 10.1 has to be a good citizen on a mobile phone. So if you receive a call or change application then Flash Player will respond appropriately, which typically means shutting down or pausing depending on the platform.
As has been documented before, our minimum spec for Flash Player 10.1 is ARM11-Cortex A8/9 at 550mhz. For Cortex-A8 processors we require NEON, which enables improved multi-media playback for a lower mhz rating.
If you don’t know what any of that means then I wouldn’t be too concerned. These chipsets represent the bulk of what our OEM partners are shipping, or planning to ship moving forward – and this list will undoubtedly expand.
AIR 2.5 on Android
Also announced today is an expanded pre-release of AIR 2.5 for Android devices. Many of us on the Evangelism team have been playing with this for several weeks now, and it’s seriously cool.