Configurazione della postazione Android: cosa fare quando il proprietario del dispositivo ti blocca l'accesso alle impostazioni

Atablet Android da 10,1 pollici era stato configurato per l’uso in modalità kiosk con ADB, un launcher personalizzato e Device Owner. Dopo il riavvio, l’applicazione si avviava come previsto, ma il dispositivo non poteva più accedere all’interfaccia normale delle Impostazioni Android.

Ciò ha creato una sfida comune nel deployment kiosk: una volta che la navigazione del sistema e i controlli di gestione del dispositivo sono stati limitati, come è possibile recuperare il tablet per ulteriori test? E se l’applicazione deve aprire Wi-Fi o altre funzioni di sistema, quali Intent Android possono ancora essere utilizzati?

Il cliente ha innanzitutto utilizzato comandi ADB per modificare il comportamento dell’interfaccia utente di sistema:

adb shell settings put system hide_navbar 1

adb shell settings put system statusbar_disp 1

adb shell settings put system swipe_show_nav_bar 0

adb shell settings put system power_button_show 0

L’applicazione è quindi stata impostata come schermata Home predefinita, seguita dalla configurazione dell’applicazione come Device Owner abilitare le funzioni richieste di gestione del dispositivo.

Dopo il riavvio, il Tablet Android in modalità kiosk è entrato automaticamente nell'applicazione come previsto. Tuttavia, il cliente non poteva più uscire dalla schermata principale dell'applicazione per accedere alle Impostazioni Android o ad altre funzioni di sistema. Anche i pulsanti Impostazioni e Wi-Fi integrati nell'applicazione hanno smesso di aprire le corrispondenti pagine di sistema.

La domanda immediata non era semplicemente come uscire dall'applicazione. Il cliente aveva bisogno di un metodo affidabile per recuperare il Tablet Android tablet per ulteriori test e voleva anche capire quali Intent di sistema potessero essere utilizzati dalla propria applicazione.

Perché il tablet Android è diventato difficile da accedere

Il problema è derivato dall'applicazione contemporanea di diversi livelli di controllo del dispositivo.

Il launcher personalizzato determinava quale applicazione veniva visualizzata come schermata Home, mentre Device Owner concedeva all’applicazione un controllo molto più ampio sulle politiche del dispositivo. La documentazione ufficiale di Android per dispositivi dedicati supporta questo tipo di configurazione per distribuzioni in modalità kiosk e per dispositivi gestiti, inclusi il controllo dell’applicazione Home predefinita e la restrizione dell’accesso alle funzioni di sistema.

I comandi ADB aggiungevano un ulteriore livello modificando il comportamento dell’interfaccia utente di sistema. Queste specifiche impostazioni dipendono dal dispositivo o dal firmware, piuttosto che essere API Android universali, quindi il loro effetto esatto dipende da come il firmware del tablet le implementa.

Ciò significa che un Tablet Android utilizzato come dispositivo kiosk può diventare difficile da ripristinare quando launcher, configurazione Device Owner, restrizioni sull’interfaccia utente di sistema e navigazione all’interno dell’applicazione vengono modificati contemporaneamente.

Il fatto che il pulsante Impostazioni o Wi-Fi dell'applicazione non funzioni più non implica necessariamente che l'Intent stesso sia errato. L'attività Impostazioni di destinazione potrebbe essere indisponibile, limitata o comunque inaccessibile con la configurazione corrente del dispositivo. Android consiglia inoltre di verificare se un Intent può essere risolto prima di tentarne l'avvio.

Percorsi di recupero per un tablet Android kiosk bloccato

Se l'applicazione è già configurata come Device Owner, si dovrebbe considerare in primo luogo il recupero basato su software.

Android's DevicePolicyManager fornisce funzioni di gestione del dispositivo utilizzabili da un Device Owner. A seconda della versione di Android e della configurazione dell'applicazione, un'applicazione Device Owner può utilizzare il meccanismo di cancellazione del dispositivo appropriato per riportare il tablet a uno stato pulito ai fini dei test. wipeData() è l'API consolidata per la cancellazione dei dati utente, mentre le versioni più recenti di Android offrono ulteriore funzionalità di cancellazione del dispositivo.

L'obsoleta clearDeviceOwnerApp() questo metodo non deve essere considerato un metodo generale per il ripristino della produzione. La documentazione Android lo descrive come un'API orientata ai test e raccomanda il ripristino delle impostazioni di fabbrica come metodo normale per rimuovere una relazione Device Owner.

ADB fornisce anche comandi per la gestione dei criteri del dispositivo, ma questi presentano restrizioni. Ad esempio, adb shell dpm remove-active-admin non è un metodo universale per rimuovere un Device Owner; la documentazione ufficiale ADB di Android specifica requisiti quali la dichiarazione testOnly dell'applicazione.

Se il ripristino software non è disponibile perché l'applicazione non può eseguire l'operazione richiesta, l'unica alternativa rimanente è un ripristino hardware alle impostazioni di fabbrica o la procedura di ripristino Android .

La combinazione esatta di tasti non deve essere dedotta da un altro modello di tablet Android. Il comportamento in modalità di ripristino dipende dal firmware e dall'implementazione hardware del tablet. Per un progetto di tablet Android personalizzato, la procedura di ripristino appropriata deve quindi essere verificata per il modello e il firmware effettivi prima della distribuzione.

Per questo tipo di Tablet Android in modalità kiosk , avere un metodo definito di ripristino è particolarmente utile durante i test di integrazione, poiché la configurazione a livello di sistema può rimuovere intenzionalmente la normale navigazione dell’utente.

Test degli intent per le impostazioni e delle funzioni di sistema su un tablet Android

La seconda domanda del cliente riguardava la possibilità che l’applicazione avviasse direttamente funzioni di sistema come Impostazioni e Wi-Fi.

Android fornisce azioni standard per le impostazioni relative a queste funzioni. Ad esempio:

Funzione	Intent standard di Android
Impostazioni principali	Settings.ACTION_SETTINGS
Impostazioni Wi-Fi	Settings.ACTION_WIFI_SETTINGS
Impostazioni wireless	Settings.ACTION_WIRELESS_SETTINGS
Impostazioni Bluetooth	Settings.ACTION_BLUETOOTH_SETTINGS
Impostazioni display	Settings.ACTION_DISPLAY_SETTINGS
Impostazioni posizione	Settings.ACTION_LOCATION_SOURCE_SETTINGS
Impostazioni suono	Settings.ACTION_SOUND_SETTINGS
Impostazioni sicurezza	Settings.ACTION_SECURITY_SETTINGS
Impostazioni applicazioni	Settings.ACTION_APPLICATION_SETTINGS
Impostazioni specifiche dell'applicazione	Settings.ACTION_APPLICATION_DETAILS_SETTINGS

 

Queste sono azioni standard delle impostazioni Android, non interfacce specifiche di un particolare Produttore di tablet Android . Tuttavia, l'esistenza di un Intent non garantisce che verrà aperto con successo su ogni dispositivo o in ogni configurazione kiosk. Android consiglia di verificare l'Intent con resolveActivity() prima di avviarlo.

Per un tablet Android integrato a livello di sistema, i test sugli Intent devono quindi essere eseguiti sul firmware e sulla versione di Android effettivamente utilizzati per la distribuzione. Il test deve verificare non solo se l'Intent esiste, ma anche se l'Activity corrispondente è accessibile dopo aver applicato le restrizioni relative al Device Owner, al launcher e all'interfaccia utente di sistema.

Se si sta lavorando su un tablet Android per kiosk o su un progetto di integrazione di sistema e si necessita di assistenza per il ripristino del Device Owner, per gli Intent delle Impostazioni o per problemi correlati alla configurazione, contattarci fornendo il modello del tablet e la versione di Android. Possiamo discutere le opzioni disponibili di supporto tecnico e personalizzazione.

 

Lo stesso principio si applica ad altre funzioni di sistema. Potrebbe esistere un'API standard di Android, ma il comportamento effettivo di un tablet personalizzato dipende dalla sua versione di Android, dalla configurazione del firmware e dalle politiche di gestione del dispositivo.

E le richieste di risveglio?

La domanda del cliente sulle "richieste di risveglio" è leggermente diversa dall'apertura di una pagina delle Impostazioni.

Intent.ACTION_SCREEN_ON rappresenta una trasmissione di sistema che indica che lo schermo è diventato interattivo. Si tratta di una trasmissione di sistema protetta, quindi un'applicazione non deve considerarla un normale Intent che può semplicemente inviare per risvegliare il tablet.

Se il requisito è di risvegliare lo schermo, mantenerlo attivo o controllarne il comportamento di accensione , il meccanismo appropriato dipende dalle esatte esigenze dell’applicazione. Android fornisce API per la gestione dell’alimentazione e per le finestre/attività in questi scenari, inclusi PowerManager e la funzionalità di wake lock, ove opportuno.

Questa distinzione è importante quando si sviluppano applicazioni per un Tablet Android in modalità kiosk . «Avviare una funzione di sistema» e «controllare lo stato di alimentazione del dispositivo» sono operazioni di sistema diverse e devono essere gestite tramite API differenti.

Assistenza tecnica per l’integrazione del tablet Android

Questo caso illustra anche perché il deployment in modalità kiosk può richiedere più della semplice configurazione hardware di base di un tablet Android.

Quando un tablet viene integrato in un’applicazione dedicata, un sistema POS, un kiosk, un sistema industriale o un altro dispositivo gestito, la configurazione software può coinvolgere contemporaneamente il launcher, il Device Owner, l’interfaccia utente di sistema, i permessi delle applicazioni, gli Intent delle impostazioni e il comportamento di ripristino.

Per progetti che richiedono tablet Android personalizzato configurazioni: questi requisiti devono essere valutati congiuntamente alla configurazione hardware e del sistema Android, anziché essere trattati come problemi separati durante i test finali.

La soluzione appropriata dipende dalla versione di Android, dal firmware del tablet, dalla configurazione dell'applicazione e dalle funzioni che l'integratore di sistema deve controllare. La documentazione tecnica può inoltre essere redatta intorno alle interfacce di sistema disponibili, agli Intent supportati, alle autorizzazioni e ai limiti specifici del dispositivo.

Se state testando un Tablet Android per il deployment in modalità kiosk o per l'integrazione nel sistema e riscontrate problemi analoghi con Device Owner, launcher personalizzati, modalità kiosk, Intent delle Impostazioni, restrizioni sull'interfaccia utente di sistema o ripristino del dispositivo , Per favore contattaci per assistenza tecnica .

Potete fornire il modello del tablet, la versione di Android, la configurazione di deployment e la funzione specifica che intendete implementare. Possiamo quindi discutere le opzioni disponibili in termini di Personalizzazione dei tablet Android e assistenza tecnica opzioni disponibili per il tuo progetto.