Add JNI interface for functions to start and stop recording AEC dumps and RTC event logs.

talk/app/webrtc/java/jni/peerconnection_jni.cc

Index: talk/app/webrtc/java/jni/peerconnection_jni.cc
diff --git a/talk/app/webrtc/java/jni/peerconnection_jni.cc b/talk/app/webrtc/java/jni/peerconnection_jni.cc
index e75cd553b6f1e3c3973d6c912315de04d3b28af8..40123e38d968ef7749d6818e3d19a3de8059059c 100644
--- a/talk/app/webrtc/java/jni/peerconnection_jni.cc
+++ b/talk/app/webrtc/java/jni/peerconnection_jni.cc
@@ -1251,6 +1251,34 @@ JOW(jlong, PeerConnectionFactory_nativeCreateAudioTrack)(
   return (jlong)track.release();
 }
 
+JOW(jboolean, PeerConnectionFactory_nativeStartAecDump)(
+    JNIEnv* jni, jclass, jlong native_factory, jint file) {

[terelius, 2015/11/10 16:40:00]

Can the file handle safely be cast to a jint and back?

[jiayl1, 2015/11/10 17:00:04]

Seems OK with
http://developer.android.com/reference/android/os/ParcelFileDescriptor.html#d...

Will the native code close the handle?

[terelius, 2015/11/10 17:15:11]

Ok.

The RtcEventLog calls

FILE* file_stream = rtc::FdopenPlatformFileForWriting(platform_file_);
file_->OpenFromFileHandle(file_stream, true, false);

in StartLogging, and 

file_->CloseFile();
rtc::ClosePlatformFile(platform_file_);

in StopLogging. Ivo, do the AECdump do the same?

[ivoc, 2015/11/10 17:44:16]

@terelius: Good question, I think I need to add an #if defined(ANDROID) around
these function calls. On linux, the platform file is an int, but on windows it
is a HANDLE, which seems to be a pointer type (and therefore 64-bit), so this
conversion will probably cause compiler problems. As far as I'm aware, there is
no way to get access to a file descriptor (as int) in plain (non-Android) java
code anyway, so this restriction shouldn't matter much.

@terelius2: Yes, AEC dump does the same thing.

@jiayl: Yes, native code will close the handle.

[ivoc, 2015/11/10 17:44:16]

@terelius: Good question, I think I need to add an #if defined(ANDROID) around
these function calls. On linux, the platform file is an int, but on windows it
is a HANDLE, which seems to be a pointer type (and therefore 64-bit), so this
conversion will probably cause compiler problems. As far as I'm aware, there is
no way to get access to a file descriptor (as int) in plain (non-Android) java
code anyway, so this restriction shouldn't matter much.

@jiayl: Yes, native code will close the handle.

+  rtc::scoped_refptr<PeerConnectionFactoryInterface> factory(
+      factoryFromJava(native_factory));
+  return factory->StartAecDump(file);
+}
+
+JOW(void, PeerConnectionFactory_nativeStopAecDump)(
+    JNIEnv* jni, jclass, jlong native_factory) {
+  rtc::scoped_refptr<PeerConnectionFactoryInterface> factory(
+      factoryFromJava(native_factory));
+  factory->StopAecDump();
+}
+
+JOW(jboolean, PeerConnectionFactory_nativeStartRtcEventLog)(
+    JNIEnv* jni, jclass, jlong native_factory, jint file) {
+  rtc::scoped_refptr<PeerConnectionFactoryInterface> factory(
+      factoryFromJava(native_factory));
+  return factory->StartRtcEventLog(file);
+}
+
+JOW(void, PeerConnectionFactory_nativeStopRtcEventLog)(
+    JNIEnv* jni, jclass, jlong native_factory) {
+  rtc::scoped_refptr<PeerConnectionFactoryInterface> factory(
+      factoryFromJava(native_factory));
+  factory->StopRtcEventLog();
+}
+
 JOW(void, PeerConnectionFactory_nativeSetOptions)(
     JNIEnv* jni, jclass, jlong native_factory, jobject options) {
   rtc::scoped_refptr<PeerConnectionFactoryInterface> factory(