Android Canary è un programma di anteprima di Android che Google ha messo in piedi nel mese di luglio per rimpiazzare le vecchie Developer Preview, proponendo mensilmente build in anteprima che si collocassero “un gradino prima” rispetto alle Beta.
L’ultima build disponibile, distribuita sui Pixel registrati a questo programma un paio di giorni fa, non porta con sé tante novità tangibili ma nasconde i lavori in corso per un paio di funzionalità che, probabilmente, dalle parti di Mountain View stanno sviluppando in ottica Android 17.
Indice:
Segui TuttoAndroid su Google Discover
roborock Qrevo Curv 2 Flow
Offerta + clicca su applica coupon di 50 euro + coupon: TTANDROID5
Android 17 potrebbe protare al debutto il blocco delle app con codice o accesso biometrico
Analizzando la build 2512 distribuita sul canale Android Canary, il noto insider Mishaal Rahman ha scoperto, all’interno del pacchetto del framework di Android, del codice sorgente che fa riferimento a una nuova API chiamata App Lock (via Android Authority) che, in soldoni, permetterà agli utenti di bloccare un’app del launcher e renderla accessibile solo inserendo un codice “di sblocco” o procedendo con l’autenticazione biometrica.
L’accesso a questa API è protetto dalla nuova autorizzazione LOCK_APPS che è limitata alle app interne al sistema e all’app che detiene il ruolo HOME, ovvero quello assegnato automaticamente al launcher predefinito (nel caso dei Pixel è “Avvio app Pixel”, più ampiamente noto come Pixel Launcher).
<permission android:featureFlag=”android.security.app_lock_apis” android:name=”android.permission.LOCK_APPS” android:protectionLevel=”internal|role”/>
Sfruttando questa autorizzazione, il launcher predefinito può richiamare l’autorizzazione LOCK_APPS di Android tramite l’intent SET_APP_LOCK: il sistema convaliderà la richiesta verificando se l’app di destinazione presenta una corrispondenza nel launcher e ne verifica lo stato di blocco. Se l’app è idonea al blocco, verrà mostrato un messaggio che chiede all’utente se vuole bloccare l’app; se l’app è bloccata ed è quindi idonea allo sblocco, verrà mostrata una finestra di dialogo che chiede se sbloccarla (un messaggio pop-up informerà in caso di esito positivo del tentativo di sblocco).
<string name=”enable_app_lock_dialog_enable_button_text”>Lock</string>
<string name=”enable_app_lock_dialog_title”>Lock %1$s?</string>
<string name=”enable_app_lock_failure_toast_message”>”Can’t lock %1$s”</string>
<string name=”enable_app_lock_success_toast_message”>%1$s is locked</string><string name=”disable_app_lock_dialog_disable_button_text”>Remove lock</string>
<string name=”disable_app_lock_dialog_title”>Remove App Lock from %1$s?</string>
<string name=”disable_app_lock_success_toast_message”>App Lock is removed from %1$s</string>
App Lock funzionerà solo con Android (niente Wear OS, Android Automotive e Android TV), dato che è pensata esclusivamente per smartphone e tablet, e funzionerà solo con quando sul dispositivo è attivo il profilo dell’utente principale (non è compatibile con i profili utente supervisionati, ad esempio).
L’estetica e l’implementazione effettiva della funzionalità dipenderà dallo sviluppatore del launcher: Google si limita, infatti, a mettere a disposizione degli sviluppatori gli strumenti per potere sfruttare App Lock ma saranno gli sviluppatori stessi a scegliere se e come integrarlo nel launcher.
Allo stato attuale dello sviluppo, Google non ha ancora inserito il codice per proteggere lo sblocco delle app ma, in futuro, potrebbe sfruttare l’API Biometric Prompt già esistente di Android per fornire un metodo standard come protezione delle app (che abilita lo sblocco con tutti i metodi di sblocco disponibili sul dispositivo).
In termini di tempistiche per il rilascio è molto difficile azzardare ipotesi ma è certo che nulla di tutto ciò possa far parte di Android 16 QPR3: il prossimo aggiornamento trimestrale di Android non metterà a disposizione degli sviluppatori nuove API; per quelle dovremo attendere Android 17. Non è nemmeno detto che la prima versione di Android 17 possa includere queste modifiche: d’altronde, Big G rilascerà nuove API anche con Android 17 QPR2 a dicembre 2026.
Sempre Mishaal Rahman, facendo seguito alle scoperte del mese scorso, ha individuato nella build 2512 di Android Canary ulteriori sviluppi legati alle nuove funzionalità di gioco offerte da Android 17 (via Android Authority).
Nello specifico, l’insider è riuscito ad abilitare il nuovo menù Impostazioni controller di gioco che attualmente è nascosto ma in futuro apparirà nella pagina dei dettagli del dispositivo collegato via Bluetooth quando è collegato allo smartphone un controller compatibile (e il DualSense di Sony sembra esserlo).
Questo menù contiene due sezioni: la prima serve rimappare i pulsanti (ci rientrano A, B, X, Y, L1, L2, R1, R2, click dello stick di sinistra, click dello stick di destra); la seconda serve per rimappare i controlli di direzione (d-pad, stick di sinistra e stick di destra). Toccando una delle opzioni disponibili, si apre una finestra di dialogo che consente di personalizzare l’input che verrà poi inviato alle app con cui interagiamo tramite il controller di gioco.
Questa aggiunta non andrà a stravolgere l’esperienza d’uso in gaming su Android, specie considerando che il sistema operativo supporta nativamente da tempo i controller di gioco. Più semplicemente, questa funzionalità permetterà agli utenti di personalizzare l’esperienza d’uso del controller, alla pari di come è già possibile giocando da PC o da console, avvicinando così l’esperienza in-game su Android a quella delle piattaforme più utilizzate.
Allo stato attuale la funzionalità è ancora in fase di sviluppo e il menù “nascosto” rimane generico a prescindere da quale controller vi sia collegato (d’altronde il controller DualSense di Sony non presenta i pulsanti A, B, X o Y). Google potrebbe quindi perfezionare il tutto prima del lancio di questa funzionalità, magari personalizzando il menù per adattarsi al controller connesso e includere gli eventuali pulsanti aggiuntivi (non standard) presenti su di esso.