When we deployed Talos tp4m and tsvg we ran into problems where the tests were perma red due to failures to detect measurements. The proximate cause was the tp4m.manifest.develop and svgm.manifest.develop files were not being pushed to the devices even though the tp4m.manifest and svgm.manifest files were.

While investigating possible fixes for the failure to get measurements, I realized that Autophone's code worked properly here locally and for jmaher but did not work on the Autophone mac mini host. It seemed to be a problem with adb push not pushing the full contents of the source directory to the destination directory. For some reason the *.manifest.develop files were not being pushed even though some/most of the other files were being pushed. In an attempt to resolve this, I updated android tools including adb. Although adb still reports its version as 1.0.32 it contains a number of changes. Once of the changes is that if you use wait-for-device more than once in a command it will be treated as a syntax error. This caused bug 1214530. I deployed a patch for bug 1214530 as a hot fix on Autophone and it resolved the adb syntax issue and the failure to copy the *.manifest.develop files.

Android Platform Tools 23.0.1's adb was very problematic as it would continually disconnect due to adb server is out of date. killing... errors. I also tried 23.1 rc1 however this caused the tests to run much slower due to repeated disconnections with messages like adb I 74926 1204278 usb_osx.cpp:259] adb E 74926 1204278 usb_osx.cpp:331] Could not open interface: e00002c5 adb E 74926 1204278 usb_osx.cpp:265] Could not find device interface adb I 74926 1204278 usb_osx.cpp:259] Found vid=18d1 pid=4ee2 serial=07c0feac2581ad6e I've reverted to the Android Platform Tools 21's adb which appears to be working well so far.

so our problem is adb pushing files, can we just retry for the talos stuff until we get linux servers? should we leave a static copy of bits on the device?

I'm not sure I understand. Q: can we just retry for the talos stuff until we get linux servers? Do you mean just keep running it and having it continually fail? I don't see the point in that. Perhaps we can work around the push issue or find a root cause for it. But yes, hopefully Linux is our salavation. Q: should we leave a static copy of bits on the device? bits of what? adb? I have a static copy of it on autophone and here locally in case I need to restore it. Is that what you mean?

oh, the ambiguous communication that I have a problem with! let me clarify: * can we retry pushing files to the device, maybe per file and validate it better * a static copy of the test info, specifically the manifest. as we have a single device, it would probably work. This assumes that running a newer version of android tools on the linux server will solve the problem.

(In reply to Joel Maher (:jmaher) from comment #5) > oh, the ambiguous communication that I have a problem with! let me clarify: > > * can we retry pushing files to the device, maybe per file and validate it > better Yes. I was thinking we could work around whatever this issue is and making sure the files are all pushed. In the old days, devicemanager did things like pushing a zip file and unzipping it on the device. I'm sure we can work around the problem giving some time to experiment. That is one reason I wanted to keep the talos jobs available via try. > * a static copy of the test info, specifically the manifest. as we have a > single device, it would probably work. > If we work around the pushing problem, I don't think we need worry about this per se. > > This assumes that running a newer version of android tools on the linux > server will solve the problem. Not sure I follow. Hopefully Linux's version of the new adb doesn't suffer from the same problems as the OSX version which in that event the pushing problems would go away anyway. I'll have to upgrade my version here to check that out. /me crosses fingers.

jmaher found and fixed the issue in bug 1216636