Fixed
Status Update
No update yet.
Comments
kl...@google.com
This is a regression in the test support library 1.0 / Espresso 3.0.0. The issue does not occur if using the previous version of the testing support library 0.5, Espresso 2.2.2 or Espresso 2.3-alpha
kl...@google.com
The ClassNotFoundException is being reported because the class could not be loaded because its base class could not be found. That behavior is correct if the class name has been explicitly specified. However, if the class name was obtained by scanning the path (which I assume is what is happening in this case) then it should ignore class loading errors.
Can you confirm that the test from step 2 is actually run even though a test failure is being reported for the unloadable class?
Can you confirm that the test from step 2 is actually run even though a test failure is being reported for the unloadable class?
kl...@google.com
The test cases are not being run. To prevent runtime crashes, I have the test cases which touch newer APIs configured with @SdkSuppress. The problem is occurring because the new runner is scanning the classpath and blows up whenever it sees something missing.
The same problem will occur with optional dependencies, like how Google Play Services contains MapFragment but the POM doesn't declare a dependency on support-v4. Clients of play services are expected to either not touch MapFragment or include support-v4 before touching the class. I do something similar with one of my own libraries, and anything consuming that library will fail to run tests unless I include an `androidTestCompile` dependency on support-v4.
The same problem will occur with optional dependencies, like how Google Play Services contains MapFragment but the POM doesn't declare a dependency on support-v4. Clients of play services are expected to either not touch MapFragment or include support-v4 before touching the class. I do something similar with one of my own libraries, and anything consuming that library will fail to run tests unless I include an `androidTestCompile` dependency on support-v4.
cb...@google.com
as...@gmail.com
I do not understand how the presence of one unloadable class is preventing other tests from being run. The code in TestLoader is explicitly written to detect this situation and defer the reporting of the error until the tests are run so that one unloadable class does not prevent the tests from running.
Could you provide the device side logs from your test run please?
Could you provide the device side logs from your test run please?
ap...@google.com
pa@google.com, another issue closed as duplicate https://issuetracker.google.com/issues/64094195 has logs attached as well as this issue (in the description).
Btw, the workaround for that is to limit scope of the search for the test runner — pass package that contains only tests:
- Either by specifying package by passing instrumentation arguments -e package com.example.tests
- Or by subclassing AndroidJUnitRunner and overriding onCreate and adding package parameter there
Btw, the workaround for that is to limit scope of the search for the test runner — pass package that contains only tests:
- Either by specifying package by passing instrumentation arguments -e package com.example.tests
- Or by subclassing AndroidJUnitRunner and overriding onCreate and adding package parameter there
ap...@google.com
The bug referenced in #6 only contains a stacktrace not a full log. Working around it by using package name filtering makes sense because that will remove the name of the unloadable class before it is tried to be loaded.
Description
For example, on Windows 10 with English US as the UI language, the console/stdin uses IMB437 as the character encoding. Assuming the six character password "ab¡äю1" (0x0061 0x0062 0x00a1 0x00e4 0x044e 0x0031 in big-endian hexadecimal representation):
$ keytool -genkey -v -keystore native.jks -keyalg RSA -keysize 2048 -validity 10000 -alias test
generates a keystore and key protected with 0x0061 0x0062 0x00ad 0x0084 0x003f 0x0031
whereas
$ keytool -genkey -v -keystore native.jks -keyalg RSA -keysize 2048 -validity 10000 -alias test -storepass ab¡äю1
generates a keystore and key protected with 0x0061 0x0062 0x00a1 0x00e4 0x003f 0x0031
The same command-lines on modern Linux/OSX which these days use UTF-8 by default for console produces keystores encrypted using:
0x0061 0x0062 0x00c2 0x00a1 0x00c3 0x00a4 0x00d1 0x008e 0x0031
and
0x0061 0x0062 0x00a1 0x00e4 0x044e 0x0031
respectively.
This weird behavior might be a remnant of the early days of Java where there was no Console (which automatically provides Unicode characters as input and thus has a concept of character encoding of standard input) nor a standard concept of character encoding for standard input. jarsigner appears to follow the same behavior, potentially to remain compatible with old keystores from those days and with current versions of keytool.
To complicate matters, keytool is not the only means of creating keystores which are used for signing APKs. For example, Android Studio offers this functionality as well. Thus, apksigner needs to try both the password represented as Unicode characters as well as the password represented as the form encoded according to the console's character encoding.