Assigned
Status Update
Comments
al...@android.com <al...@android.com>
gr...@gmail.com <gr...@gmail.com> #2
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
yb...@google.com <yb...@google.com> #3
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?
yb...@google.com <yb...@google.com> #4
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.
gr...@gmail.com <gr...@gmail.com> #5
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?
gr...@gmail.com <gr...@gmail.com> #6
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
gr...@gmail.com <gr...@gmail.com> #7
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.
gr...@gmail.com <gr...@gmail.com> #8
Fixed in the next release, Runner v1.0.1
gr...@gmail.com <gr...@gmail.com> #9
Pleas give runner:1.0.1-alpha-1 a try and report back if you can still see this issue.
[Deleted User] <[Deleted User]> #10
After updating to alpha-1, the issue no longer reproduces.
ch...@gmail.com <ch...@gmail.com> #11
Confirming, Runner 1.0.1-alpha-1 fixes issue, thanks!
mi...@meta.com <mi...@meta.com> #12
I can see this consistently crashing after an insert in cases where the index of next full span which needs to be invalidated is equal to the size of mData before mData was updated.
This can happen because mData is only resized after invalidation, but full span item indexes have already been shifted after the insert.
I've managed to isolate a repro for this, which you can find in the attached zip. I can upload the raw files if you prefer
This can happen because mData is only resized after invalidation, but full span item indexes have already been shifted after the insert.
I've managed to isolate a repro for this, which you can find in the attached zip. I can upload the raw files if you prefer
Description
Version used: 22.0.0
Noticed on Nexus 5 (Android 5.0.1 LRX22C).
RecyclerView with StaggeredGridLayoutManager.
On click on list item (which spans through all columns) the item is changed (enlarged) and some additional items are inserted below the clicked one. This sometimes results in below exception (I was unable to find why this is random).
java.lang.ArrayIndexOutOfBoundsException: start < 0 || end > len. start=8, end=12, len=11
at java.util.Arrays.checkStartAndEnd(Arrays.java:1732)
at java.util.Arrays.fill(Arrays.java:803)
at android.support.v7.widget.StaggeredGridLayoutManager$LazySpanLookup.invalidateAfter(StaggeredGridLayoutManager.java:2244)
at android.support.v7.widget.StaggeredGridLayoutManager.handleUpdate(StaggeredGridLayoutManager.java:1281)
at android.support.v7.widget.StaggeredGridLayoutManager.onItemsAdded(StaggeredGridLayoutManager.java:1257)
at android.support.v7.widget.RecyclerView$5.dispatchUpdate(RecyclerView.java:443)
at android.support.v7.widget.RecyclerView$5.onDispatchSecondPass(RecyclerView.java:459)
at android.support.v7.widget.AdapterHelper.consumePostponedUpdates(AdapterHelper.java:119)
at android.support.v7.widget.RecyclerView.dispatchLayout(RecyclerView.java:1966)
at android.support.v7.widget.RecyclerView.onLayout(RecyclerView.java:2237)
at android.view.View.layout(View.java:15596)
at android.view.ViewGroup.layout(ViewGroup.java:4966)
at android.support.v4.widget.SwipeRefreshLayout.onLayout(SwipeRefreshLayout.java:561)
at android.view.View.layout(View.java:15596)
at android.view.ViewGroup.layout(ViewGroup.java:4966)
at android.widget.RelativeLayout.onLayout(RelativeLayout.java:1076)
at android.view.View.layout(View.java:15596)
at android.view.ViewGroup.layout(ViewGroup.java:4966)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:573)
at android.widget.FrameLayout.onLayout(FrameLayout.java:508)
at android.view.View.layout(View.java:15596)
at android.view.ViewGroup.layout(ViewGroup.java:4966)
at android.widget.RelativeLayout.onLayout(RelativeLayout.java:1076)
at android.view.View.layout(View.java:15596)
at android.view.ViewGroup.layout(ViewGroup.java:4966)
at android.support.v4.widget.DrawerLayout.onLayout(DrawerLayout.java:907)
at android.view.View.layout(View.java:15596)
at android.view.ViewGroup.layout(ViewGroup.java:4966)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:573)
at android.widget.FrameLayout.onLayout(FrameLayout.java:508)
at android.view.View.layout(View.java:15596)
at android.view.ViewGroup.layout(ViewGroup.java:4966)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:573)
at android.widget.FrameLayout.onLayout(FrameLayout.java:508)
at android.view.View.layout(View.java:15596)
at android.view.ViewGroup.layout(ViewGroup.java:4966)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:573)
at android.widget.FrameLayout.onLayout(FrameLayout.java:508)
at android.view.View.layout(View.java:15596)
at android.view.ViewGroup.layout(ViewGroup.java:4966)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:573)
at android.widget.FrameLayout.onLayout(FrameLayout.java:508)
at android.view.View.layout(View.java:15596)
at android.view.ViewGroup.layout(ViewGroup.java:4966)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:573)
at android.widget.FrameLayout.onLayout(FrameLayout.java:508)
at android.view.View.layout(View.java:15596)
at android.view.ViewGroup.layout(ViewGroup.java:4966)
at android.view.ViewRootImpl.performLayout(ViewRootImpl.java:2072)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1829)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1054)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:5779)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:767)
at android.view.Choreographer.doCallbacks(Choreographer.java:580)
at android.view.Choreographer.doFrame(Choreographer.java:550)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:753)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5221)
at java.lang.reflect.Method.invoke(Native Method)