My app is split into modules and I am trying to run instrumentation tests on one of the library module. Currently I’m using spoon to run my tests and I’m able run it only with the test apk and not needing to have a app apk. VDT instrumentation does not seem to be happy with that. Is there anyway I can just use the test apk to run the tests.
Here is how I would do it if I have to run the tests with adb
adb -s emulator-5554 shell am instrument -w com.xxx.mobile.android.commons.test/android.support.test.runner.AndroidJUnitRunner
1 Like
@viktorbenei Can you please suggest whether I have added the correct tags here so that it gets noticed.
Hey @senthilkumarv! 
Noticed you issue, all tags are correct. 
Sorry for the delay.
So basically it might be possible, however didn’t tried to setup the same as you would like to so I can only suggest to try using the test apk in both input: APK Path and Test APK Path, if the instrumentation does not depends on the app APK then it might will be ignored and it may start your test.
Did you tried that already?
Yes I did. It complains with an error saying test apk same as app apk 
Waiting for test results
- Validating
Failed to get test status, error: Failed to get test status: INVALID(TEST_SAME_AS_APP)
Is it possible to generate a dummy APK to set as the app APK? If not then please ask Firebase TestLab straight on their open slack channel to get the fastest solution.
@tamaspapik Looks like a Firebase TestLab constraint. I have solved this for now using a dummy apk. Thanks for the suggestion.
2 Likes
Thank you for the help in finding a solution to this problem. I wanted to add my research into this problem and leave it here for reference to help others.
Problem: When running instrumentation tests on Bitrise for an Android library project, Bitrise may throw an error where it could not find an app APK on the workflow step: Android build for UI testing.
The error you may see is:
Export APKs:
Export [ libraryname-debug-androidTest.apk => $BITRISE_DEPLOY_DIR/libraryname-debug-androidTest.apk ]
Could not find the exported app APK
Bitrise found my test APK, but did not find my app APK. Even though it did run the gradle task to compile an app APK: /bitrise/src/gradlew ":libraryname:assembleDebug" ":libraryname:assembleDebugAndroidTest", an app APK was not created because this is an Android library project, not an app.
As stated earlier in this post, the solution to this problem is to create a fake app APK that Bitrise can find in your project and upload to Firebase test lab. The app APK does not need to be anything special. It will not even be used. It will only exist in order for Firebase test lab to satisfy it’s need for having an app APK.
To create a fake app APK, I created a brand new Android Studio project with no views and no dependencies and built an APK for 93kb (awesome!). I copied the built app APK file into my code’s git repo. I made a bash script that would run on my Bitrise workflow before my workflow step for “Android build for UI testing”. This bash script would copy the already built APK and copy it into libraryname/build/output/apk/debug to fake that it was built by gradle.
This, however, did not work. I got the same error about my app APK not being found even though my copy bash script ran successfully.
Looking at the source code for Bitrise Android build for UI testing step, I stumbled upon the code for finding APK files and found that the modified date on the APK file must be greater then the date when the Bitrise Android build for UI testing workflow step started. This means that by running my bash script before the Android build for UI testing step, it would not work. Even if I modified the modified date on the file.
So, I resorted to this very simple solution, but not my favorite. I added an extra argument to the gradle task for my Android build for UI testing workflow step. This extra argument is simply :app:assembleDebug which would make sure to build a debug APK for my example app in my Android library project.
I do not like this solution as much because building my app’s APK takes longer then simply coping a 93kb file into a directory. Either one is a hack so I suppose either one isn’t the best solution.
2 Likes
Thanks for sharing your solution! 