Implement the skeleton of an android content shell.

media/base/android/media_jni_registrar.cc

Index: media/base/android/media_jni_registrar.cc
diff --git a/media/base/android/media_jni_registrar.cc b/media/base/android/media_jni_registrar.cc
new file mode 100644
index 0000000000000000000000000000000000000000..bc44d418f1ed5409b160aff14dbf3430e4661f79
--- /dev/null
+++ b/media/base/android/media_jni_registrar.cc
@@ -0,0 +1,25 @@
+// Copyright (c) 2012 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 "media/base/android/media_jni_registrar.h"
+
+#include "base/basictypes.h"
+#include "base/android/jni_android.h"
+#include "base/android/jni_registrar.h"
+
+#include "media/base/android/media_player_bridge.h"
+
+namespace media {
+
+static base::android::RegistrationMethod kMediaRegisteredMethods[] = {
+  { "MediaPlayerListener",
+    MediaPlayerBridge::RegisterMediaPlayerListener },

[Ami GONE FROM CHROMIUM, 2012/04/24 19:44:55]

Is there a design doc (or any description of the overall design/plan) for the
registration business?  

Is this list expected to grow?  If not, I'm not clear on the relative value of
media::RegisterJni vs. MPB::RegisterMediaPlayerListener.  If the former is the
only code that needs to know about the latter can one of them not be a public
method (or better yet, can one of them be deleted)?

[Ted C, 2012/04/24 22:28:10]

The idea is to limit the knowledge the library loader in content needs to know
about the internals of the component packages that need to be setup during the
native library JNI initialization.  Previous the library loader had an explicit
list of each file that needed to register it's JNI, but as part of this CL
(comment from jrg) we decided to split of the registration so each module would
expose a single register method that would handle all the necessary classes
locally.  This will hopefully provide a bit more module isolation and prevent
having to change the content directory if you are simply adding a new media
file.

I'm not sure if the media list will grow, but by using the same registrar
concept provides a consistent interface for registering modules.  I will argue
that consistency is worth the a bit of overhead in the case of media.

As for making the other method private, I would definitely like to be able to do
that if there was some kind of concept of module privacy (something like java's
package protected concept), but I don't believe such a beast exists.  Sadly, the
RegisterNatives method in MediaPlayerBridge::RegisterMediaPlayerListener must
exist in the same file that includes the *_jni.h based on how we generate these
headers, so moving that call into this file is also not really possible either.

So, I think this is probably the best we can do for now.

+};
+
+bool RegisterJni(JNIEnv* env) {
+  return base::android::RegisterNativeMethods(
+      env, kMediaRegisteredMethods, arraysize(kMediaRegisteredMethods));
+}
+
+}  // namespace media