Resolve several Chromoting Android UI-related crashes and misbehaviors

This protects several places where the UI once allowed users to hit dangerous edge cases:
- Canceling the auth prompt on the app's first run now leaves the switcher's label text unset.
- Launching the app on a device with no usable accounts once again offers to add a new account.
- Trying to authenticate to an account for the first time while disconnected is detected as a network problem.
- The account switcher is made unavailable when the only usable account is already selected.
- There's a new refresh button for updating the currently-displayed host list from the directory server.
- Pressing a device's extra/exotic buttons with high keycodes no longer DCHECKS to crash the app.
- Many third-party keyboards that stubbornly covered the bottom of the remote desktop image no longer do so.
- All native threads are actually properly detached from the JVM.

BUG=259594

Review URL: https://chromiumcodereview.appspot.com/22662003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@216556 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 4 insertions, 0 deletions

diff --git a/remoting/client/jni/chromoting_jni_runtime.h b/remoting/client/jni/chromoting_jni_runtime.h
index 1a6952b..93f933f 100644
--- a/remoting/client/jni/chromoting_jni_runtime.h
+++ b/remoting/client/jni/chromoting_jni_runtime.h
@@ -6,6 +6,7 @@
 #define REMOTING_CLIENT_JNI_CHROMOTING_JNI_RUNTIME_H_
 
 #include <jni.h>
+#include <string>
 
 #include "base/at_exit.h"
 #include "net/url_request/url_request_context_getter.h"
@@ -94,6 +95,9 @@ class ChromotingJniRuntime {
   // cross-thread calls on the class.
   virtual ~ChromotingJniRuntime();
 
+  // Detaches JVM from the current thread, then signals. Doesn't own |waiter|.
+  void DetachFromVmAndSignal(base::WaitableEvent* waiter);
+
   // Reference to the Java class into which we make JNI calls.
   jclass class_;