permissão negada usando o Android Q ffmpeg ": erro = 13, permissão negada

Quero obter os quadros do vídeo RTSP usando ffmpeg. Mas para o Android 10 acima, estou recebendo o erro abaixo.

 E/FFmpeg: Exception while trying to run: [Ljava.lang.String;@55e447f
java.io.IOException: Cannot run program "/data/user/0/com.example.downloadimagefromurl/files/ffmpeg": error=13, Permission denied
    at java.lang.ProcessBuilder.start(ProcessBuilder.java:1050)
    at java.lang.Runtime.exec(Runtime.java:698)
    at java.lang.Runtime.exec(Runtime.java:563)
    at com.github.hiteshsondhi88.libffmpeg.ShellCommand.run(ShellCommand.java:10)
    at com.github.hiteshsondhi88.libffmpeg.FFmpegExecuteAsyncTask.doInBackground(FFmpegExecuteAsyncTask.java:38)
    at com.github.hiteshsondhi88.libffmpeg.FFmpegExecuteAsyncTask.doInBackground(FFmpegExecuteAsyncTask.java:10)
    at android.os.AsyncTask$3.call(AsyncTask.java:378)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:289)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
    at java.lang.Thread.run(Thread.java:919)
 Caused by: java.io.IOException: error=13, Permission denied
    at java.lang.UNIXProcess.forkAndExec(Native Method)
    at java.lang.UNIXProcess.<init>(UNIXProcess.java:133)

Como resposta fornecida por @Saurabh Thorat, o Google não permite que aplicativos executem arquivos binários no diretório / data / user.

Uma solução ruim que eu sei é alterar compileSdkVersion e targetSdkVersion para 28 ou menos e relançar meu aplicativo, o que não é recomendado.

Portanto, também estou procurando soluções mais viáveis ​​para lançamentos futuros.

Qualquer dica, link ou sugestão seria muito apreciada. Desde já, obrigado.

A partir do Android Q, você não pode executar binários no diretório de dados particulares do seu aplicativo.

No issuetracker: https://issuetracker.google.com/issues/128554619

A alteração no bloco exec () nos arquivos de dados do aplicativo para targetAPI> = Q está funcionando conforme o planejado. Consulte https://android-review.googlesource.com/c/platform/system/sepolicy/+/804149 para obter informações detalhadas sobre essa alteração. Chamar exec () em arquivos de aplicativos graváveis ​​é uma violação de W ^ X ( https://en.wikipedia.org/wiki/W%5EX ) e representa uma prática insegura de aplicativo. O código executável deve sempre ser carregado no APK do aplicativo.

Embora o exec () não funcione mais em arquivos no diretório inicial do aplicativo, ele continua sendo suportado por arquivos no diretório somente leitura / data / app. Em particular, deve ser possível empacotar os binários no diretório libs nativo do aplicativo e ativar android: extractNativeLibs = true e, em seguida, chamar exec () nos artefatos / data / app. Uma abordagem semelhante é feita com a funcionalidade wrap.sh, documentada em https://developer.android.com/ndk/guides/wrap-script#packaging_wrapsh .

Além disso, esteja ciente de que os executáveis ​​executados via exec () não são gerenciados de acordo com o ciclo de vida do processo Android e, de modo geral, exec () é desencorajado pelos aplicativos Android. Embora não seja uma documentação do Android, o uso de "exec ()" com NDK cobre isso com alguns detalhes. Depender de exec () pode ser problemático em futuras versões do Android.

Altere apenas no arquivo Build.gradle targetSdkVersion 29 a 28 e reinstale o aplicativo no seu dispositivo

A resposta anterior explica corretamente o problema que você está enfrentando. Esse também é um problema aberto levantado em setembro passado, discutido no fórum da biblioteca que você está usando (pelo que posso ver no rastreamento de pilha).

A solução para compilar para o SDK 29 seria parar de colocar binários no diretório / data / e garantir que eles estejam no diretório libs nativo. Isso não pode ser alcançado depois que o APK é instalado e descompactado em dispositivos não-rooteados e, portanto, deve ser feito corretamente ao preparar o projeto Android (por exemplo, através das configurações de gradle) e para garantir que, após a instalação, o conteúdo seja descompactado corretamente: android:extractNativeLibs=true.

No seu caso, esse código move binários que são compactados como 'ativos' no diretório de dados do usuário:

https://github.com/WritingMinds/ffmpeg-android-java/blob/master/FFmpegAndroid/src/main/java/com/github/hiteshsondhi88/libffmpeg/FileUtils.java

Essa é uma preocupação de segurança executando quaisquer executáveis ​​em um local que seja de leitura / gravação. Esse código fonte ao qual vinculei acima precisaria ser removido, em vez disso, os binários nativos empacotados em / libs. A alteração é mais segura, pois o local / libs dentro do diretório de instalação dos aplicativos é executável, mas não pode ser gravado.

Em resumo, a biblioteca de terceiros precisa abordá-la ou você pode fazê-lo e contribuir com uma solicitação de recebimento. Ou escolha o seu e recompile por si mesmo.

Ainda há um problema, se seu aplicativo realmente baixa conteúdo após a instalação e espera executar todos os downloads. Agora isso é impossível, tanto quanto eu posso dizer no Android 10.

A solução à prova de futuro é parar de usar binários externos e compilar as dependências como projetos NDK. Eles precisarão de wrappers jni em torno do código nativo (um pouco de trabalho). Existe um projeto relacionado que eu conheço que você pode analisar.