Instrumentation check fails on some devices

[xpconanfan]

On certain devices from huawei, micromax, and asus, the adb cmd to list instrumentation is flaky. On rare occasions, the cmd prints error with ret code 0:

adb -s URX0215911016988 shell pm list instrumentation
java.lang.UnsatisfiedLinkError: No implementation found for java.lang.String android.os.SystemProperties.native_get(java.lang.String, java.lang.String) (tried Java_android_os_SystemProperties_native_1get and Java_android_os_SystemProperties_native_1get__Ljava_lang_String_2Ljava_lang_String_2)
	at android.os.SystemProperties.native_get(Native Method)
	at android.os.SystemProperties.get(SystemProperties.java:64)
	at android.os.Environment$UserEnvironment.<init>(Environment.java:169)
	at android.os.Environment.initForCurrentUser(Environment.java:107)
	at android.os.Environment.<clinit>(Environment.java:83)
	at android.os.Environment.getLegacyExternalStorageDirectory(Environment.java:468)
	at android.os.Debug.<clinit>(Debug.java:96)
	at android.ddm.DdmHandleHello.handleHELO(DdmHandleHello.java:164)
	at android.ddm.DdmHandleHello.handleChunk(DdmHandleHello.java:91)
	at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)
java.lang.UnsatisfiedLinkError: android.os.Debug
	at android.ddm.DdmHandleHello.handleFEAT(DdmHandleHello.java:176)
	at android.ddm.DdmHandleHello.handleChunk(DdmHandleHello.java:93)
	at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)
java.lang.UnsatisfiedLinkError: android.os.Debug
	at android.ddm.DdmHandleProfiling.handleMPRQ(DdmHandleProfiling.java:187)
	at android.ddm.DdmHandleProfiling.handleChunk(DdmHandleProfiling.java:88)
	at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)

Retrying the same cmd worked.

Looks like we should do a sleep and retry for the instrumentation check in snippe_client.

[dthkao]

Should the framework automatically mask such failures? Maybe exposing the option to retry rather than making it the default would be a better approach.

[xpconanfan]

1. this error is not exposed today, bc the adb cmd ret code 0 so it's treated the same as the package is not instrumented.
2. adding nobs for such detailed control doesn't have much benefit. Users just want it to work, if a retry works, great; if not, it can still fail the way it does today. So we are not masking anything if something really went wrong.

[dthkao]

An exception was raised and made its way all the way back up to the test. It is exposed, and IMO a valuable signal (what if they were testing for device crashes?).

You could just as easily wrap the entire register snippet call in a retry.

[xpconanfan]

A retry does not mask that exception though. It'll still throw if the device actually crashed etc.

This is a pretty standard way to get around adb flakiness in systems that deal with Android.

[xpconanfan]

This is not a high priority thing though as it rarely happens...

[xpconanfan]

Perhaps we could in addition throw a better error for such cases. E.g. if there are lines (except for the first line) that don't start with "^instrumentation:", throw an error saying malformed output received from instrumentation.