Fix Arc integration test.

chrome/browser/chromeos/arc/arc_session_manager.cc

Index: chrome/browser/chromeos/arc/arc_session_manager.cc
diff --git a/chrome/browser/chromeos/arc/arc_session_manager.cc b/chrome/browser/chromeos/arc/arc_session_manager.cc
index 7eab36a63c72b086c0c29b6e9e06b531d7179912..419e5215f01c98647d8a52271ba610bb062f9e9a 100644
--- a/chrome/browser/chromeos/arc/arc_session_manager.cc
+++ b/chrome/browser/chromeos/arc/arc_session_manager.cc
@@ -60,6 +60,9 @@ ArcSessionManager* g_arc_session_manager = nullptr;
 // Skip creating UI in unit tests
 bool g_disable_ui_for_testing = false;
 
+// Skip DCHECK(state() == State::REMOVING_DATA_DIR) in OnArcDataRemoved.
+bool g_is_session_manager_for_sync_test = false;
+
 // Use specified ash::ShelfDelegate for unit tests.
 ash::ShelfDelegate* g_shelf_delegate_for_testing = nullptr;
 
@@ -156,6 +159,11 @@ void ArcSessionManager::EnableCheckAndroidManagementForTesting() {
   g_enable_check_android_management_for_testing = true;
 }
 
+// static
+void ArcSessionManager::SetSessionManagerForSyncTest() {
+  g_is_session_manager_for_sync_test = true;
+}
+
 void ArcSessionManager::OnSessionReady() {
   for (auto& observer : arc_session_observer_list_)
     observer.OnSessionReady();
@@ -223,7 +231,8 @@ void ArcSessionManager::OnArcDataRemoved(bool success) {
     observer.OnArcDataRemoved();
 
   profile_->GetPrefs()->SetBoolean(prefs::kArcDataRemoveRequested, false);

[lgcheng, 2017/02/22 23:36:44]

state() is confused when multiple profiles are created.

[hidehiko, 2017/02/23 06:31:45]

Instead, could you avoid confusing the state machine in ArcSessionManager,
because it means ArcSessionManager won't work properly then?
I think there are several possibilities;

ArcAppListPrefs is per profile (BrowserContextKeyedService), while ASM is a
global singleton (owned by ArcServiceLauncher).
So, maybe could you work on fixing ArcAppListPrefs so that it can do something
good with a Profile instance which is different from the one ASM knows?

Or, alternatively, ASM needs to be created per Profile. Though, IIUC, the
current plan is to keep it singleton, for persistent ARC and login-screen work.
Thus, this approach sounds a bit harder, I guess.

Another approach is, creating a primary Profile and do something, then destroy
it completely (incl. shutdown ARC), then creating another Profile and do
something.
In that way, Profile instance and tied ArcAppListPrefs can be one at once, so it
won't hit the ASM restriction?

WDYT?

-  DCHECK_EQ(state(), State::REMOVING_DATA_DIR);
+  DCHECK(state() == State::REMOVING_DATA_DIR ||
+         g_is_session_manager_for_sync_test);
   SetState(State::STOPPED);
 
   MaybeReenableArc();