Posts tagged ‘Jelly Bean’
It can be debated that the camera is one of the most used features of a smartphone, and thus one of the most important. It’s no wonder too – the inclusion of a small and convenient camera subsystem in the everyday phone has created more opportunities for capturing those quick snaps that wind up on Facebook, your wallpaper, or in the family album. Wherever it ends up though, no one wants the blurry photo of Sasquatch, or even something that was missed entirely (some of the device’s we’ve seen are so slow, they’d only capture an empty track during the 100m sprint!).
While imaging sensors and lenses in smartphones have come a long way since the days of non-autofocus VGA shooters, even the best snappers struggle to match the performance of a basic pocket point and shoot camera. At Apkudo, via our Apkudo Device Analytics product, we deeply assess the user experience of pre-launch Android devices for most OEMs worldwide (we have over 6 pre-launch devices in our lab just this week!). It’s a lot of fun, and interestingly, by a reasonable margin, the most common user experience issues we discover are camera related – ranging from low shutter speeds, to distortion effects, to poor color accuracy, and beyond.
One reason for this massive variation in camera quality is the fact that phone cameras are really only marketed by their megapixel rating, something that is a flawed metric in itself. Only recently have some OEMs tried to improve on this by touting a zero shutter-delay on their ICS devices, particularly as it is a highlight feature of ICS.
However, this is only a small aspect of the user experience relating to camera response and image quality. Many manufacturers advertise that their camera is really awesome, or it is excellent at low light, or captures images with vivid and stunning colors. Unfortunately, there is no metric to gauge this claim by, or to compare with one another. Is my camera that takes “Lifelike images with stunning realism” better than that one which does “incredible color and vividness”, or that other one which tells me it has “superb camera quality”?
It comes as no surprise that these claims mean little when it comes time for a user to decide which phone camera will best satisfy their needs.
So how can this be situation be improved? Standards! In particular, standards whereby various metrics of phone camera can be objectively compared, just like they are with professional DSLR’s.
And that is why I’m currently 36,000ft in the air, writing this blog on the way to the first meeting of IEEE P1858™ – the Draft Standard for Camera Phone Image Quality (CPIQ) working group. Apkudo has joined specifically to take part in setting a standard for camera phone image quality.
And what can Apkudo offer in this area? Simple. We have assessed every Android device that’s ever been released. The amount of data we’ve collected is immense – thousands of data points on metrics such as shutter lag, shot-to-shot latency, sharpness across the image, color accuracy and saturation, vignetting, time to first shot, color temperature – the list goes on. We’re currently using that data to assist OEMs and Operators to improve their pre-launch devices, and we intend on now using it to help the ecosystem at large.
Here’s a very small sampling of that data to whet your appetite:
Sharpness Graph
Here we’re looking at a bit of sharpness at some points across a sample image. MTF50 can be correlated to perceived image sharpness, whereas overshoot corresponds well with post-process sharpening techniques by increasing perceived contrast between edges. Obviously having an overly low MTF50 will result in blurry images. However, what it doesn’t show is artificially introduced sharpness. This is where the overshoot measure helps. The HTC Desire VC has a good sharpness by MTF50 measure on first glance, but take a closer look, and it’s over sharpening is through the roof. And this, leads to a common ‘halo’ effect affecting all edges.
HTC Desire VC with halo effect.
Samsung Galaxy Nexus.
On the other hand, the Galaxy Nexus seems to have a lower perceived sharpness. However, it has very little post processing applied, so it’s doing pretty well without much assistance.
A few more metrics:
Shutter lag, color, and Imatest results.
Here we’re looking at some camera delay tests, some camera saturation accuracy and distortion, and Imatest results. It’s fairly interesting that the One S is just about twice as quick at firing up that camera app than the other devices, including other ICS devices and the Galaxy Nexus rocking some Android Jelly Bean action.
Shot-to-shot is always an interesting one, and there seems to be two clear groups of performers. Ones that take more than a second per image, and ones that take less than half a second. Granted some of these devices have a burst mode that speeds things up a little, but we reckon that if you’re in a hurry to take a few quick pics in succession, you’re not going to have time to find that burst mode anyway.
We found the shutter lag to be pretty good on these phones, given that most of them are at least Android 4.0 (and so featuring that zero shutter lag perk). Interestingly though, the Motorola Droid 4 we analyzed is still running Gingerbread, yet keeps up with its younger brethren.
Below, we can see how each device handles color reproduction, saturation and even just to the naked eye, exposure. Some phones have a tendency to over expose, whereas some tend to underexpose. Others, like the Samsung SGS3, seem to get this just right. Color temperature is also exposed to the naked eye through the bottom row of grey patches. Of course this is all going to be dependant on the viewing monitor, but assuming it’s calibrated, the Ascend D1 and Desire VC both show a fairly warm tint, whereas the Droid 4 is hitting the other end of the scale with cool temperatures. Some of the complex analysis is handled by the excellent software produced by Imatest, which provides accurate and reproducible data that is invaluable to the classification and assessment of a phone camera.
Samsung Galaxy S3
HTC One S
Samsung/Google Galaxy Nexus
Huawei Ascend D1
HTC Desire VC
HTC One X
Motorola Droid 4
The results we’ve presented just begin to scratch the surface of the camera analysis we do here at Apkudo. Analyzing so many devices for OEMs and Operators affords us the opportunity to provide lots of insight and actionable recommendations as to why a camera might perform poorly and what can be done to fix it. When we saw that the IEEE would be putting together a working group to create a standard for methods and metrics to judge camera phone image quality, we knew we’d have a lot to offer. We are a company whose mission is to optimize the Android user experience – not just for OEMs, Operators, and developers – but for everyone. We believe we can help lead the charge in creating this industry standard to reach the end goal of a better user experience. For everyone.
—
Benjamin Tseng | Director of Device Analytics
Apkudo Inc.
+1 443 453 3172
+61 422 387 773
Since the beginning of time man has sought to virtualize the human experience. We go to sleep and have life-like experiences in our dreams, we connect to internet sites like Chatroulette to virtually meet strangers (and inadvertently catch a glimpse of some old man balls from time to time), 1995 brought us the classic Denzel Washington/Russell Crowe sci-fi action thriller Virtuosity, and nerds gather in herds online to play StarCraft (myself included) and become virtual intergalactic heroes. The journey to virtualize reality has been a long time coming. The next logical step… to run Google Play on a virtual mobile device? “Of course!” said no one.
Alas, our journey continues. Our odyssey starts with the awesome blog post “Installing Google Play on Android Emulator.” The author, Piotr Buda, was able to successfully install the Google Play application on an emulator. However, you’ll notice that in the comments and subsequent blog post he (and his readers) were unable to download and install applications: the effects of the dastardly Error 491. Additionally, the applications they were able to view were severely limited. After reading both posts, the Apkudo team attempted to take it a step further and a) get downloads working and b) be able to browse and download any app.
Installing Google Play on an Android emulator requires three separate APKs: GoogleLoginService.apk, GoogleServicesFramework.apk, and Phonesky.apk (older versions will be named ‘Vending.apk’.) All three are located in the /system/app/ folder on your device. You can issue an adb pull command to pull each one off of your device (you generally don’t need root to pull). We pulled ours off of a Samsung Galaxy S III (the version of the store that we pulled was 3.5.16)
Next we just push the three APKs to install on the emulator (we made a simple modification to the shell script from the original blog post):
#!/bin/sh echo "remounting..." adb remount echo "pushing login apk..." adb push GoogleLoginService.apk /system/app/. echo "pushing framework apk..." adb push GoogleServicesFramework.apk /system/app/. echo "pushing vending apk..." adb push Phonesky.apk /system/app/. echo "done"
Once the three APKs are installed, it is trivial to get the market executing. You’ll need to enter your account information when prompted and accept the market update if required (the update will generally not be successful, but it doesn’t seem to matter). You should now be able to browse and search the Play Store. Except, of course, you’ll usually hit an Error 491 when you try to download!
Solving Error 491
If you have created your AVD for ICS or earlier you will undoubtedly encounter Error 491 when attempting to download an application. The reason is that a shared object file, libdrmframework_jni.so is missing from the /system/lib/ folder. You may also find that the DrmProvider.odex and DrmProvider.apk files are missing from the /system/app/ folder. It seems that standard Android AVD images do not include these files. In order to circumvent this, you can build the Android platform from source (see http://source.android.com/source/initializing.html); your AVDs should now include the relevant DRM files. (Note: pulling the .so off of your device and pushing them to the emulator will generally not work.) You can also, of course, just create an AVD for 4.1 Jelly Bean: AVDs that target 4.1 appear to include those missing files and should be able to download applications easily.
Google Play on an emulator.
Move along, not too many apps to see here!
Downloading Solitaire. Side note: I’m pretty good at Solitaire.
Circumventing Google Play Filters
As you browse the Play Store you’ll notice a startling lack of available applications. The Google Play Store filters the apps that you can view based on a handful of factors relating to hardware, software, and carrier. You can find most filters listed here: http://developer.android.com/guide/google/play/filters.html
Depending on which features you give your AVD, you will see a variety of available apps. However, you’ll still be unable to view a great deal of what the store has to offer simply because your AVD lacks a great many features. Therefore, we’ll need to get our hands dirty with the innards of the Google Play code (this could probably be accomplished in a few other ways, but this was the most practical.)
The basic idea is to capture and mock all of the device identifying information and metadata that Play compiles before it is sent off on the wire. You’ll first need to unzip each APK: unzip {apk} -d {out_dir}. Then, remove the META-INF folder within each (we’ll re-sign each APK later.) Use baksmali on the classes.dex of both Phonesky.apk and GoogleServicesFramework.apk. Now you’ll have access to the smali code for each APK.
Inside the decompiled GoogleServicesFramework you’ll find a file entitled /com/google/android/gsf/checkin/CheckinRequestBuilder.smali. Poke around a bit, and you’ll notice that it contains a host of device identifying information, all of which we must intercept and mock. Inside the decompiled Phonesky you’ll find two files entitled /com/google/android/finsky/utils/DeviceConfigurationHelper.smali and /com/google/android/finsky/utils/VendingUtils.smali respectively. Again, each file contains device identifying information that Google Play will eventually serialize, send off into the cloud, and use to filter the apps that you can view on the store.
So now that we know what data is being sent, how do we intercept it and mock it? First, you’re going to need data to mock. This is relativley simple, as you can pull most of that information from a real phone using some combination of adb shell getprop, adb shell pm, and adb shell dumpsys. On the other hand, you can build a simple application that pulls all of this data and dumps it out in a neat little file. The next step is to build a framework for mocking data. I built a java class composed entirely of static methods (it is very easy to hand insert into smali code (with some register finagling)) that I compiled and then decompiled back into smali. Inside each of the decompiled Google APKs, make the appropriate directories for your classes package, and copy over the smali file. You should now be able to call any of your static methods from Google code.
Now its a matter of using grep to find the right method calls in the files mentioned above. For each method found, comment it out, and insert your own, mocked method call. For example, in DeviceConfigurationHelper.smaliI’ve replaced the call
invoke-virtual {v4}, Landroid/content/pm/PackageManager;->getSystemAvailableFeatures()[Landroid/content/pm/FeatureInfo;
with a call to my own getSystemAvailableFeatures() method. Finally, you’ll need to use smali to re-compile all of the code back into a classes.dex file (replace the old ones in Phonesky and GoogleServicesFramework respectively), re-zip into each into an apk (including GoogleLoginService), and re-sign each using jarsigner. Push them onto the emulator as always and you should be good to go.
Play thinks we’re a Galaxy Nexus!
Downloading Angry Birds Space.
Playing our downloaded app on the emulator!
For now, you can only download and install free apps. As you might imagine, getting paid apps on an emulator is a bit trickier. We’ll save that for a later post.
Happy hacking,
-Daniel Joyce, Software Engineer
You may wish to reference the following:
Smali and Baksmali
Android Api
Google Play Filters
There’s no doubt that Amazon’s Kindle Fire has been a runaway success since it launched Q4 ‘11. Part of the success is due to its affordable price of $199, enabling it to appeal to a wider audience – something many other Android tablets in the past have struggled to achieve.
However, the caveat of the affordable tablet not being Google certified predominantly means it doesn’t have access to Google’s content services, instead, relying on Amazon’s own offerings. Although Amazon’s application store is nothing to sneeze at, its 31,000 apps (March 2012) is a small handful compared to Android’s share of almost 500,000 apps. It boiled down to this: purchase a cheaper tablet without some of the Google apps and features, or kiss a bunch more hard earned benjamins goodbye for one with the whole Google experience.
But then, why can’t we have both?
Google answers and fills this void with the recently released Nexus 7; a light, affordable and well-built, tablet sporting the latest Android 4.1.1 ‘Jelly Bean’ OS. Announced at Google I/O 2012, the Nexus 7 aims to place a Google Certified Android tablet into more hands, all while maintaining good user experience through the harmony of leading edge hardware and thorough software.
Although released at different time frames (Q4 ’11 for the Kindle and Q3 ’12 for the Nexus), both tablets target a similar market given their likeness in form factor and price point. With both the Kindle Fire and Nexus 7 in our labs we put them through the ringer by performing the entire Apkudo Device Analytics suite on both tablets and characterizing their respective user experiences. If you’ve got a Kindle Fire and you’re wondering how the Nexus 7 stacks up against it, look no further.
Display
The Kindle Fire and Nexus 7 sport pretty extrinsically similar displays. Both are IPS. Both feature Corning scratch-resistance glass. Both span 7”. Both can render 16 million colors. Both support multi-touch. However, that’s about where abundance of similarities ends. To start, the Nexus 7 has a significantly wider viewing angle. Placed within a sealed, light absorbing box, the Nexus 7 loses 50% lux at a 45 degree angle as opposed to viewing it straight on. Now, this might seem like a lot, but it’s one of the best results we’ve seen, and significantly better than the Kindle Fire’s loss of almost 90% lux given the same setup.
Another area where we often see shortcomings is the color temperature of displays. Device displays (both phones and tablets) often appear as though they were lit up by a solid blast of UV lighting, completely ruining the experience of anything projected onto the display. The Kindle Fire does reasonably well here, clocking in at 7600K; slightly high, but not enough to be causing any detrimental color tints. However, the Nexus 7 really brings it home with an average temperature of 6800K (a widely accepted ideal is 6500K), producing colors that appear pleasantly neutral without any noticeable tints.
Figure 1: Kindle Fire
Tablets are a great way to display photos and such due to their combination of good portability and a relatively large screen. As you’ll see in Figure 1, despite the Kindle Fires’ display’s ability to support 16 million colors, its photo gallery proves to be the weakest link as significant banding is evident. This might cause nice images to appear choppy, especially if there’s a nice gradual gradient – a sunset, for example.
Figure 2: Nexus 7
On the other hand, the Nexus 7 performs significantly better. We can still spot small amounts of banding particularly near the dark end of the spectrum in Figure 2, so it’s not perfect, but definitively smoother. Does this make or break a device? Not entirely, but these small things all add up to shape the user experience. Not only is good hardware important, but the software needs to be able to utilize it – kinda like having a roaring V8, but then an electronic speed limiter stuck at 30mph.
Touch Screen
Not all touch screens are created equal, and the digitizers used in the Kindle and Nexus are no exception. Although both demonstrate very good touch accuracy throughout the touch panel, the Kindle excels at edge tracking where the Nexus 7 experiences some slightly abnormal traits. Where a trailing edge is concerned on the Nexus 7, touch points develop a tendency to stick along the edge like a meniscus. Although not a deal breaker by a large margin, it is in stark contrast to the Kindle which tracks straight and true all the way to the edge, resulting in a higher R-squared value that corresponds to the straight-line relationship between each point and its line of best fit. So what does this all mean? Basically, the Kindle Fire will detect your finger with better pin-point accuracy than the Nexus 7… just.
Figure 3: Nexus 7
Figure 4: Kindle Fire
Both devices claim to support multi-touch – the ability to recognize the presence of two or more points of contact with the surface. While technically correct, they do support more than 1 simultaneous touch, the Kindle only supports 2 touches. The Nexus 7 on the other hand maxes out at 10 detectable touches (we tried 11 points with an extra hand, but alas, 10 it is). Besides the limitation of 2 touch points, the other characteristic that really hurts the Kindle is the loss of all points upon a 3rd point present on the screen. While you might not actually USE three points too often, the accidental presence of a 3rd point is not unheard of, especially when you’re hammering away at a favorite game.
Audio
Audio analysis is also performed, with the Nexus 7 outclassing the Kindle Fire in almost every aspect. One way of determining the accuracy of audio reproduction is by measuring the Total Harmonic Distortion (THD), that is, the amount of unwanted overtones (harmonics) arising from the playback of a particular note. At a fundamental frequency of 1kHz measuring harmonics up to 20Khz, THD on the Nexus 7 is low enough to be largely unnoticeable throughout low, medium and high volumes. Things aren’t quite as smooth for the Kindle, with up to 18% THD at lower volume levels. Noticeable amounts are around 1% to 5%.
Another way of determining audio quality is by measuring the amount of background noise compared to the intended signal – that is, the ratio between everything you want to hear, against everything that you don’t. The difference between the Nexus 7 and Kindle Fire at average volume settings of 50% is night and day. Positioned as a media device, the Nexus 7 doesn’t disappoint, producing a clean signal with a high SNR (Signal-to-Noise Ratio) of 91.5dB. On the other hand, the Kindle Fire disappoints slightly, with significantly poorer performance. As seen below, the Nexus 7 produces an extremely clean signal, whereas the Kindle appears very messy. End result? You’ll hear clearer sound and less hissing on the Nexus 7.
Figure 5: Nexus 7
Figure 6: Kindle Fire
Volume levels are also much better on the Nexus 7. Through the headphone jack, the Nexus 7 offers peak-to-peak amplitudes that are up to twice as high as the Kindle Fire (950mV vs 1900mV). Peaking at over 90dB at 3ft, the external speaker on the Nexus 7 tells a similar tale with an approximate 20dB gain over the Kindle Fire. Let’s face it. You buy a tablet to consume different types of media. These results are important because a high and clear output volume ensures the clarity of sounds during various media file playback so you can hear and enjoy them better.
Browser
We also performed a few quick browser tests to demonstrate some performance differences. Besides various standard benchmarks freely available, a speed test is also performed to determine the overall speed at which the device and default browser open up a list of top 25 webpages. As a testament to the overall speed of Jelly Bean and the Quad+1 core Tegra 3 processor, the Nexus 7 powers through each test and benchmark with significantly better results than the Kindle.
Conclusion
Combining leading edge hardware and supporting software in an affordable package makes the Nexus 7 the true winner amongst Android tablets. At the same price point as the popular Kindle Fire, the Nexus 7 increases performance in many aspects such as display, audio, touch screen and browser performance, giving it the cost and user experience advantage to compete with more expensive offerings. The inclusion of stock Android on the Nexus 7 presents users with a raw, unadulterated experience without compromising access to Google services, enabling it to reach a market otherwise unavailable to the Kindle Fire.
All in all, the Nexus 7 is an outstanding device that encompasses and builds upon many of the defining aspects of the Kindle Fire that made it the runaway success that it was.
-Ben Tseng
Director, Device Analytics
apkudo 