Develop Reference

Android instrumentation tests fail on Google's Test Lab Galaxy S9+ due to keyboard on-boarding popup

Occasionally, the instrumentation tests (Espresso) are failing on Google's Firebase Test Lab due to a keyboard on-boarding popup (screenshot) that blocks the screen and prevents tap/type events.
This only happens on the Samsung Galaxy S9+
Here is the exception:
android.support.test.espresso.PerformException: Error performing 'type text(666666)' on view '(is descendant of a: (with id: XXX) and an instance of android.widget.EditText)'.
Caused by: android.support.test.espresso.InjectEventSecurityException: java.lang.SecurityException: Injecting to another application requires INJECT_EVENTS permission
at android.support.test.espresso.base.InputManagerEventInjectionStrategy.injectKeyEvent(InputManagerEventInjectionStrategy.java:113)
Any suggestions?

Maybe you can try to play around with "ime" command from ADB to enable another keyboard (you can log for example the return of ime list in order to get the IDs) before running your tests (e.g. #Before):
getInstrumentation().getUiAutomation().executeShellCommand("ime enable ID");
Thread.sleep(1000);
getInstrumentation().getUiAutomation().executeShellCommand("ime set ID");
Else you can workaround with uiautomator and implement a check before using the keyboard with this kind of piece of code :
...
onView(withId(R.id.inputField)).perform(click());
if (Build.VERSION.SDK_INT >= 23) {
UiDevice device = UiDevice.getInstance(getInstrumentation());
UiObject skipButton = device.findObject(new UiSelector().text("SKIP"));
if (skipButton.exists()) {
try {
skipButton.click();
Timber.e(e, "Dismissed popup on Keyboard");
} catch (UiObjectNotFoundException e) {
Timber.e(e, "There is no popup displayed on Keyboard");
}
}
}
onView(withId(R.id.inputField)).perform(typeText("some"), pressImeActionButton());
...
Hope this help !

I also faced this problem. It's on Firebase Test Lab side, and you shouldn't try to find a workaround. Sometimes there are problems with devices you are not responsible for. Instead you should report about it to Firebase team directly if you want it to be fixed as soon as possible.
The fastest way to do it is to go to #test-lab channel of the Firebase Slack community and report them about an issue like that. They will ask you to provide your matrix ID where you experienced something wrong.
As for layout popup, it was fixed the next day it was reported, so you shouldn't see it now.

Keep Logcat from deleting entries

In Eclipse, I notice that Logcat only retains a few dozen entries and deletes the older ones as soon as a new one come in. Is there a way to prevent this? I need my app to run for a long time and not lose any entries because my app eventually hangs or crashes after a few days, and I want to see if something in Logcat has been recorded.

I am not sure if this is the most elegant solution to the problem, but you can always increase the LogCat message size in Eclipse.
Window -> Preferences -> Android -> LogCat -> Maximum number of LogCat messages to buffer
The default is 5000, I believe. You can set it to be very high if you are planning to run your application for a long time.

i think you need to increase this show image

Here's a better solution:
Set the Default Uncaught Exception Handler. Whenever the app crashes, this will be called with the exception. Simply write a log entry saying it crashed then dump the logcat to a file. Finally, make sure you re-throw the exception to make sure the app crashes and funky things don't happen. Note: This is per thread, keep that in mind.
Thread.setDefaultUncaughtExceptionHandler(new UncaughtExceptionHandler() {
#Override
public void uncaughtException(Thread thread, Throwable ex) {
Log.e("TAG", "---My app crashed just now---", ex);
//TODO: Dump logcat to file
throw new RuntimeException(ex);
}
});

if you want to keep your app running for days.. its better you capture your logs from adb shell.
the common shell command would be :
logcat -c \\ to clear previous logs
logcat -v time>yourLogs.txt & \\ to capture fresh logs

How can I detect in an app that Proguard successfully removed all log calls?

Thanks to Proguard's optimization features I am now able to do as much debug-logging as I which in my code - for production I simply let it strip all this unnecessary code.
That is fine and works (with the latest Proguard version).
But: before I went this way, I had my final static boolean DEBUG constant that "guarded" all my Log.d/Log.v calls. To ensure I did not forget to disable that for signed production apk's, I just had an easily visible add on in my UI main activity that in some corner put an ugly text "DEBUG IS ON".
So, when producing my final apk, all I had to do is install it once - in case I forgot to switch debug mode off, I was reminded by that.
Now, with Proguard doing the work of removing debug-log-calls: how could I DETECT that in my app and control a UI element that states "DEBUG IS ON"?
Any idea?
My first attempt was to try this:
boolean loggingEnabled = false;
Log.d(TAG, (loggingEnabled = true) ? "Logging test" : "");
And I hoped that Proguard would also remove the assignment loggingEnabled=true- but I underestimated Proguard. It removes the call to Log.d, but still does the assignment... :)

You can do a few things:
Check the mapping.txt in proguard's output folder: grep -E '(android/util/|de/ub0r/android/logg0r/)Log.[dv]' */build/proguard/release/dump.txt
Run the app and check if any d/v log is printed.
Decompilte the app and look at the source code for calls to Log.d() and Log.v().
I build a simple wrapper library to make it a little bit more handy:
https://github.com/felixb/ub0rlogg0r
--- EDIT ---
To Check if your logs got stripped, do the following:
Fork ub0rlogg0r.
Add a public static boolean sHasDebugCalls = false; to Log.
Add sHasDebugCalls = true to all the Log.d() and Log.v() methods.
Place a Log.d(TAG, "has debug logs") somewhere in the very beginning of your app.
When creating your UI, test for Log.sHasDebugCalls to decide visibility of the DEBUG reminder.

Runtime.exec() bug: hangs without providing a Process object

Whether I use this:
process = Runtime.getRuntime().exec("logcat -d time");
or that:
process = new ProcessBuilder()
.command("logcat", "-d", "time")
.redirectErrorStream(true)
.start();
I get the same results: it often hangs within the exec() or start() call, no matter what I tried to do!
The thread running this cannot even be interrupted with Thread.interrupt()! The child process is definitely started and if killed the above commands return.
These calls may fail on first attempt, so THERE IS NO WAY TO READ THEIR OUTPUT! I can also use a simple "su -c kill xxx" command line, same result!
EDIT: Started debugging the java_lang_ProcessManager.cpp file in an NDK project with some debugging logs! So here is what I found so far, after the fork() the parent does this:
int result;
int count = read(statusIn, &result, sizeof(int)); <- hangs there
close(statusIn);
Though the child process is not supposed to block on it: That's what the child does (if started at all!):
// Make statusOut automatically close if execvp() succeeds.
fcntl(statusOut, F_SETFD, FD_CLOEXEC); <- make the parent will not block
// Close remaining unwanted open fds.
closeNonStandardFds(statusOut, androidSystemPropertiesFd); <- hangs here sometimes
...
execvp(commands[0], commands);
// If we got here, execvp() failed or the working dir was invalid.
execFailed:
int error = errno;
write(statusOut, &error, sizeof(int));
close(statusOut);
exit(error);
The child can fail for 2 reproducible reasons:
1- child code is not running, but the parent believes it is!
2- child blocks on
closeNonStandardFds(statusOut, androidSystemPropertiesFd);
In either case the read(statusIn...) in the parent ends in deadlock! and a child process is left dead (and cannot be accessed, pid unknown, no Process object)!

This problem is fixed in Jelly Bean (Android 4.1) but not in ICS (4.0.4) and I guess it will never be fixed in ICS.

Above solution didn't prove to be reliable in any ways, causing more issues on some devices!
So I reverted back to the standard .exec() and kept digging...
Looking at the child code that hangs, I noticed the child process will hang while trying to close all file descriptors inherited from the parent (except the one created within the exec() call) !
So I search the whole app code for any BufferedReader/Writer and similar classes to make sure those would be closed when calling exec()!
The frequency of the issue was considerably reduced, and actually never occured again when I removed the last opened file descriptor before calling exec().
NB: Make sure SU binary is up-to-date, it can actually cause this issue too!
Enjoy your search ;)

Bug fix in Bionic was commited monthes ago, but it still hasn't been included in Android 4.0.4.

I have the same problem on ICS (seem to works fine on Android < 4). Did you find a solution?
A simple workaround could be to call the "exec" method in a dedicated thread with a timeout-join so that this situation could be "detected" (yes I know it's not very elegant...)

Android test annotations with Robotium

I'm currently building an app in Android, and using Robotium to do functional tests (By the way, don't use Robotium on anything less that Android 1.6, it is way too buggy).
Some of these tests have a random tendency to fail, mainly Robotium missing a text field, or timing out, not reading text. I am trying to use the #FlakyTest annotation, so they will run two or three times before throwing out a failed test error. However, the annotation is not working, the tests do not re-run after a failure.
Here is how I am using the annotation:
public class ClassName extends ActivityInstrumentationTestCase2<HomeActivity>{
#LargeTest
#FlakyTest(tolerance=3)
public void testMethod(){
//Here I run my roboitium scripts.
}
}
Then I run it from the command line:
adb shell am instrument -w com.jayway.test/android.test.InstrumentationTestRunner
Neither eclipse nor the command line execution of the tests takes into account the flaky test annotation. Does anyone see an error with how I am trying to apply #FlakyTest?

I can't see any issue with your use of the #FlakyTest annotation.
I put together a quick test case to test #FlakyTest and Robotium (v2.2):
public class FlakyTestCase extends ActivityInstrumentationTestCase2<Main> {
private static int count = 0;
private Solo solo;
public FlakyTestCase() {
super("com.stackoverflow.example", Main.class);
}
#Override
public void setUp() throws Exception {
solo = new Solo(getInstrumentation(), getActivity());
}
#LargeTest
#FlakyTest(tolerance=3)
public void testFlaky(){
Log.e("FlakeyTestCase", "Execution Count:" + ++count);
solo.assertCurrentActivity(null,Main.class);
solo.clickOnText("Doesn't Exist");
Log.e("FlakeyTestCase", "Shouldn't make it here");
}
}
LogCat showed the following messages:
Execution Count: 1
Execution Count: 2
Execution Count: 3
So the #FlakyTest annotation was definitely being invoked. The (final) failure of the test was shown as:
junit.framework.AssertionFailedError: The text: Doesn't Exist is not found!
And the message "Shouldn't make it here" was never logged.
So as far as I can see, there is no issue with how you've declared your annotation or any problems with #FlakyTest and Robotium, v2.2 anyway.
Perhaps there is an issue with another part of your test code?

In general, when writing tests for Android (with or without Robotium) you have to be much more careful. You can't just say "is this visible". You need to wrap everything in a "wait for" cycle, so would say "wait for this to be visible". This is particularly a problem when running in the emulators, because sometimes things take long without any good reason. Without the waiting cycles, you will never have a consistent run. We have a few hundred tests and we have never needed to use the FlakyTest annotation.

Robotium missing a text field, or timing out, not reading text means
We have to check clearly if the text or any existed on the screen then only need to perform the actions like
if(solo.searchText("Doesn't Exist", true){
solo.clickOnText("Doesn't Exist");
}
Similar if any components like button or others we can achieve this by above logic.

Add this to your code:
import android.util.Log;