POST appium/app/strings not working with the new gradle build system

In order to extract the texts from the application appium is running “POST appium/app/strings” :
this command is suppose to return all the strings from the strings.xml as a mapped array: => {“coupon_end_date”:“Until <font color=”#BF0000">%1$s",“register_member_info”:“Member Information”,“quantity_default”:“1”,“global_profile_title”:“Additional Information”,“abs__searchview_description_search”:“Search”,“action_forgot_password”:“Forgot your password?”,“checkoutprogress_ship”:“Shipping”, … etc …

After developers changed android app to gradle build system this command is returning an empty array:
POST appium/app/strings
=> {}

Any ideas why is not this working?


I have the same issue when using the Mac Appium server with an Android application (.apk).
I reproduces this issue on the latest official released version (v1.3.4), as well as on the new beta version (1.3.5).

I had some reports (running on Saucelabs) that this issue is reproducible also on a Linux Appium server - version v1.3.4.

The log from the local run on the Mac server is below:

info: [debug] java -jar "/Applications/" "stringsFromApk" "/Users/rakuten/Desktop/seb/Ichiba_fix.apk" "/tmp/" en

info: [debug] No strings.xml for language 'en', getting default strings.xml

info: [debug] java -jar "/Applications/" "stringsFromApk" "/Users/rakuten/Desktop/seb/Ichiba_fix.apk" "/tmp/"

warn: Error getting strings.xml from apk

info: [debug] Exception in thread "main" brut.androlib.AndrolibException: Could not decode arsc file
 at brut.androlib.res.decoder.ARSCDecoder.decode(
 at brut.androlib.res.AndrolibResources.getResPackagesFromApk(
 at brut.androlib.res.AndrolibResources.loadMainPkg(
 at brut.androlib.res.AndrolibResources.getResTable(
 at io.appium.apktools.Main.main(
Caused by: Expected: 0x001c0001, got: 0x00000000
 at brut.util.ExtDataInput.skipCheckInt(
 at brut.androlib.res.decoder.ARSCDecoder.readPackage(
 at brut.androlib.res.decoder.ARSCDecoder.readTable(
 at brut.androlib.res.decoder.ARSCDecoder.decode(
 ... 5 more

I saw that there are two similar issues already opened, but from I saw tha cause is not the same:

The discussions in those two issues make the appium_apk_tools package the main cause for this error.
This doesn’t seem to be the case, because I ran the same test and using the same apk on Windows Appium (v1.3.4.1) server, and the strings were retrieved correctly:

info: [debug] java -jar “C:\AppiumForWindows\node_modules\appium\node_modules\appium-adb\jars\appium_apk_tools.jar” “stringsFromApk” “C:\Ichiba_fix.apk” “C:\Users\SEBAST~1.ALB\AppData\Local\Temp\” en
info: [debug] No strings.xml for language ‘en’, getting default strings.xml
info: [debug] java -jar “C:\AppiumForWindows\node_modules\appium\node_modules\appium-adb\jars\appium_apk_tools.jar” “stringsFromApk” “C:\Ichiba_fix.apk” “C:\Users\SEBAST~1.ALB\AppData\Local\Temp\”
info: [debug] executing cmd: C:\adt-bundle-windows-x86\sdk\platform-tools\adb.exe -s emulator-5554 push “C:\Users\SEBAST~1.ALB\AppData\Local\Temp\\strings.json” /data/local/tmp
info: [debug] Pushing command to appium work queue: [“updateStrings”,{}]
info: [debug] [BOOTSTRAP] [debug] Got data from client: {“cmd”:“action”,“action”:“updateStrings”,“params”:{}}
info: [debug] [BOOTSTRAP] [debug] Got command of type ACTION
info: [debug] [BOOTSTRAP] [debug] Got command action: updateStrings
info: [debug] [BOOTSTRAP] [debug] Loading json…
info: [debug] [BOOTSTRAP] [debug] json loading complete.
info: [debug] Responding to client with success: {“status”:0,“value”:{“abs__action_bar_home_description”:“Navigate home”,“abs__action_bar_up_description”:“Navigate up”,“abs__action_menu_overflow_description”:“More options”,“abs__action_mode_done”:“Done”,“abs__activity_chooser_view_see_all”:“See all…”,“abs__activitychooserview_choose_application”:“Choose an application”,“abs__searchview_description_clear”:“Clear query”,“abs__searchview_description_query”:“Search query”,“abs__searchview_description_search”:“Search”,“abs__searchview_description_submit”:“Submit query”,“abs__searchview_description_voice”:“Voice search”,“abs__shareactionprovider_share_with”:“Share with”,“abs__shareactionprovider_share_with_application”:“Share with %s”,“account_dashboard_btn_register”:“Register”}

I checked and besides the default appium_apk_tools which is called to retrieved to get the strings.xml from the apk, in the Appium folder there is only one other appium_apk_tools file marked with version 1.6. So I am assuming that the default package called is actually the 1.6 version. I also tried overwriting the default apk_tool with the latest version and it still works correctly.

So, my guess is that the apk_tool doesn’t manage to dump correctly to the default path the strings.xml file which he retrieves from the apk file. From what I saw the error is due to the fact that the file dumped by the apk_tool is not reachable, and because that the apk_tools cannot retrieve the file from the app.

That is as far as my investigation has gone, as I didn’t manage to open the location where the strings.xml file is dumped (the path is shown in the logs, but I am not very familiar with Mac OS systems to successfully access it), or to access the location of the appium_apk_tool and replaced with the latest one - to test is actually the tool is broken.

If anyone else has more information, please share it.

One small update on system configurations I tested on:

Windows 7 X86 - Appium
Mac OS - 10.10.2 - Appium 1.3.4 (and afterwards 1.3.5 beta)

On both systems I had the latest version of Java (8?) and all the packages from Extras and Tools (from Android bundle) updated to the latest versions.I also made sure that all the files for the Android 4.3 and 4.4 (the versions that the real device and the AVDs were using) were up to date.

Also, according the release page for Appium 1.3.4, when an Android app is tested on a machine that has Java 7, then apk_tool version 2.0.0 should be called:

For some reason, this doesn’t seems to be the case in my tests.