This isn’t a new approach, but it helps a lot enabling frame number switching for the most of Android devices. The app I wrote tries to reconstruct a file address for a content URI it receives in a manner like this. The pipe protocol suits purposes when data has to be read just one time like frame extracting or playing a video without rewinding backward. Also sometimes with certain file formats this protocol fails to read frames completely. Seeking forward is supported however, as it just skips read bytes. So when a media resource is accessed this way we can’t return back to the beginning and read data from it. The protocol works in general, but has one major disadvantage: it doesn’t support seeking backward. The nativePointer property also has to be left as is, because it is accessed from the C part in a reflection-style API.Īn example of the C counterpart for the nativeNewFD(fd: Int) looks like this: JNIEXPORT void JNICALL Java_com_javernaut_whatthecodec_VideoFileConfig_nativeNewFD (JNIEnv *env, jobject instance, jint jFileDescriptor). For JNI a name for a C function has to match the JMV method name, so obfuscation process should skip those JVM methods. One more important thing here: you have to carefully set Proguard rules for such a JVM class. Rule of thumb: a dependant library has to be loaded after all its dependencies. Note that the order of libraries to load is important, at least for Android API 16 and 17. That call binds external methods to their implementations in C at runtime. In the companion object we have a list of shared libraries to import with System.loadLibrary(). The nativePointer property is actually an address of a C struct, casted to the Long type. The actual implementation resides in the C part. Several methods and properties are marked with external.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |