You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Device unauthorized errors during Android device CI runs #47185
Adb seems to be claiming that the device is unauthorized, which causes a bunch of tests to not run and fail. I'm not sure if this is machine specific or device specific. I'm seeing numerous BadExit's on DNCENGWIN-036 and 30.
[10:02:24] fail: Error trying to get device architecture: error: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.
[10:02:24] crit: Failure to run test package: Object reference not set to an instance of an object.
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.DotNet.XHarness.CLI.Commands.Android.AndroidTestCommand.<>c__DisplayClass17_0.<GetDeviceToUse>b__0(KeyValuePair`2 kvp) in /_/src/Microsoft.DotNet.XHarness.CLI/Commands/Android/AndroidTestCommand.cs:line 259
at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source, Func`2 predicate)
at Microsoft.DotNet.XHarness.CLI.Commands.Android.AndroidTestCommand.GetDeviceToUse(ILogger logger, AdbRunner runner, String apkRequiredArchitecture) in /_/src/Microsoft.DotNet.XHarness.CLI/Commands/Android/AndroidTestCommand.cs:line 259
at Microsoft.DotNet.XHarness.CLI.Commands.Android.AndroidTestCommand.InvokeInternal(ILogger logger) in /_/src/Microsoft.DotNet.XHarness.CLI/Commands/Android/AndroidTestCommand.cs:line 99
XHarness exit code: 71
C:\h\w\A9ED09B0\w\B03109F7\e>set _commandExitCode=71
I think so... but they seem to be going bad more often. Is it possible that a sufficiently weird APK could cause the problem? (@parose1 would be interested in the answer)
Hard to say, we'd need to know in what state the device is then we could maybe track down how it got there by correlating which workitems ran around the time it went bad.
Activity
steveisok commentedon Jan 19, 2021
/cc @MattGal
MattGal commentedon Jan 19, 2021
Sure seems device-specific ... @akoeplinger any suggestions? We can just teach it to try the suggested workaround of kill-server in this case too.
akoeplinger commentedon Jan 21, 2021
Hm we should try if killing the adb server works, but it's possible that the device lost authentication and someone needs to re-auth it on the phone.
ViktorHofer commentedon Mar 1, 2021
Most likely mitigated with fixes mentioned in https://github.com/dotnet/core-eng/issues/11891.
mdh1418 commentedon Apr 21, 2021
I'm seeing this happening for the following test suites
based on https://dev.azure.com/dnceng/public/_build/results?buildId=1093022&view=logs&j=c693b1a1-52cc-5241-304f-e4b4c2d5f73e&t=ca6cd8a5-c31d-5a98-8419-f200a8c4128d from test runs in #50095
MattGal commentedon Apr 21, 2021
@mdh1418 it's more likely related to specific devices versus the tests but we'll take a look and get an issue created if so.
akoeplinger commentedon Apr 22, 2021
@MattGal this ended up being the devices right: https://github.com/dotnet/core-eng/issues/12841 ?
MattGal commentedon Apr 22, 2021
I think so... but they seem to be going bad more often. Is it possible that a sufficiently weird APK could cause the problem? (@parose1 would be interested in the answer)
akoeplinger commentedon Apr 22, 2021
Hard to say, we'd need to know in what state the device is then we could maybe track down how it got there by correlating which workitems ran around the time it went bad.