Trim and truncate test failure stack traces for both orchestrator and classic/non-orchestrator modes.

[copybara-service]

Trim and truncate test failure stack traces for both orchestrator and classic/non-orchestrator modes.

This change should clean up test failure reporting by:

• Remove test runner framework related stack frames
• Truncate stack traces to a 64KB size when running under orchestrator
  to attempt to avoid binder transaction limits.
  This limit is already enforced when running in classic/non-orchestrator mode

JUnit 4.13 has a really nice getTrimmedStackTrace feature, but androidx.test
is fixed to 4.12 for the time being. So as a temporary workaround, copy
the relevant JUnit change junit-team/junit4#1028 into this project.

Fixes #729, and hopefully #269

[bohsen]

Nice followup 👍

For this to fix #269 shouldn't you apply this change to OrchestrationResultPrinter also?
Please ignore. Didn't read the code properly.

[bohsen]

@brettchabot Small follow-up question. Will this change along with #711 be considered in a 1.3.1 release or can it be expected in an alpha release?
I would very much like to see this change in a stable release, as an alpha release could mean serious breaking changes and would be a no-go. Specifically the plan to deprecate ActivityTestRule is my big concern.

[brettchabot]

@brettchabot Small follow-up question. Will this change along with #711 be considered in a 1.3.1 release or can it be expected in an alpha release?
I would very much like to see this change in a stable release, as an alpha release could mean serious breaking changes and would be a no-go. Specifically the plan to deprecate ActivityTestRule is my big concern.

Sorry, the underlying code has changed significantly between 1.3.0 and HEAD, so I don't think this change will be a candidate for a maintenance release. Arguably as well its a new feature as opposed to purely a bug fix. I can see about doing an alpha release soonish though.

I don't follow the concern about ActivityTestRule though - its already deprecated in 1.3.0.

[bohsen]

I don't follow the concern about ActivityTestRule though - its already deprecated in 1.3.0.

Oh sorry, I meant:
Specifically the plan to remove ActivityTestRule is my big concern.
as mentioned in ActivityScenarioRule-javadoc:

...
This rule is an upgraded version of {@link androidx.test.rule.ActivityTestRule}. The previous
version will be deprecated and eventually be removed from the library in the future.
...

Currently we are blocked by #446 regarding migration to ActivityScenarioRule.

[brettchabot]

I don't follow the concern about ActivityTestRule though - its already deprecated in 1.3.0.

Oh sorry, I meant:
Specifically the plan to remove ActivityTestRule is my big concern.
as mentioned in ActivityScenarioRule-javadoc:

...
This rule is an upgraded version of {@link androidx.test.rule.ActivityTestRule}. The previous
version will be deprecated and eventually be removed from the library in the future.
...

Currently we are blocked by #446 regarding migration to ActivityScenarioRule.

I don't follow the concern about ActivityTestRule though - its already deprecated in 1.3.0.

Oh sorry, I meant:
Specifically the plan to remove ActivityTestRule is my big concern.
as mentioned in ActivityScenarioRule-javadoc:

...
This rule is an upgraded version of {@link androidx.test.rule.ActivityTestRule}. The previous
version will be deprecated and eventually be removed from the library in the future.
...

Currently we are blocked by #446 regarding migration to ActivityScenarioRule.

Oh darn, thanks for raising this. The 'removed' part of that statement should be deleted IMO. To my knowledge, a public API has never been removed from android.support.test/androidx.test, and I cannot imagine removing ActivityTestRule anytime in the near future. androidx uses semantic versioning - so if we did remove an API, it would be in a 2.0+ release.

[bohsen]

@brettchabot That's good news.

I actually have a simple fix for #446 in mind that I wanted to create a change request for, but the setup for the android-test project is kind of a nightmare. Up until now I've spent two whole days trying to create an installation of Ubuntu on a USB-stick. Failed three times by now trying to get Android Studio, Bazel and the AS-Bazel plugin to build the project successfully.

[brettchabot]

@brettchabot That's good news.

I actually have a simple fix for #446 in mind that I wanted to create a change request for, but the setup for the android-test project is kind of a nightmare. Up until now I've spent two whole days trying to create an installation of Ubuntu on a USB-stick. Failed three times by now trying to get Android Studio, Bazel and the AS-Bazel plugin to build the project successfully.

Sorry for the trouble. What OS do you primarily use? Bazel itself does support Windows and Mac, so if it helps you can build and run the robolectric tests on mac at least.
(bazel test ... --test_tag_filters=robolectric --build_tag_filters=robolectric)

Currently linux is needed for building/running tests on emulators and apparently building the maven repository (#734)

[bohsen]

Sorry for the trouble.

@brettchabot Ahh, no worries. It's nice to learn a bit about Bazel and all its intricacies. Actually just got it to build on my Mac. Had to add the following to my WORKSPACE file:

...
android_sdk_repository(
    ...
    path = "/Users/<username>/Library/Android/sdk",
    ...
)
...

Thanks for the info on Mac-support (my primary OS by the way). I thought only Linux was supported from the Contributing doc.