Fresh off the heels of Apkudo’s FierceWireless “Fierce 15” award, Josh Matthews will appear on Bloomberg TV’s famed in-depth investor program “Taking Stock with Pimm Fox” today at 5:20 pm EST! Josh will sit down with Pimm to discuss what makes Apkudo fierce, the state of Android, and how Apkudo helps mobile network operators, device manufacturers, and application developers make fierce products.

Watch “Taking Stock with Pimm Fox” on Bloomberg TV at 5:20 pm EST!
Click here to find Bloomberg TV in your area, or watch it online!

Did you miss Josh’s last appearance on “Taking Stock”? No worries, you can check it out here:
How Do You Define an App? Part 1
How Do You Define an App? Part 2

Enjoy!!

Check out his slides, here!

Thanks to all the wonderful folks at AnDevCon and the Android developers that attended David’s class! We hope you enjoyed it!

May 29, 2013 – Baltimore, MD – Apkudo, the Android innovation company, today announced the release of a case study with wireless carrier Cincinnati Bell discussing how their use of the Apkudo Approved program on one of their Android devices saved the company at least half a million dollars in device return associated costs over the course of a year. Apkudo Approved objectively analyzes the user experience of a carrier’s Android devices, generating millions of data points against potential user and app scenarios allowing carriers to better understand, standardize, stabilize and create a better user experience. Cincinnati Bell has since mandated that all of their Android devices must now complete the Apkudo Approved program before release to consumers.

Android is a huge opportunity for wireless carriers, having shipped in 75% of  smartphones sold in Q1 2013. With hundreds of makes and models released yearly, Android gives consumers unprecedented choice and represents a critical element in a regional carrier’s growth strategy. Android can also bring frustration to carriers when releasing these devices. Cincinnati Bell was no exception, having experienced the difficulty of releasing these complex devices with mixed results.

In order to reduce the dreaded ‘no trouble found’ device returns (associated as poor user experience) Cincinnati Bell enlisted the help of Apkudo to analyze the user experience of one of their high-tier Android devices. The Apkudo Approved program uncovered a number of key user experience issues, allowing Cincinnati Bell to present objective, third-party to the OEM to assist in mitigating the issues before the device’s release. After the device was launched Cincinnati Bell calculated at least a $500,000.00 savings from potential device return-associated costs over the course of a year for this one device, then moved to mandate that all devices will be Apkudo Approved to realize similar savings. Cincinnati Bell saved time and money while making their customers happy.

To learn more about how Apkudo Approved helped Cincinnati Bell mitigate issues early and save half a million dollars, please download the case study:

https://www.apkudo.com/customers.html

About Apkudo
An Android user experience innovation company, Apkudo is pioneering analysis technologies that deeply and holistically test pre-release Android devices against millions of different possible use-cases and activities to discover bugs and refine the user interface and experience, taking devices from bad to good, and good to great. Apkudo works with many of the world’s largest device manufacturers, including Samsung, Sony, HTC, and LG, and carriers such as MetroPCS, Cricket and Cincinnati Bell.

Apkudo is headquartered in Baltimore, MD. The Apkudo team includes deep research expertise with the Android operating system including optimization, usability and performance testing, and is focused on helping the ecosystem deliver the best possible user experience to Android device owners. Learn more at http://www.apkudo.com and email hello@apkudo.com for additional information.

“We’ve had the pleasure of working with a number of the United State’s largest Tier 2 carriers – such as MetroPCS and Cricket – by collecting user experience data on their pre-release Android devices, exposing likely areas of consumer satisfaction and dissatisfaction,” said Josh Matthews, Apkudo CEO and co-founder. “Apkudo is helping device manufacturers and carriers improve the overall quality of Android devices. We’re excited to use our Associate Membership with the CCA as a platform to engage with regional carriers and show them how to do the same.”

“I am delighted to welcome Apkudo to CCA,” said CCA President & CEO Steven K. Berry.  “CCA’s associate members play an important role in the competitive carrier ecosystem, and Apkudo’s offers unique services and tools to assist in the delivery of next generation networks through Android devices.  Apkudo’s industry perspective will certainly be a valuable addition for the entire membership, and we are glad to have them on board.”

About Apkudo

Apkudo helps mobile operators and device manufacturers launch successful Android devices. An Android user experience innovation company, Apkudo is pioneering analysis technologies that deeply and holistically characterize and compare the user experience, taking devices from bad to good, and good to great. Starting early in the device approvals process and continuing throughout friendly user trials, the Apkudo Approved data-informed approach speeds time to market, ensures issues are alleviated early, and significantly reduces device return associated costs. The end result is a device that exceeds consumer expectations.

Apkudo is headquartered in Baltimore, MD. The Apkudo team includes deep research expertise with the Android operating system including optimization, usability and performance testing, and is focused on helping the ecosystem deliver the best possible user experience to Android device owners. Learn more at http://www.apkudo.com and email hello@apkudo.com for additional information.

About the Competitive Carriers Association

CCA is the nation’s leading association for competitive wireless providers and stakeholders across the United States. The licensed service area of CCA’s more than 100 members covers 95 percent of the nation. Visit http://www.competitivecarriers.org.

The Rise of Android: 2005-2012

Created by: MBAOnline.com

One thing that can be a little confusing with Python is how packages work. Packages let you group your modules together and gives you a nice namespace. You can read all about them in the Python docs.

Something that’s pretty confusing is that importing a package does not mean that any modules inside that package are loaded.

Imagine a very simple package called testing, with a single foo module. E.g:

testing/
    __init__.py
    foo.py

The foo module might look something like:

def bar():
    return 'bar'

Now, you might expect to be able to write code such as:

import testing
print(testing.foo.bar())

However, trying this won’t work, you end up with anAttributeError:

Traceback (most recent call last):
  File "t.py", line 2, in 
    testing.foo.bar()
AttributeError: 'module' object has no attribute 'foo'

So, to fix this you need to actually import the module. There are (at least) two ways you can do this:

import testing.foo
from testing import foo

Either of these put testing.foo into sys.modules, andtesting.foo.bar() will work fine.

But, what if you want to load all the modules in a package? Well, as far as I know there isn’t any built-in approach to doing this, so what we’ve come up with is a pretty simple function that, given a package, will load all the modules in the package, and return them as a dictionary keyed by the module name.

def plugin_load(pkg):
    """Load all the plugin modules in a specific package.

    A dictionary of modules is returned indexed by the module name.

    Note: This assumes packages have a single path, and will only
    find modules with a .py file extension.

    """
    path = pkg.__path__[0]
    pkg_name = pkg.__name__
    module_names = [os.path.splitext(m)[0] for m in
                    os.listdir(path)
                    if os.path.splitext(m)[1] == '.py' and m != '__init__.py']
    imported = __import__(pkg_name, fromlist=module_names)
    return {m: getattr(imported, m) for m in module_names}

There are plenty of caveats to be aware of here. It only works with modules ending in .py, which may miss out on some cases. Also, at this point it doesn’t support packages that span multiple directories (although that would be relatively simple to add). Note: code testing on Python 3.2, probably needs some modification to work on 2.x (in particular I don’t think dictionary comprehensions work in 2.x).

If you’ve got a better way for achieving this, please let us know in the comments.

Benno Leslie

Friend of Apkudo Daniel Box, Quality Assurance Manager over at Mubaloo, recently completed the intense task of creating an Android testing MindMap. As you can see, there’s a lot to take into account when testing an Android app or website. Have a look below and if you’d like to download it yourself, check it out here.

Android Testing MindMap by Daniel Box

Many thanks to Dan for including us in the MindMap. Be sure to follow him on Twitter @dnlkbox!

• Take a look at the hint and photo and try to guess what the mystery device is.
• Post your answers in the comments section below. Each person to get it right will be entered into a drawing to win a free Apkudo t-shirt (they’re pretty badass).
• When posting your answer, be sure to include your Twitter address so we can get in touch with you. No Twitter address? That’s cool – just check back to the blog to see if you won.
• All answers must be submitted within 5 days of the post, and only one answer per person will be accepted.

Accept or deny my challenge, however “impossible” is a word only found in the dictionary of fools.

Here is your hint for this challenge:

The edge of a knife, the tip of a sword

In the US this brand is often ignored 

Both TV and phone share the same name

You’ll need more than the model to win at this game

Composed of mixed origin, like a Prius or Leaf

Plus the fact that its waterproof is quite a relief 

Include the whole name or your answer we’ll forgo

Now put your guess in the comments below

Best of luck to everyone!

-Asa Gismervik, Lab Manager
@asagismervik

Android HierarchyViewer in Tree Mode on the Galaxy SII

So how does it actually work? The HierarchyViewer utilizes a service running on the device called ViewServer located in

frameworks/base/services/java/com/android/server/ViewServer.java

When launched, ViewServer opens up a socket on local port 4939 and receives commands from a client (usually HierarchyViewer) to dump the current view state of the device. The ViewServer dispatches these calls via binder to the ViewRoot class, which serializes the view state and transmits it to the client over the socket. The WindowManagerService manages the ViewServer and provides a hook (via binder service call) to spawn the service.

A client can only launch the ViewServer if the device’s properties ro.debuggable=1 and ro.secure=0, and the client contains manifest.dump permission (in the usual case, HierarchyView, as the client, has these permissions via adb). Although Google Engineer Romain Guy has been very adamant that the ViewServer is not enabled for production devices, we’ve found a pretty easy way to bypass its restrictions if you have root. The portion of the code dictating the restrictions can be found in line 5501 of WindowManagerService.java and is shown below.

if (!checkCallingPermission(Manifest.permission.DUMP, "startViewServer")) {
return false;
}
[/sourcecode]

One can go about bypassing these restrictions in two ways: patch the WindowManagerService to allow anyone to spawn the server _or_ modify the ro.debuggable and ro.secure properties in the default.prop file. Because of the potential negative ramifications of modifying the ro.debuggable and ro.secure properties in Android (not to mention the fact that the default.prop file is part of the ramdisk, which makes editing it a bitch), we decided to patch the WindowManagerService. The patch is minimally invasive and provides a good intro into the power of patching the Android framework.

In order to perform this patch you will need the smali/baksmali tools, dextopt-wrapper, and access to a rooted device with BusyBox installed. If you have no idea what these tools are or how they work, you may want to do some reading first. We’ve only tested this on the HTC One S and a 4.0.3 Galaxy S II, so if you brick your device we’ll feel bad but can’t really do anything about it (hey, maybe we’ll send you a t-shirt).

Step 1 – Backup the phone’s /system/framework/ on your machine

$ mkdir ./system
$ mkdir ./system/framework
$ adb pull /system/framework/ ./system/framework/

Important: Make sure the directory structure matches the device’s for step 3.

Step 2 – Grab the bootclasspath from the device

$ adb shell
# echo $BOOTCLASSPATH

Copy this path.

Step 3 – Disassemble (baksmali) the services odex

$ baksmali -x -a 14 -c <copied bootclasspath> ./system/framework/services.odex

-x = odex
-a = api level 14
-c = classes (loaded from the bootclasspath, separated by colon)
If you’ve done this correctly you will now see a directory called ‘out’, otherwise verify you’ve pulled the jars and bootclasspath correctly.

Step 4 – In your favorite text editor, open up WindowManagerService.smali

$ emacs out/com/android/server/wm/WindowManagerService.smali

Search for isSystemSecure(). This is the method they use (only for ViewServer) to verify the system is not secure. We happened to find this on line 4815. Note: In 4.0 they moved WindowManagerService into the wm directory, it may just be in out/com/android/server/

Step 5 – Patch the return value of isSystemSecure() to always return false

.prologue
.line 5965
const-string v0, "1"

const-string v1, "ro.secure"

const-string v2, "1"

invoke-static {v1, v2}, Landroid/os/SystemProperties;->get(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;

move-result-object v1

invoke-virtual {v0, v1}, Ljava/lang/String;->equals(Ljava/lang/Object;)Z

move-result v0

if-eqz v0, :cond_22

const-string v0, "0"

const-string v1, "ro.debuggable"

const-string v2, "0"

invoke-static {v1, v2}, Landroid/os/SystemProperties;->get(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;

move-result-object v1

invoke-virtual {v0, v1}, Ljava/lang/String;->equals(Ljava/lang/Object;)Z

move-result v0

if-eqz v0, :cond_22

const/4 v0, 0x1

:goto_21

return v0

:cond_22
const/4 v0, 0x0

goto :goto_21
.end method
[/sourcecode]

We can see from above that the v0 register contains the return value of this method. Let’s add a simple

const/4 v0, 0x0

in the line 41 above return v0 to ensure this method will always return false, giving the WMS the go ahead to spawn view server. Easy enough, right?

Step 6 – Reassemble into Dex

$ smali ./out -o classes.dex

-o = output file (classes.dex is the default name for apks in Android)

Step 7 – Zip dex

$ zip services_hacked.jar ./classes.dex

Step 8 – Remount /system

$ adb remount

OR

$ adb shell
# mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system

Step 9 – Push dexopt-wrapper and services_hacked.jar onto /data/local/tmp

$ adb push ./services_hacked.jar /data/local/tmp
$ adb push ./dexopt-wrapper /data/local/tmp

Step 10 – Optimize the services_hacked.jar into services_hacked.odex

$ adb shell
# cd /data/local/tmp
# chmod 777 ./dexopt-wrapper

Important: We need to feed in the bootclasspath into dexopt, but because we have modified a member of that class path, we need to make sure we don’t include it. To do this, copy bootclasspath (via method in step 2) and omit the “:/system/framework/services.jar”. Forgetting this step will likely result in a boot loop.

# ./dexopt-wrapper ./services_hacked.jar ./services_hacked.odex <copied bootclasspath excluding ":/system/framework/services.jar">

Our final command looked something like

./dexopt-wrapper ./services_hacked.jar ./services_hacked.odex /system/framework/core.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/framework2.jar:/system/framework/android.policy.jar:/system/framework/apache-xml.jar:/system/framework/filterfw.jar:/system/framework/sechardware.jar:/system/framework/wimax.jar

A great way to check that this command has worked is to see that the /system/framework/services.odex and the services_hacked.odex are nearly identical in size. The two files shouldn’t differ by more than 1KB.

Step 11 – Copy in the signature

Each odex is signed with a 20 byte signature located at a 52 byte offset within the odex. Let’s trick the OS into thinking our hacked odex matches the system signature by copying it from the original

# busybox dd if=/system/framework/services.odex of=/data/local/tmp/services_hacked.odex bs=1 count=20 skip=52 seek=52 conv=notrunc

if = input file
of = output file
bs = block size (1 byte)
count = number of blocks
skip = input file offset
seek = output file offset
conv=notrunc – don’t truncate the output file.

Step 12 – Replace the original odex with the hacked version

# dd if=/data/local/tmp/services_hacked.odex of=/system/framework/services.odex

Step 13 – Let the device reset

The previous step should result in a software reset, and it may be worthwhile to logcat as this loads. If you see the Dalvik logs stating “some deps went away” or “not all deps represented” then you’ve definitely screwed up step 10. These errors are a result of passing in the wrong bootclasspath to dexopt-wrapper. If this causes a bootloop, see step 16.

Step 14 – Launch ViewServer

WindowManagerService provides a (heavily undocumented) hook into spawning ViewServer. To start the server on port 4939,

$ adb shell service call window 1 i32 4939

To stop the server

$ adb shell service call window 2

To check if the server is running

$ adb shell service call window 3

If ViewServer is running, you should see

Result: Parcel(00000000 00000001   '........')

Step 15 – Launch HierarchyViewer

$ ./sdk/tools/hierarchyviewer

You will now see your rooted phone available in the HierarchyViewer. Double click on a layout to introspect on that view tree.

Step 16 (if you get stuck in a bootloop)

Don’t panic! Simply push the backed up services.odex to system/framework to revert to your previous state.

$ adb push ./system/framework/services.odex /system/framework/services.odex

Note, you should make sure you don’t reboot when if you get a bootloop. In some cases the OS will not be at a state at which your SU binary is functional (I’ve seen it segfault many times). If you don’t have root your only option is to reflash the device via fastboot or other bootloader.

Although this API is not meant to be public, it’s extremely useful to developers when debugging their UI. It’s a shame you have to jump through so many hoops to obtain this functionality. I hope to see Android keep the ViewServer in further builds and provide a means of using the HierarchyViewer on production phones as well.

(As an aside: we refered to HierarchyViewer as the “usual client” of ViewServer above. Other clients are certainly possible. One issue with HierarchyViewer is it’s pretty damn slow – we’ve been working on our own optimized client over here at Apkudo, which will be the subject of a future blog!)

Happy Hacking,

David Teitelbaum
VP of Engineering
@davtbaum

We’d just pulled ourselves from bed after a wonderful party at Knuckle’s Bar the night before replete with drinks, food, and a lot of laughs. We met some really excellent people and reconnected with plenty of others. While it’s true that conferences can take a lot out of you (energy and electrolytes, mostly), they definitely give back much, much more. So huge thanks to all of you – our new friends, our old friends, and even those few devs we didn’t get a chance to meet. We hope our paths cross again soon!

As promised here are some highlights from AnDevCon III!

Look Out, Leader Boards…

We started off the show with a quick 30 minute session, “Who Needs Thumbs? Reverse Engineering Scramble With Friends,” on Tuesday, May 15. According to the AnDevCon organizers, ours was the highest attended session of the conference! Congrats to David and Josh on their great class and thank you to all who attended! We recorded the session and you can check it out on YouTube in a 3 part series. Unfortunately, Steven Spielberg cancelled on us at the last minute and James Cameron was all, “I’m only doing Avatar movies from now on!” so I had to record this myself. Consider it an homage to the “bootleg movie theater” style films of yore.

Who Needs Thumbs? Part 1

Who Needs Thumbs? Part 2

Who Needs Thumbs? Part 3

We’ve also uploaded the slides to Slideshare so click here to view, download, and share with your pals.

When Lightning Strikes

We went old school with this recording. Good ole tripod. In case you missed Josh’s 5 minutes of fame you can take a gander here to get a sneak peek at our new App Analytics UI, to hear about Ape, and our work with OEMs and Operators via Apkudo Device Analytics.

Josh Matthews’ AnDevCon III Lightning Talk

Android Developers Know How to Party

Wednesday night marked the second Apkudo Drink-Up. There were drinks (many, many drinks), food, and even a themed drink: The Apkudo. What’s The Apkudo you ask? Maker’s Mark on the Rocks. Like Apkudo App Analytics, it’s uncomplicated, easy, and awesome. Perfect drink for a perfect night. Thanks to everyone who came out, we had an absolute blast! Check out a few pictures below. The rest are on our Facebook page. Spot yourself in one of the pics? “Like” us and we’ll tag you!

Once again, thanks to everyone who helped make AnDevCon III a success – from BZ Media to the Apkudo staff that held things down in Baltimore to all of the bad-ass attendees, we couldn’t have done it without you!

Until next time…

-Kate Lyons, COO
@katelyons3
@apkudo