I found an interesting error today. The complete error, copied below without the stack trace, is:
Original error: packageAndLaunchActivityFromManifest failed. Original error: Command '/home/afwang/lib/android/sdk/build-tools/24.0.0-preview/aapt dump badging /tmp/201642-2029-11s8dnl/appium-app.apk' exited with code 1 (WARNING: The server did not provide any stacktrace information)
Running the command explicitly myself revealed something like ERROR getting 'name' attribute: attribute is not a string value.
This is a bug within aapt itself, and as you can tell from the build tools version, the bug is also apparent in the next stable release of the build tools. Here is some links showing that the bug has been around for quite a while:
- http://stackoverflow.com/questions/17008364/aapt-error-getting-androidname-attribute-attribute-is-not-a-string-value
- https://code.google.com/p/android/issues/detail?id=46311
This bug will affect you if certain manifest elements' attributes refer to XML string resources using the @string/string_name format. Some example manifest elements where this bug can occur are <meta-data ...> and <category ...>.
In any case, this bug can cause Appium to fail because Appium needs aapt to retrieve the package name and launch activity from the APK.[1]
My workaround for this bug is to explicitly tell Appium which application package and activity to launch, so Appium does not need to run aapt dump badging. As an example in Java code:
caps.setCapability(AndroidMobileCapabilityType.APP_PACKAGE, "com.example.app");
caps.setCapability(AndroidMobileCapabilityType.APP_ACTIVITY, ".MainActivity");
If this aapt bug has ever affected you, please log into your Google account and "star" the issue to increase its visibility; hopefully, it'll let Android's system developers to prioritize fixing aapt. 
[1] Appium uses the package name and launch activity's name to wait until the activity is launched before handing control back to your test code.
