#Pensando ancora (fin troppo) alle #fotocamere dei #NintendoDS, non posso fare altro che riconoscere quel pattern, secondo molti moderno ma che in realtà appunto va indietro anche di tutti questi anni, per cui #Nintendo deve per forza introdurre un peggioramento nei suoi prodotti dopo aver introdotto un qualche miglioramento… 🐞
A livello hardware non ci sono strani #particolari: le #camere hanno la stessa risoluzione (640×480, #VGA praticamente), ma quelle del 3DS dovrebbero essere più accurate; e la risoluzione dei display delle due #console è rispettivamente 256×192, e 400×240 / 320×240, quindi meglio sul #Nintendo3DS. Però il #software…
Sul #DSi, tutte le foto sono gestite e salvate nella loro risoluzione massima e sempre in 4:3. E la fotocamera offre #funzioni fighissime, alcune oggi mainstream ma all’epoca avveniristiche (come i filtri facciali che oggi sarebbero definiti “di Snapchat”), ed altre che giuro di non trovare su nessuna #app fotografica #mobile, solo su apparecchi professionali (ad esempio, la composizione live, cioè la sovrapposizione di immagini opportunamente scontornate non solo in post-produzione, ma direttamente sull’anteprima di #scatto). ✨
Il 3DS fa le #foto in 3D, molto figo, e può registrare video, ma… un sacco di quelle funzioni fighe mancano, ci sono giusto pochi filtri visivi banali, e una funzione di graffiti (equiparabile all’editor per smartphone predefinito medio) solo in post-produzione, non anche live. Niente compositing, niente roba. In compenso, la regolazione dei livelli è presente, al contrario della #fotocamera non-pro media per smartphone (GCam Lite merda), c’è l’autoscatto, e lo zoom. Però lo zoom è un po’ di pessimo gusto, perché già di base l’immagine appare fin troppo zoommata… perché? Perché, a quanto pare, l’anteprima è tagliata, perché su uno schermo 16:10 non ci entra il framebuffer della #camera 4:3 senza bordi neri. Però le foto sono salvate comunque alla massima risoluzione, e l’album permette di passare dalla visualizzazione scalata a quella intera con lo stick. Però, se si va in modalità graffiti, si può operare solo su quella porzione tagliata dell’immagine, che dopo le modifiche sarà salvata… per qualche motivo, in 640×320, che è 18:9, quindi tagliata sempre molto sopra e sotto ma ancora non alla scala nativa. Le uniche #immagini perfettamente scalate al display sono le schermate dei giochi o del menu home, e qui direi che è il minimo. 🔪
Insomma, dati questi #dettagli, non è scontato dire quale delle due app di #fotografia è migliore, e probabilmente una conviene più dell’altra solo a seconda delle situazioni. Per fortuna, su un #3DS moddato si possono avere entrambe, e infatti io me la gioco così. 📸
Non sono passati nemmeno 10 giorni da quando avevo detto “aaa è improbabile che aggiornerò ancora #MBViewer, dovrei provare a far iniziare a funzionare il progetto definitivo #alternativo migliore…” 🥴️
Però poi mi sono resa conto che: magari del #progetto alternativo non è semplice progettare tutta l’interfaccia e il suo funzionamento (cosa che va fatta, essendo una cosa da #costruire da zero), ma certamente non si posso comunque granché se prima non preparo dei #componenti logici che so già che mi dovranno servire… e allora, tanto vale iniziare a lavorare per quelli, integrandoli nella #app che (per quanto #spaghetti) è già esistente e funzionante, e acchiappare un bel 2 in 1 (espandere quel #programmino, e nel mentre accumulare codice che mi servirà per quel molto altro più tardi). 📦️
La prima cosa un po’ intricata che serve è il supporto all’ingestione di dati da #piattaforme diverse, con #schemi diversi. L’idea è di avere un solo #schema di dati che la app usa per lavorare internamente, per evitare di avere spaghetti, ma questo vuol dire che bisogna fare qualche tipo di conversione. Ci sarebbero diversi approcci: 🔪️
Il più classico sarebbe quello di scrivere (come degli schiavi indiani) delle #procedure di codice per tradurre ogni tipo di entità #API dai #formati esterni a quello interno, e viceversa… il che non solo è una pazzia, e richiede un botto di #lavoro (va scritto un numero di #funzioni complesse pari alle piattaforme da supportare, moltiplicato per 2), ma finisce per dare #rogne: appena decidiamo che lo schema di API interno va modificato o allargato, ecco che bisogna modificare in ognuna di quelle parti, ed ecco che magari escono nuovi errori e problemi. Ehhh, no, non ci sto dentro. 😩️
La mia idea, invece, è di usare un #documento di #trasformazione, almeno per quando le task sono semplicemente selezione e riassegnazione di chiavi di #dati (per operazioni più complesse, il codice è più appropriato del #markup). Era questo che avevo già provato a fare mesi fa (e funzionava eh!), ma, riguardandolo ora, mi stavo rendendo conto che lo strano #formato JSON da me inventato ha dei #limiti abbastanza forti, tra cui penso sia un casino tremendo usare 1 solo documento di #traduzione per fare sia avanti che indietro. Quindi, ho iniziato a ripensarlo da capo, ma ho pensato abbastanza in fretta che, beh… #JSON non va bene per sta roba, lo si vede anche dal come devo mettermi a scrivere chiavi tipo “__robo__“; JSON abuse, doing I am. Però l’idea credo sia bona… 😋️
E allora, fortunatamente sono tornata sana giusto in tempo, prima di #impazzire ancora una volta dopo mesi con Jason; almeno, abbastanza sana per capire che è meglio impazzire con #XML, se proprio proprio, in questo caso. E, boh, ci ho perso 1 giornata e qualcosa (soprattutto l’altra sera in cui, mezza drogata di sonno, mezza cringiata per colpa della situazione, ho iniziato ad andare un pochino mentale), ma bene o male l’ho fatto funzionare un minimo. C’è stato di tutto in mezzo ovviamente; tra cui, il #godere per aver sistemato un #bug, eccetto scoprire poco dopo che, no, nulla era sistemato… e averci dovuto perdere un’altra mezza giornata. 📆️
https://octospacc.altervista.org/wp-content/uploads/2024/01/image-9-960x451.pngIn #screenshot, i documenti di trasformazione: a sinistra, quello XML nuovissimo, credo definitivo; al centro, quello JSON vecchio: a destra, quello JSON nuovo che ho sperimentato per pochi quarti d’ora. 💎️Questa è una di quelle cose capaci di stupirmi anche se fatte da me: la sola #idea di poter raggiungere il 90% di quello scopo intricato semplicemente #componendo un documento XML in maniera adeguata, e avere vita facile per ogni #modifica, la trovo #pazza in concetto. Comunque, ho dovuto (iniziare a) scrivere una mega-funzione totalmente #originale per questa cosa perché, come già avevo constatato mesi fa, ma riconfermato appunto ieri, tutte le #librerie in giro per fare trasformazioni di dati così sono troppo generiche, a quel punto usare quelle sarebbe anche peggio che fare tutto in #codice. E credo di aver cercato fin troppo in giro. E, ahimè, prima o poi soffrirò di nuovo, perché dovrò scrivere pure la #funzione di traduzione inversa! 😵💫️
Che centra con la #applicazione mezza kangata? In pratica, avendo integrato questo #sistema già da ora, MBViewer può visualizzare (alcuni) #feed#RSS, e (con qualche problema, per ora) #profili#Mastodon, il che non è male. È male, invece, il mio aver scoperto solo ora che su Firefox avviene un problema con il parsing dei feed RSS, che dovrò sistemare… ma su #Chromium funziona tutto. Oh well. Ohhh, it’s so well. I #glitch non finiscono mai, la tortura della #programmazione è eterna!!! 😭️
Ho preso 5 minuti (uhmm, no, magari) per un breve #ReverseEngineering di quella parte della #applicazione, arrivando a questa sezione del file (baksmaliato dall’ultima versione presente su APKMirror) smali_classes6/posteitaliane/posteapp/apppostepay/ui/activity/SplashActivity.smali, che invoca il dialogo di avviso in foto: 🤓️
# riga 4358.method public final e()V# ... inizializzazione di altra roba# riga 4503new-instance v1, Lcom/scottyab/rootbeer/b;invoke-direct {v1, v0}, Lcom/scottyab/rootbeer/b;-><init>(Landroid/content/Context;)Vinvoke-virtual {v1}, Lcom/scottyab/rootbeer/b;->a()Zmove-result v1if-eqz v1, :cond_2# ... visualizza il dialogo se il codice sopra non ha saltato# riga 4542:cond_2# ... ritorna e termina il metodo
Detto in italiano, questo #codice invoca un metodo (dal nome offuscatino?) presente in una certa classe “com.scottyab.rootbeer“… ed esce fuori, con una #ricerca sul web, che questa è una #libreria#OpenSource (evidentemente integrata dagli sviluppatori di #PostePay) per controllare se un #dispositivo Android è #rootato. (Non se passa o meno #SlaveryNet, attenzione.) 🍻️
È un po’ troppo rubatempo mettersi a capire quale effettivamente è nel codice Java quella funzioncina b;->a()Z ora, quindi tiriamo a #indovinare. Ci sono, in RootBeer.java, tante #funzioniboolean, di cui varie ausiliarie, e 2 principali: isRooted[With/Without]BusyBoxCheck(). Queste due principali restituiscono un valore positivo qualora anche solo una delle ausiliari chiamate restituisca true, l’unica differenza tra le due è il fare anche il controllo per la presenza del binario busybox, oppure no… E quindi le opzioni sono le seguenti: 📜️
checkForBinary(BINARY_SU), checkSuExists(), checkForRootNative(), checkForMagiskBinary(): controllo effettivo del root; escludo, da quel che ricordo il suo telefono non è rootato, ed avendo il bootloader bloccato direi che possiamo stare tranquilli.
detectRootManagementApps(): scarto, se il telefono non è rootato non avrebbe senso tenere app di gestione del root.
detectPotentiallyDangerousApps(): controlla se sono installate app “a umma umma”; escludo perché credo nessuna sia utile senza il root, e qualcuna forse è pure malware… eccetto Lucky Patcher, che però ad oggi si auto-spoofa.
checkForRWPaths(): scarto, controlla se alcuni percorsi sensibili sono scrivibili, immagino di no col bootloader bloccato e senza root.
checkForDangerousProps(): da verificare, controlla se alcune #BuildProps di Android sono particolari.
detectTestKeys(): inizialmente sospettavo, ma lo abbiamo verificato (con getprop | grep build.tags), e pare non sia il caso (tutto è listato come “release-keys“).
checkForBinary(BINARY_BUSYBOX): questa potrebbe essere, ed è #interessante, controlla come ho detto prima la presenza del binario busybox, ma da questo commit del 2020 non è più usata nel check predefinito perché — come detto nel commento in quella parte di #source, e alla sezione “False positives” del readme — alcuni #OEM lo lasciano quando non dovrebbero (io credevo fosse normale tralaltro, non un’anomalia!).
Quest’ultima #ipotesi mi cattura perché innanzitutto, te micro hai proprio un #MotoEda quello che ricordo, che è uno dei #telefoni listati esplicitamente sul readme… certo, se la #lib usata nella app fosse stata aggiornata, questo non sarebbe dovuto succedere, a meno che i programmatori delle #Poste non abbiano stupidamente usato la funzione di #controllo aggressiva. Però tbh, considerando la qualità del #software#statale o semi-statale qui in #Italia, secondo me semplicemente quella #dipendenza non è mai stata aggiornata (da un lato però, come biasimarli… “se funziona, non toccare”…). Al momento però non riesco a #provare ciò, perché non trovo #APK abbastanza vecchi di PostePay, quindi lancio solo #idee al vento. 😩️
Io punto su #busybox per risolvere questo #mistero. Lo #smartphone non è il mio, quindi io ora posso solo aspettare, se dovessero uscire novità farò un banale edit. (Sperando non siano così grosse da necessitare di un nuovo #messaggio). 😼️
Edit: non ci ho beccato nemmeno per il cavolo: dalla regia, che ha ora testato con il #programma di #test di #RootBeer, vengo a scoprire #malamente che le mie opzioni tecnicamente più plausibili si sono rivelate sbagliate. “Root Management Apps” è cosa fa scattare gli allarmi, cosa che io giustamente ho escluso a priori, ma la regia mi fa appunto sapere che aveva #Magisk Manager installato (soltanto a prendere polvere perché, questo l’ho pensato bene, non ha il root nell’effettivo); e, come previso, la disinstallazione mette a tacere i falsi positivi. Vabbè oh, non potevo immaginarmelo… 🤕️
Diversi anni fa testai, con scarsi risultati, https://nebula.chat, una #reimplementazione#OpenSource del #server di Telegram, perché ne scoprii l’esistenza ed era #intrigante come concetto. A quanto pare ha cambiato nome, ora si chiama #Teamgram, l’ho scoperto qualche ora fa quando mi è tornato in mente questo fatto e ho voluto ritestare il #progetto. 💍
Sembra che lo #sviluppo sia andato parecchio avanti, ora pare che le #chat private e i canali funzionino in modo praticamente perfetto (non ho testato i gruppi), con addirittura le #chiamate vocali (credo, non ho potuto controllare se si sentisse), e anche i bot. Questo l’ho verificato sulla #istanza ufficiale di #test, ma in teoria è #selfhostabile… solo che non capisco come mai sul #Git il #README dica che queste ultime #funzioni succose siano “enterprise” (e di contattare il tizio lì se se ne ha bisogno), e tra le #issue c’è chi dice che non riesce appunto ad usarle, ricevendo errori che dicono proprio che siano cose di un’edizione #enterprise. Cercando nei #sorgenti stringhe come ErrEnterpriseIsBlocked riesco a trovare qualche parte che fa riferimento a “chiave di licenza da https://teamgram.net/ richiesta per sbloccare le funzioni enterprise”, ma non vedo controlli di licenza nelle molte parti che tirano questo errore, che tralaltro sembrano fare esclusivamente quello. In sostanza, sento puzza di #codice mancante dalle #repo pubbliche, e se ci ho azzeccato è un peccato. 👾
In ogni caso, non so che tipo di utilità pratica possa avere. Forse giusto se si vogliono creare #comunità#online#sovrane in contesti dove #Telegram sarebbe preferibile (per abitudine, principalmente), ma quello vero per un motivo o un altro non si può usare (visto che ormai è gestito sempre peggio…), o probabilmente in #team collaborativi, perché altrimenti l’assenza di federazione è limitante. Comunque è giusto tenerci su un occhio. https://github.com/teamgram ✈️