Pas possible sans Root mais même avec Root, l'enregistrement SoX peut ne pas fonctionner.
Permissions du manifeste Android
Le système de permission d'Android est différent Niveaux de protection ( 1 , 2 ) ; Normal les permissions sont accordées à n'importe quelle application sans interaction de l'utilisateur alors que Signature|Privilégiée (SignatureOrSystem) permissions ( Liste blanche en /etc/permissions/privapp-permissions-*.xml ) ne sont accordées qu'aux applications système. Les deux sont accordés lorsque l'application est installée ou au premier démarrage (si l'application système) et la configuration est sauvegardée dans le fichier /data/system/packages.xml fichier. Certaines autorisations de signature peuvent être accordées à des applications non liées au système après approbation de l'utilisateur à l'aide de la méthode suivante appops .
Dangerous Les permissions sont celles qui nécessitent l'approbation de l'utilisateur pour être accordées ou refusées. Le choix de l'utilisateur est enregistré dans /data/system/users/<User_ID>/runtime-permissions.xml où le User_ID du propriétaire du dispositif est 0 (ne le confondez pas avec l'UID du DAC UNIX).
La plupart des permissions du manifeste sont appliquées par le cadre Android ( system_server ) mais certains sont mappés à des GIDs ; donc appliqués par le noyau. La correspondance entre la permission et le GID est stockée dans /data/system/packages.list .
Comment accorder à une application une autorisation non demandée ?
Vous pouvez modifier les fichiers mentionnés ci-dessus pour accorder une permission qui n'est pas demandée par une application dans son fichier Manifeste . Je n'ai pas testé avec toutes les permissions mais cette astuce fonctionne (au moins jusqu'à Pie) car le framework Android ne vérifie pas la configuration des permissions sauvegardées par rapport aux fichiers manifestes des applications à chaque redémarrage (il se peut que les changements soient rétablis lors d'une tâche de maintenance programmée ou lorsqu'une application est installée ou mise à jour ; je ne suis pas sûr).
Dans notre cas, nous voulons accorder android.permission.RECORD_AUDIO à Termux qui est une permission dangereuse, donc c'est ainsi que vous devez modifier votre runtime-permissions.xml suivi d'un redémarrage immédiat :
<?xml version='1.0' encoding='UTF-8' standalone='yes' ?>
<runtime-permissions fingerprint="...">
...
<shared-user name="com.termux">
<item name="android.permission.READ_EXTERNAL_STORAGE" granted="true" flags="0" />
<item name="android.permission.WRITE_EXTERNAL_STORAGE" granted="true" flags="0" />
<item name="android.permission.RECORD_AUDIO" granted="true" flags="0" />
</shared-user>
...
</runtime-permissions>
Pour confirmer :
~$ pm dump com.termux | grep -A3 'runtime permissions:'
runtime permissions:
android.permission.READ_EXTERNAL_STORAGE: granted=true
android.permission.WRITE_EXTERNAL_STORAGE: granted=true
android.permission.RECORD_AUDIO: granted=true
Pourquoi le SoX ne fonctionne pas ?
Cela dit, le SoX ne sera toujours pas en mesure d'enregistrer de l'audio car (AFAIK) il n'utilise pas les API Java d'Android ( android.media ) ou des API natives ( aaudio / opensles ). Il utilise le pilote ALSA/OSS directement ou par l'intermédiaire de PulseAudio qui a besoin d'un accès direct aux interfaces des dispositifs dans /dev/snd/ o /dev/{audio,dsp*} et l'arbre de proc en /proc/asound/ . Pour plus de détails, voir Architecture audio d'Android .
Cependant, l'accès direct au niveau du noyau n'est pas la norme sur Android, vous avez donc besoin d'un accès Root. Les applications avec android.permission.MANAGE_VOICE_KEYPHRASES sont autorisés à lire /dev/snd/* appareils. Il s'agit d'une autorisation de niveau signature privilégiée qui est cartographié à GID audio ( 1005 ). Vous pouvez modifier packages.xml pour que cette permission soit accordée :
<package name="com.termux" ... >
<perms>
<item name="android.permission.MANAGE_VOICE_KEYPHRASES" granted="true" flags="0" />
</perms>
</package>
<shared-user name="com.termux" ...>
<perms>
<item name="android.permission.MANAGE_VOICE_KEYPHRASES" granted="true" flags="0" />
</perms>
</shared-user>
Et packages.list :
com.termux ... 0 /data/user/0/com.termux default:targetSdkVersion=28... 1005,3003
Mais SELinux ne permet qu'aux applications privilégiées (ayant un contexte priv_app ) pour lire les fichiers dans /dev/snd tandis que /proc/asound/ n'est pas du tout lisible par les applications, donc vous devez patcher sepolicy également.
Et même après cela, la configuration de SoX pour utiliser ALSA/OSS/PA dépend de vous.
Solutions sans racines
Au lieu d'utiliser directement ALSA, PulseAudio peut également être configuré pour diffuser de l'audio sur des sockets TCP ou UDP ou UNIX. C'est ainsi que la lecture des médias fonctionne sur Termux. Voir cette question . Cependant, la capture audio ne fonctionne que par le biais des API Android. Vous pouvez installer termux-api pour utiliser termux-microphone-record pour l'enregistrement audio. Elle utilise MediaRecorder de l'API Java, ou vous pouvez envisager modification de La source SoX pour utiliser le système Android APIs natives .
RELATED
