Secondo una serie di impegni in AOSP, Google potrebbe iniziare a limitare l'accesso alle API non documentate o nascoste in Android P. Molte app di marca utilizzano API nascoste per aumentare la funzionalità, quindi l'effetto potrebbe essere diffuso.
Aggiornamento 28/02/18: Google ha pubblicato oggi un post sul blog confermando le modifiche. Maggiori dettagli alla fine dell'articolo.
Mentre alcuni appassionati di Android lo sono speculando da che dolce prenderà il nome la prossima versione di Android, ci sono alcuni sviluppi interessanti in corso dietro le quinte. Abbiamo individuato un pochi degni di nota funzionalità imminenti di Android P, ma una scoperta più recente nell'Android Open Source Project (AOSP) si è rivelata molto più interessante. Secondo questi recenti impegni, alle applicazioni potrebbe essere impedito l'accesso alle API non documentate nell'SDK di Android (come le API contrassegnate dall'attributo javadoc @hide).
Perché questo è importante
L'Android Software Development Kit (SDK) fornisce agli sviluppatori le librerie API e gli strumenti necessari per testare e creare nuove applicazioni Android. Con ogni nuova versione di Android arrivano tutta una serie di nuove API disponibili per gli sviluppatori tramite Android SDK. Le API disponibili per un'app dipendono da quale compileSDKVersion imposta lo sviluppatore. Ecco perché Google
Host di Google pagine di documentazione per ogni classe e tutti i relativi metodi disponibili in ciascun livello API. Si tratta dell'insieme di API documentate disponibili nell'SDK Android ufficiale. Puoi sfogliare facilmente l'elenco delle classi utilizzando un'app Android come l'app Android SDK Search recentemente rilasciata da Android Engineer Jake Wharton.
Prezzo: gratuito.
4.1.
Tuttavia, non tutte le API disponibili in ogni versione di Android sono documentate da Google o disponibili nell'SDK Android ufficiale. Spesso ci sono API utili che lo sono non documentato, ma sono comunque molto utili. Non è consigliabile che gli sviluppatori creino le proprie app utilizzando API non documentate o nascoste, ma molti lo fanno perché semplicemente non c'è alternativa se vogliono offrire una determinata funzionalità. Anche gli sviluppatori che utilizzano API nascoste o non documentate possono ottenere un vantaggio competitivo, poiché possono offrire funzionalità che i loro concorrenti, che si attengono alle API offerte da Android SDK: impossibile.
Anche se non posso fornire un elenco di app che utilizzano API non documentate (gli sviluppatori probabilmente non condividono quali usano perché darebbe un vantaggio ai loro concorrenti), l'elenco probabilmente è piuttosto lungo grande. Pertanto, concluderei che vietare l’accesso alle API nascoste sarebbe significativo. Mark Murphy, fondatore di Commonware, concorda:
Sono d'accordo con la valutazione secondo cui vietare in blocco l'accesso agli elementi @hide-annotated sarebbe un grosso problema, se ciò dovesse accadere. Si spera che poche app accedano a questi elementi come parte delle funzionalità chiave. Tuttavia, sospetto che molte app di marca le utilizzino occasionalmente, direttamente o tramite una libreria.
Cosa sta succedendo ad Android P?
Questi cambiamenti imminenti sono stati notati per la prima volta dallo sviluppatore riconosciuto senior XDA rovo89, lo sviluppatore di Quadro Xposed. Mi ha indicato due impegni, uno dei Quale è stato fusi, che introduce un nuovo strumento di creazione chiamato "hiddenapi". Questo strumento modifica i flag di accesso di tutti i membri della classe all'interno di un file DEX se le loro firme appaiono su una greylist o blacklist di input e, in tal caso, i metodi contrassegnati verranno trattati come API interne con restrizioni accesso. L'altro commit descrive come funziona la lista nera dell'API; impedisce l'accesso a classe di avvio metodi e campi contrassegnati dal suddetto "hiddenapi" a cui gli sviluppatori possono accedere tramite collegamento statico, riflessione e JNI.
Secondo rovo89, il risultato finale di queste due modifiche in Android P è il seguente:
Se questi commit venissero uniti, significherebbe che le app non potranno più utilizzare/accedere alle API nascoste classi, metodi e campi annotati con @hide in AOSP e quindi non fanno parte del file SDK ufficiale. Questo non sarebbe un problema per i moduli Xposed poiché potrei facilmente ripristinare tali commit o consentire anche ai moduli di farlo accedere a queste API. Ma ci sono molte app che sfruttano le API nascoste e queste fallirebbero futuro.
In effetti, ulteriori impegni mostrano che questo potrebbe essere ciò che Google sta pianificando. Questo commettere afferma quanto segue:
Anche se questo particolare commit non è stato unito poiché è stato abbandonato a favore di 3 commit più piccoli, il messaggio di commit descrive lo scopo di queste modifiche. Un'altra serie di commette mostrano che Google suggerirà alternative agli sviluppatori che cercano di utilizzare API non pubbliche:
Tuttavia, spesso non esistono alternative a determinate API nascoste. Noi di XDA possiamo parlare per esperienza qui come sfortunatamente questo cambiamento potrebbe segnare la fine di alcune app innovative o potrebbe richiedere ad alcune app di grandi nomi di ridurne la portata funzionalità. Questo cambiamento imminente sembra simile nello spirito a quello recente giro di vite sui servizi di accessibilità (questo è stato per fortuna in pausa mentre Google valutava usi innovativi). Sebbene la maggior parte delle app che utilizzano API non documentate lo facciano per motivi benigni, potrebbero esserci alcune app che le hanno utilizzate in modo improprio per scopi nefasti.
Per questo motivo, Google potrebbe bloccare l'accesso a tutte le API nascoste in Android P per salvaguardare gli utenti dai pochi che ne abusano. È difficile dire quale impatto ciò potrebbe avere sugli utenti, ma se sei uno sviluppatore considerando di cercare attraverso AOSP per trovare un uso innovativo di un'API nascosta, allora potresti volerlo fare riconsiderare.
Aggiornamento: Google conferma
In un post sul blog pubblicato oggi, 28 febbraio, Google ha confermato queste modifiche. Citando i rischi di crash per gli utenti e successivamente costringendo gli sviluppatori a implementare soluzioni di emergenza, Google afferma che la società si è gradualmente spostata verso lo scoraggiamento degli sviluppatori dall'accesso a prodotti non SDK interfacce. A partire da Android P, le restrizioni si espanderanno per coprire le interfacce in linguaggio Java dell'SDK.
La società afferma che "alcuni metodi e campi non SDK saranno limitati", sebbene non abbiano spiegato quali sarebbero stati limitati. Inizialmente la restrizione si concentrerà sulle interfacce utilizzate raramente e per un po’ l’azienda lo consentirà gli sviluppatori continuino a utilizzare metodi e campi non SDK in cui la transizione a un metodo SDK è tecnicamente stimolante. Tuttavia, col tempo le restrizioni verranno ampliate, quindi gli sviluppatori di app che utilizzano metodi non SDK dovrebbero effettuare la transizione il prima possibile in preparazione ad Android P. Per quanto riguarda i metodi senza un'alternativa all'SDK, Google richiede agli sviluppatori di pubblicare sul proprio file localizzatore di bug con maggiori informazioni.
La prossima anteprima per sviluppatori, apparentemente in arrivo, consentirà agli sviluppatori di testare le app esistenti rispetto alla blacklist o alla greylist prima del rilascio finale.