13

Questa domanda è stata posta alcune volte in overflow dello stack, ma nessuna soluzione, ancora. Ho un ricevitore di trasmissione per ricevere l'azione connessa tramite USB. La responsabilità del ricevitore di trasmissione è, se ottengo l'intento di avviare la mia applicazione. Nel file manifest ho aggiunto il ricevitore. Ho la stessa logica che funziona in GingerBread, ma I ICS non funziona. Molte domande come, broadcast-not-invokingIl ricevitore broadcast non funziona in ICS se l'app non viene avviata almeno una volta

1: Android Boot-Up BroadCast Not invoking e broadcastreciever-not-working

Se inizio la mia app manualmente una volta, poi dalla prossima volta in reparti quando è collegato USB mia app si avvia automaticamente. prova a rispondere alla stessa domanda ma non risponde. Esiste una soluzione per questo in ICS?

Questo mio ricevitore

 <receiver android:name="com.test.MyReceiver"> 
       <intent-filter> 
        <action android:name="android.hardware.usb.action.USB_STATE" /> 
        <action android:name="android.net.wifi.STATE_CHANGE" /> 
      <action android:name="android.net.wifi.WIFI_STATE_CHANGED" /> 
      <action android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED" /> 
      <action android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED" /> 
       </intent-filter> 
      </receiver> 
    and this is my class 
    public class MyReceiver extends BroadcastReceiver { 
    . 
    . 
    . 

    public void onReceive(Context context, Intent intent) { 
. 

Mi sbaglio da qualche parte?

Grazie in anticipo --Kozlov

+0

Non ho una risposta per te, anche se potrebbe essere utile se potessi guardare il tuo codice e vedere se c'è qualcosa di ovvio. Tuttavia, ho un'applicazione che funziona bene, anche con un ascoltatore di avvio in ICS, quindi non posso dire con certezza quale potrebbe essere il tuo problema. – waxspin

+0

Ciao waxspin, grazie per il tuo commento.Modifica la domanda con manifest e receiver.Puoi controllare se qualcosa è consumato? Ho anche il permesso necessario – Kozlov

+0

Penso di aver frainteso il problema come quello in cui nessuno aveva ancora lanciato l'app. Dovrò rimandare a ** CommonsWare ** di seguito, in quanto sembra averlo testato un bel po '. Nel mio caso particolare, la mia app funziona perché deve essere aperta almeno una volta perché sia ​​utile all'utente finale. Immagino che l'unica cosa che potrai fare qui sia regolare la tua esperienza utente in modo che questo non sia un problema. Non l'avevo notato con la mia app, perché il mio caso particolare non aveva bisogno di essere riadattato dopo la modifica. – waxspin

risposta

11

C'è qualche soluzione per questo in ICS?

Funziona correttamente. A partire da Android 3.1, nessun BroadcastReceiver funzionerà finché l'utente non avrà avviato manualmente un'attività. I blogged about this eight months ago.

+0

solo curioso, perché dovrebbero disabilitare questo per Broadcast Recievers, ma non i fornitori di contenuti? Ho testato questo stesso scenario sia con 2.3 che con ICS. I prodotti di ContentProvider funzioneranno, i BR non funzioneranno su ICS, ma entrambi funzionano con 2.3. – Ben

+1

@ Ben: perché i fornitori di contenuti non vengono utilizzati spontaneamente. Questo è stato aggiunto per aiutare a ridurre il malware drive-by, roba che installa, aggancia una serie di trasmissioni di sistema e fa cose senza alcun coinvolgimento dell'utente. – CommonsWare

+0

sì, credo di poter vedere quell'argomento, ma comunque, sembra che potrebbero renderlo un permesso piuttosto che cambiare completamente il modo in cui funziona il sistema. Una delle cose che mi è piaciuta di Broadcast Receivers è che si trattava di un message bus integrato direttamente nel sistema operativo con consegna garantita (se si utilizza sendOrderedBroadcast). Sembra che ora, la garanzia è sparita, quindi sono costretto a usare CP invece, il che va bene, tranne che perdo quel bellissimo pub/sotto modello con filtri di intent. – Ben