2011-12-30 8 views
7

Tengo un stacktrace enviado por un usuario con ICS.startBluetoothSco() arroja excepción de seguridad (BROADCAST_STICKY) en ICS

en mi dispositivo Froyo todo funciona bien, pero al parecer, el usuario obtiene la denegación de permisos cuando AudioManager.startBluetoothSco() se llama ... no tengo idea de por qué ocurre esto - Sé que la difusión de ACTION_SCO_AUDIO_STATE_CHANGED es pegajosa, pero no es la aplicación que está enviando, por lo que no debería necesitar el permiso ...

A continuación se muestra la StackTrace:

java.lang.SecurityException: Permission Denial: broadcastIntent() requesting a sticky 
broadcast from pid=15341, uid=10064 requires android.permission.BROADCAST_STICKY 
at android.os.Parcel.readException(Parcel.java:1327) 
at android.os.Parcel.readException(Parcel.java:1281) 
at android.media.IAudioService$Stub$Proxy.startBluetoothSco(IAudioService.java:1090) 
at android.media.AudioManager.startBluetoothSco(AudioManager.java:975) 
at de.bulling.smstalk.libs.utils.AudioUtils.startBluetoothSco(AudioUtils.java:164) 
at de.bulling.smstalk.Services.TTS.speakIt(TTS.java:151) 
at de.bulling.smstalk.Services.TTS.onInit(TTS.java:83) 
at android.speech.tts.TextToSpeech.dispatchOnInit(TextToSpeech.java:627) 
at android.speech.tts.TextToSpeech.access$1000(TextToSpeech.java:52) 
at android.speech.tts.TextToSpeech$Connection.onServiceConnected(TextToSpeech.java:1279) 
at android.app.LoadedApk$ServiceDispatcher.doConnected(LoadedApk.java:1068) 
at android.app.LoadedApk$ServiceDispatcher$RunConnection.run(LoadedApk.java:1085) 
at android.os.Handler.handleCallback(Handler.java:605) 
at android.os.Handler.dispatchMessage(Handler.java:92) 
at android.os.Looper.loop(Looper.java:137) 
at android.app.ActivityThread.main(ActivityThread.java:4424) 
at java.lang.reflect.Method.invokeNative(Native Method) 
at java.lang.reflect.Method.invoke(Method.java:511) 
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784) 
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551) 
at dalvik.system.NativeStart.main(Native Method) 

/editar: podía reproducir el problema, y ​​no lo hace importa si comienzo el servicio con START_STICKY o no.

+0

¿Hay alguna razón para no querer para incluir el permiso? –

+0

No, ahora lo incluí para la próxima actualización, pero * no debería ser necesario * para esta función. Entonces debe haber algo mal. Argh: hasta ahora, ICS trajo tantos problemas ... – Force

+0

¿Puedes reproducirlo en un emulador? ¿O solo está sucediendo en un Galaxy Nexus? Podría ser un problema específico del dispositivo? –

Respuesta

4

Sólo solución es agregar este permiso a la aplicación para que funcione en ICS ..

<uses-permission android:name="android.permission.BROADCAST_STICKY"/> 

Hay un problema registra here on OHAP para este defecto en la ICS

Cuestiones relacionadas