Autorizzazioni una tantum che causano l'annullamento di allarmi e processi pianificati in background

Aug 21 2020

Sviluppiamo un SDK Android e, durante il test di Android 11 Beta, abbiamo riscontrato un problema che non sembra ancora essere segnalato.

In Android 11, sono state introdotte nuove autorizzazioni una tantum per le autorizzazioni di posizione, microfono e fotocamera. Con questa opzione, non appena l'utente lascia l'applicazione, l'autorizzazione viene revocata (maggiori dettagli possono essere trovati qui ).

Il problema è che dopo un breve lasso di tempo in cui l'app non è più in primo piano (non è necessario chiudere l'app, basta ridurla a icona), tutti i futuri avvisi o lavori programmati vengono rimossi, come se l'app fosse forzata ucciso. Ciò accade solo con questo livello di autorizzazione. Negando o fornendo altri livelli si mantengono gli avvisi o i lavori pianificati in precedenza, come previsto. Lo abbiamo riprodotto nella build Beta 3, in un emulatore Pixel 2 con il numero build RPB3.200720.005. In questo repository puoi trovare un'app di esempio per riprodurre il bug.

Questa app per attività singola pianifica un allarme per suonare nei prossimi cinque minuti, così come un lavoro da attivare tra 5-6 minuti. Lo schermo ha tre pulsanti, ciascuno dei quali attiva la richiesta di autorizzazione corrispondente. Le classi JobService e BroadcastReceiver registrano solo che sono state attivate. La situazione può essere riprodotta dopo i seguenti passaggi:

  1. Ad ogni avvio dell'app è possibile eseguirle entrambe adb shell dumpsys alarm | grep com.example.permissions.appe adb shell dumpsys jobscheduler | grep com.example.permissions.appvedere che sia l'allarme che il lavoro sono programmati;
  2. Fare clic su uno dei pulsanti e concedere il livello di autorizzazione una tantum;
  3. Riduci a icona l'app (puoi andare alla schermata principale o aprire un'altra app);
  4. Dopo circa un minuto, esegui sia adb shell dumpsys alarm | grep com.example.permissions.appe adb shell dumpsys jobscheduler | grep com.example.permissions.app. L'allarme e il lavoro non verranno più visualizzati;
  5. Aspettare gli orari pianificati originali sia per il lavoro che per l'allarme (con indulgenza per i ritardi del sistema) mostrerà che non verranno attivati.

Qualcuno di voi ha riscontrato una situazione simile? La nostra impressione è che per revocare le autorizzazioni una tantum, il processo dell'app venga interrotto in qualche modo causando questi effetti collaterali. Abbiamo anche presentato un problema su Android Issue Tracker e terremo aggiornato questo post se Google risponde.

Risposte

GabrielFalcone Sep 14 2020 at 12:38

Il problema è stato "risolto". Il problema era in realtà con Android Studio che chiamava una chiusura forzata quando l'autorizzazione veniva revocata dopo aver chiuso l'app.

La risposta effettiva di Google:

Grazie mille per aver sollevato questo problema e fornito un codice di esempio per riprodurlo. Dopo aver indagato ulteriormente, abbiamo scoperto che ciò è dovuto a un'interazione tra Android Studio e le app avviate tramite il comando "Esegui".

In particolare, quando Android revoca l'autorizzazione di un'app, interrompe il processo dell'app. Abbiamo scoperto che Android Studio invia un comando di arresto forzato tramite adb quando osserva che l'app che ha avviato non è più in esecuzione.

Se l'app viene avviata tramite il programma di avvio (incluso in un emulatore connesso ad Android Studio), l'app non viene arrestata forzatamente e l'allarme e il lavoro vengono entrambi eseguiti come previsto.

Quindi non causerà problemi aggiuntivi tranne durante la fase di sviluppo. Per ulteriori informazioni, controlla il tracker dei problemi di Android collegato alla domanda.