2011-12-30 8 views
7

Ho uno stacktrace inviato da un utente con ICS.startBluetoothSco() genera l'eccezione di sicurezza (BROADCAST_STICKY) su ICS

sul mio dispositivo Froyo tutto funziona bene, ma l'utente ottiene a quanto pare la negazione del permesso quando AudioManager.startBluetoothSco() si chiama ... Non ho idea perché questo sta accadendo - So che il Broadcast per ACTION_SCO_AUDIO_STATE_CHANGED è appiccicoso, ma non è l'applicazione che sta inviando esso, quindi non dovrebbe essere necessario il permesso ...

riportano di seguito le 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) 

/edit: ho potuto riprodurre il problema, e non lo fa importa se avvio il servizio con START_STICKY oppure no.

+0

v'è alcuna ragione per non volere includere il permesso? –

+0

No, ora lo ho incluso per il prossimo aggiornamento, ma * non dovrebbe essere necessario * per questa funzione. Quindi deve esserci qualcosa di sbagliato. Argh - finora ICS ha portato così tanti problemi .... – Force

+0

Puoi riprodurlo in un emulatore? Oppure sta accadendo solo su un Galaxy Nexus? Potrebbe essere un problema specifico del dispositivo? –

risposta

4

unica soluzione è quella di aggiungere questa autorizzazione per la vostra applicazione per farlo lavorare su ICS ..

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

C'è un problema registrato here on OHAP per questo difetto in ICS

Problemi correlati