FFmpeg-Android
FFmpeg-Android copied to clipboard
Permission denied running version command when targeting Android Q
Not sure if it's because I am running Android Q beta, or I'm doing something wrong but I am getting the following:
2019-07-26 12:29:01.320 24329-24408/com.android.testffmpeg E/FFmpeg: Exception while trying to run: [/data/user/0/com.android.testffmpeg/files/ffmpeg, -version] java.io.IOException: Cannot run program "/data/user/0/com.android.testffmpeg/files/ffmpeg": error=13, Permission denied at java.lang.ProcessBuilder.start(ProcessBuilder.java:1050) at nl.bravobit.ffmpeg.ShellCommand.run(ShellCommand.java:15)
All I am doing is calling this function:
`
private fun versionFFmpeg() {
FFmpeg.getInstance(TestFFmpegApplication.instance.applicationContext)
.execute(arrayOf("-version"), object : ExecuteBinaryResponseHandler() {
override fun onSuccess(message: String?) {
Timber.d(message)
}
override fun onProgress(message: String?) {
Timber.d(message)
}
})
}
`
The only setup I have in the code is this:
implementation 'nl.bravobit:android-ffmpeg:1.1.7'
Can anyone see what it is I am missing, or perhaps there is an issue running on Android Q?
Looks like it's Q. If I build and run your sample app verbatim, it works, but when I change the compile and target SDK to be 29....crash. Same as I see in my app. So I think this looks to be a fairly high bug given Q will be released shortly.
Tried this on Q emulator, system-images\android-29\google_apis\x86, and it simply worked.
I have updated the Q emulator (now it is [google/sdk_gphone_x86/generic_x86:10/QPP6.190730.005.B1/5775370:userdebug/dev-keys]), and the it does not permit to run ffmpeg from the files directories anymore. Or maybe the trigger is that I set targetSdk=29.
Actually, this is a documented change.
The fix is to move ffmpeg from assets to jniLibs.
Someone has solution to run ffmpeg commands in android Q its urgent??
Any updates on this?
Hi, I didn't try it myself but probably you can fix it with adding
android:requestLegacyExternalStorage="true"
to application in AndroidManifest.xml
No, it still does not work
Try this library I just tested it on a physical device running Android Q (android 10)
@WassimErriha Thanks, it worked.
Any updates on this?
Or is this the end of this library?
I found solution on this issue. https://issuetracker.google.com/issues/128554619
exec() no longer works on files within the application home directory, it continues to be supported for files within the read-only /data/app directory. In particular, it should be possible to package the binaries into your application's native libs directory and enable android:extractNativeLibs=true, and then call exec() on the /data/app artifacts. A similar approach is done with the wrap.sh functionality, documented at https://developer.android.com/ndk/guides/wrap-script#packaging_wrapsh .
It works well on my project(tested on Pixel 3a XL android Q)
I have updated the Q emulator (now it is
[google/sdk_gphone_x86/generic_x86:10/QPP6.190730.005.B1/5775370:userdebug/dev-keys]), and the it does not permit to run ffmpeg from the files directories anymore. Or maybe the trigger is that I set targetSdk=29.Actually, this is a documented change.
The fix is to move ffmpeg from assets to jniLibs.
I have create jniLibs folder then move the lib from assets,but still not work, Is there something i miss?
I have create jniLibs folder then move the lib from assets,but still not work, Is there something i miss?
It's much more than simply renaming some folders, see https://github.com/bravobit/FFmpeg-Android/pull/130
Why hasn't this been merged yet, even Android 11 is about be released, has this project been abandoned?
Just change targetSdkVersion 29 to 28 in build.gradle
It worked for me.
@pratikbutani not a solution that works on higher android versions
@kibotu It's working on higher version too. I have checked on Android 10.
not working for me
NOT WORKING FOR ME TOO. Have anyone found an answer to this problem?
@SnehaDZ @aliraza96 if you can set targetSdkVersion less than 29, your app will continue to work even on Android 11 (a.k.a. Android R). Note that this does not prevent you from using the new Android Q APIs in your code.
But if you want to switch to 29, you can try my fork. In the long run, I would recommend to switch to another library, even though this means that your code must be changed: with every upgrade, Android becomes less open to running executables in the context of an app.
any update ?
still unrepaired
any update?
We're using this library instead now, which is still maintained actively
https://github.com/tanersener/mobile-ffmpeg
You can take a look on my approach on the original repo. I basically moved ffmpeg to the libs folder and renamed it to libffmpeg.so (should start with lib and end with .so in order for this to work). Then I added android:extractNativeLibs = "true" to the manifest so the binary is moved into data/app/{package_name}/lib/{arch}/, where it can me executed on Android 10.
There is a problem with this though. You have to put the binaries 4 times in the apk (if you want an apk that supports all architectures). The only way to have the binaries 2 times is to build the apk for arm and x86 only (so it can use the x86 binary on x64 and arm binary for arm64). But then playstore wont let you upload your app because it doesn't have native x64 support.
I have updated the Q emulator (now it is
[google/sdk_gphone_x86/generic_x86:10/QPP6.190730.005.B1/5775370:userdebug/dev-keys]), and the it does not permit to run ffmpeg from the files directories anymore. Or maybe the trigger is that I set targetSdk=29.Actually, this is a documented change.
The fix is to move ffmpeg from assets to jniLibs.
how can I move from assets to JNI libs?
use this
implementation 'com.arthenica:mobile-ffmpeg-full:4.3.1.LTS'
use this
implementation 'com.arthenica:mobile-ffmpeg-full:4.3.1.LTS'
I tried this, ffmpeg -version hits onFailure. do I need to do load library with this version. The 0.3.2 from writingminds required it.
@plazar99 normally, the library loads its native part by itself. But your mileage may vary.
I just rebuild it for sdktarget 28, no difference. I'm afraid I'm missing something fundamental here.