Setup initial mock url request job tests for Cronet

components/cronet/android/test/cronet_mock_job_interceptor.cc

Index: components/cronet/android/test/cronet_mock_job_interceptor.cc
diff --git a/components/cronet/android/test/cronet_mock_job_interceptor.cc b/components/cronet/android/test/cronet_mock_job_interceptor.cc
new file mode 100644
index 0000000000000000000000000000000000000000..8d0ed23a813129dfc7b727c5c9e6652a2ec8127e
--- /dev/null
+++ b/components/cronet/android/test/cronet_mock_job_interceptor.cc
@@ -0,0 +1,24 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "cronet_mock_job_interceptor.h"
+
+#include "base/files/file_path.h"
+#include "base/path_service.h"
+#include "base/threading/sequenced_worker_pool.h"
+#include "net/test/url_request/url_request_failed_job.h"
+#include "net/test/url_request/url_request_mock_http_job.h"
+
+namespace cronet {
+
+void AddUrlInterceptors() {
+  base::FilePath test_files_root = base::FilePath::FromUTF8Unsafe(
+      "/data/data/org.chromium.cronet_test_apk/app_cronet_test");
+  // PathService::Get(base::DIR_ANDROID_APP_DATA, &test_files_root);

[xunjieli, 2014/09/19 20:39:15]

Matt, I hardcoded a the directory above temporarily just to see if the tests
pass. 
The problem I ran into is that I can't call
PathService::Get(base::DIR_ANDROID_APP_DATA, & test_files_root) at this time. It
is the complaining that the application context is null (fails
DCHECK(!g_application_context.Get().is_null()); on line 144 of
jni_android.cc).The native application context can only be initialized after the
library is loaded. Since we are calling AddUrlInterceptors() before the library
is loaded, there is no way we can initialize native application context (since
the native implementations are only registered after the library is loaded).

So I guess there are only two options:
#1 keep the hardcoded file path (which is not ideal)
#2 move AddUrlInterceptors() out of JNI_OnLoad and create JNI binding for it.

Which do you prefer? Any thoughts?

[mmenke, 2014/09/19 20:56:37]

That's unfortunate.  I think the JNI binding approach is preferable,
particularly if we can put the call in our test fixture, Java side.

+  net::URLRequestMockHTTPJob::AddUrlHandler(
+      test_files_root, new base::SequencedWorkerPool(1, "Worker"));
+  net::URLRequestFailedJob::AddUrlHandler();
+}
+
+}  // namespace cronet