Run the later parts of startup as UI thread tasks

chrome/app/android/chrome_main_delegate_android.cc

Index: chrome/app/android/chrome_main_delegate_android.cc
diff --git a/chrome/app/android/chrome_main_delegate_android.cc b/chrome/app/android/chrome_main_delegate_android.cc
index 81f402936423b81d476b4374b57b0c7181c80c94..a1022e4b3709474d889e7776e9da445cde600ee6 100644
--- a/chrome/app/android/chrome_main_delegate_android.cc
+++ b/chrome/app/android/chrome_main_delegate_android.cc
@@ -6,6 +6,7 @@
 
 #include "base/android/jni_android.h"
 #include "base/debug/trace_event.h"
+#include "base/memory/scoped_ptr.h"
 #include "chrome/browser/android/chrome_jni_registrar.h"
 #include "chrome/browser/android/chrome_startup_flags.h"
 #include "content/public/browser/browser_main_runner.h"
@@ -13,8 +14,8 @@
 // ChromeMainDelegateAndroid is created when the library is loaded. It is always
 // done in the process's main Java thread. But for non browser process, e.g.
 // renderer process, it is not the native Chrome's main thread.
-ChromeMainDelegateAndroid::ChromeMainDelegateAndroid() {
-}
+ChromeMainDelegateAndroid::ChromeMainDelegateAndroid()
+    : incremental_startup_enabled_(false) {}
 
 ChromeMainDelegateAndroid::~ChromeMainDelegateAndroid() {
 }
@@ -33,7 +34,17 @@ int ChromeMainDelegateAndroid::RunProcess(
     RegisterApplicationNativeMethods(env);
 
     browser_runner_.reset(content::BrowserMainRunner::Create());
-    return browser_runner_->Initialize(main_function_params);
+
+    // For Chrome on android we want to run the startup tasks incrementally, so

[Yaron, 2013/07/23 02:14:03]

Any reason not to do this on testshell as well and avoid the unnecessary
conditional? Or put another way: why configure this from internal repo? If you
want to make this conditional, it could just be a flag.

[aberent, 2013/07/23 13:45:03]

This has to be conditional, since there are a number of secondary broadcast
receivers and activities provided by Chrome on Android (and implemented in the
internal repo) that assume that the browser starts synchronously. These include
the AccountsChangeReceiver and the various bookmark receivers and activities. As
such the decision on whether startup is allowed to be asynchronous has to be in
the internal repo.

I have not investigated whether we could change these to support asynchronous
startup, but, at the very least, this would involve considerable extra work.

I considered making this a command line flag, but the observer had to be passed
down anyway, so it seemed to make sense to pass down the control of this by the
same route.

+    // that UI tasks can get in in-between.
+    content::StartupTaskRunner::StartupMode mode =
+        incremental_startup_enabled_ ? content::StartupTaskRunner::INCREMENTAL
+                                     : content::StartupTaskRunner::IMMEDIATE;
+    scoped_refptr<content::StartupTaskRunner> startup_task_runner(
+        new content::StartupTaskRunner(mode, GetStartupObserver()));
+
+    return browser_runner_->Initialize(main_function_params,
+                                       startup_task_runner);
   }
 
   return ChromeMainDelegate::RunProcess(process_type, main_function_params);
@@ -47,3 +58,7 @@ bool ChromeMainDelegateAndroid::BasicStartupComplete(int* exit_code) {
 bool ChromeMainDelegateAndroid::RegisterApplicationNativeMethods(JNIEnv* env) {
   return chrome::android::RegisterJni(env);
 }
+
+void ChromeMainDelegateAndroid::EnableIncrementalStartup(bool enable) {
+  incremental_startup_enabled_ = enable;
+}