See: https://build.chromium.org/p/chromium.android/builders/Android%20Cronet%20Lollipop%20Builder


Looks like it started with this change:

commit	fd031f17d903f22300f08f46610e1f6418275708	
author	pauljensen <pauljensen@chromium.org>	Mon Nov 21 13:52:57 2016
committer	Commit bot <commit-bot@chromium.org>	Mon Nov 21 13:57:31 2016
[Cronet] Test the libcronet that's shipped, not libcronet_test

The motivation is two-fold:
1. It's always best to test what you ship.
2. This facilitates testing an implementation (libcronet) loaded by other means, rather than forcing testing to replace the implementation in an artificial manner (e.g. substituting libcronet_test for libcronet).

Previously libcronet_test contained both Cronet and the tests, so it could be tested without libcronet.  Now libcronet contains Cronet and the tests are contained within libcronet_test.  During testing libcronet and libcronet_test are loaded.  This presents some complications because libcronet exposes no symbols so direct native testing is not possible (there are no symbols to call), but this is easily addressed:  Most testing just involves actuating the Cronet API (we've good encapsulation boundaries) and what native components need to be accessed can be accessed through a couple simple @hide JNI APIs, namely CronetUrlRequestContext.getUrlRequestContextAdapter and CronetUrlRequest.getUrlRequestAdapterForTesting.

There are a few static data items that cannot be directly manipulated within libcronet and required some additional changes for testing:

1. URLRequestFilter - A few tests registered URLRequest interceptors with URLRequestFilter.  This was remedied by inserting a URLRequestInterceptingJobFactory into the URLRequestContext under test.  The URLRequestInterceptingJobFactory delegates to libcronet_test's URLRequestFilter so interceptors work like normal.

2. NetworkChangeNotifier - I rewrote NetworkChangeNotifierTest to perform a more comprehensive system integration test that did not require direct native manipulation, and instead used pre-existing Java testing APIs.

3. MessageLoop and ThreadTaskRunnerHandle - When libcronet_test code (e.g. URLRequestInterceptors) are run on libcronet's network threads they cannot access MessageLoop::current() and ThreadTaskRunnerHandle::Get() as they're static and, like all static data, are not shared between libcronet and libcronet_test.  To remedy this I simply instantiate a MessageLoop in libcronet_test via CronetTestUtil.PrepareNetworkThread(), and set it to use libcronet's SingleThreadTaskRunner.

TestUploadDataStreamHandler was also slightly modified to run on a thread from libcronet rather than create its own thread.  This way there was a MessageLoop and ThreadTaskRunnerHandle already accessible to libcronet native code.

BUG=629299

Review-Url: https://codereview.chromium.org/2406273002
Cr-Commit-Position: refs/heads/master@{#433525}