Ogni sistemista Linux, prima o poi, si trova davanti a una domanda che top o free non riescono a risolvere del tutto: perché questo processo consuma tanta memoria? Perché una porta risulta occupata ma netstat non mostra nulla? Perché un servizio continua a scrivere su un file che, in teoria, è stato cancellato? La risposta, quasi sempre, si trova in un posto che molti amministratori conoscono solo superficialmente: /proc.

/proc non è una directory come le altre. È un filesystem virtuale, di tipo procfs, generato e mantenuto interamente dal kernel in memoria: non un singolo byte dei suoi contenuti risiede su disco. È, di fatto, una finestra live sullo stato interno del kernel, esposta attraverso strumenti che ogni sistemista già conosce: cat, grep, awk. Comandi come free, ps, top e iostat non fanno altro che leggere e formattare i dati che /proc mette a disposizione: imparare a leggerlo direttamente significa avere accesso alle stesse informazioni, ma senza filtri, e con la possibilità di combinarle in modi che nessun tool preconfezionato offre.

La struttura: due mondi in una directory

/proc contiene sostanzialmente due categorie di contenuti. Da un lato le directory numerate, una per ogni processo in esecuzione (/proc/1234/, dove 1234 è il PID), che espongono lo stato specifico di quel processo. Dall’altro i file di sistema globali, come /proc/meminfo o /proc/cpuinfo, che riflettono lo stato del kernel nel suo complesso, indipendentemente da quale processo li legga.

I file di sistema che contano davvero

/proc/cpuinfo e /proc/stat

/proc/cpuinfo elenca i core logici della CPU con modello, velocità di clock, dimensione della cache e i flag di supporto per estensioni come vmx (virtualizzazione hardware), aes e avx2. Un one-liner molto usato per contare le CPU logiche disponibili è:

grep -c '^processor' /proc/cpuinfo

/proc/meminfo: oltre a “free”

/proc/meminfo è la fonte dati grezza dietro al comando free, ma contiene molti più campi di quelli che free mostra normalmente. Due meritano attenzione particolare: MemAvailable, che indica la memoria realmente disponibile per nuovi processi tenendo conto della cache riclamabile (a differenza di MemFree, che è quasi sempre un numero fuorviante), e Dirty, che riporta quanta memoria contiene dati modificati ancora in attesa di essere scritti su disco — un valore che cresce pericolosamente su sistemi con storage lento e scritture intense.

Per un monitoraggio in tempo reale della pressione di memoria, questo comando è estremamente utile in fase di troubleshooting:

watch -n1 'grep -E "MemAvailable|Dirty|Writeback|SwapFree" /proc/meminfo'

/proc/diskstats, /proc/loadavg, /proc/net/

/proc/diskstats fornisce le statistiche I/O per dispositivo — letture, scritture, settori trasferiti, tempo speso in operazioni — ed è la fonte dietro iostat. /proc/loadavg espone le tre celebri medie di carico a 1, 5 e 15 minuti, mentre /proc/uptime riporta i secondi trascorsi dal boot e il tempo cumulativo di inattività della CPU.

La sottodirectory /proc/net/ merita un capitolo a sé: /proc/net/dev contiene i contatori di byte e pacchetti per ogni interfaccia di rete, /proc/net/tcp e tcp6 elencano tutte le connessioni TCP attive in formato esadecimale, /proc/net/sockstat riassume l’utilizzo dei socket a livello di sistema, e /proc/net/snmp espone contatori SNMP utili per individuare retransmit e fallimenti di connessione anomali.

Il mondo per-processo: /proc/PID/

Qui si trova la parte più preziosa per il debugging quotidiano. Alcuni file chiave:

• /proc/PID/cmdline — il comando esatto con cui il processo è stato lanciato, con gli argomenti delimitati da byte null.
• /proc/PID/status — un riepilogo leggibile con UID, GID, utilizzo di memoria e numero di thread. Il campo VmRSS indica la memoria residente effettivamente occupata, mentre VmSwap segnala se (e quanto) il processo è finito in swap.
• /proc/PID/fd/ — una directory di symlink, uno per ogni file descriptor aperto dal processo. È la base dati su cui si appoggia lsof. Contare i descrittori aperti è semplice: ls /proc/12345/fd | wc -l.
• /proc/PID/io — la contabilità I/O del processo, con read_bytes e write_bytes che riflettono i dati effettivamente passati al layer di storage.
• /proc/PID/maps e /proc/PID/smaps — le regioni di memoria mappate dal processo (codice, stack, heap, librerie condivise). smaps va oltre e fornisce, per ogni regione, i dettagli su RSS, PSS e swap.
• /proc/PID/environ — le variabili d’ambiente al momento del lancio, anch’esse delimitate da byte null.
• /proc/PID/cwd e /proc/PID/exe — symlink rispettivamente alla directory di lavoro corrente e all’eseguibile su disco. Sono fondamentali per identificare binari che sono stati cancellati o sostituiti mentre il processo era ancora in esecuzione (un classico segnale da cercare dopo un aggiornamento di sicurezza mal gestito).
• /proc/PID/oom_score e oom_score_adj — il punteggio che l’OOM killer del kernel usa per decidere quale processo terminare per primo in caso di esaurimento memoria. oom_score_adj, con un range da -1000 a 1000, permette di proteggere o “sacrificare” volontariamente un processo specifico.

Due scorciatoie tornano utili spesso: /proc/self/ punta sempre al processo che sta effettuando la lettura, mentre /proc/$$/ punta alla shell corrente all’interno di uno script.

Casi pratici di troubleshooting

Trovare quale processo ha in ascolto una determinata porta (qui la porta 443/0x01BB su IPv6), senza usare ss o lsof:

inode=$(awk '$2 ~ /:01BB$/ {print $10; exit}' /proc/net/tcp6)
ls -l /proc/*/fd/ 2>/dev/null | grep "socket:[$inode]"

find /proc/*/fd -ls 2>/dev/null | grep '(deleted)'

cat /proc/interrupts | head -20

/proc/sys e il tuning via sysctl

Sotto /proc/sys/ si trovano i file scrivibili che espongono i tunable del kernel — la stessa interfaccia usata da sysctl. Ad esempio, per modificare a caldo la propensione del kernel allo swap:

echo 10 | sudo tee /proc/sys/vm/swappiness

/proc dentro i container

Un punto che genera spesso confusione: /proc è namespace-aware. Dentro un container Docker, la directory mostra il namespace PID del container, non quello dell’host — il PID 1 visto dall’interno è l’entrypoint del container, non l’init dell’host. Attenzione però: campi come quelli di /proc/meminfo o /proc/stat spesso riflettono ancora i totali dell’host e non i limiti imposti dai cgroup al container, un dettaglio che ha tratto in inganno più di un tool di monitoring scritto ingenuamente.

/proc contro /sys: quando usare cosa

/sys (sysfs) è il filesystem virtuale complementare a /proc, ma orientato al modello dei dispositivi del kernel: driver, bus, block device, gestione dell’energia. Un esempio tipico è /sys/devices/system/cpu/cpu0/cpufreq/, che espone i parametri di scaling della frequenza per singolo core. La regola pratica: /proc per processi e stato del kernel a livello di sistema, /sys per configurazione e stato dei dispositivi hardware.

Conclusione

Conoscere /proc non è un esercizio accademico: è uno degli strumenti diagnostici più potenti a disposizione di un sistemista Linux, proprio perché sta sotto ogni tool di monitoring che si finisce per usare quotidianamente. Quando top, free o netstat non bastano — o semplicemente non sono installati sulla macchina compromessa o minimale su cui ci si trova a lavorare — sapere leggere direttamente /proc/meminfo, /proc/PID/status o /proc/net/tcp fa la differenza tra un troubleshooting rapido e ore perse a indovinare. Vale la pena tenere a portata di mano, come riferimento minimo, i file /proc/meminfo, /proc/cpuinfo, /proc/stat, /proc/net/dev e la struttura di /proc/PID/: coprono la stragrande maggioranza dei casi reali di debugging su sistemi in produzione.

Fonte originale: A Guide to Linux /proc Filesystem, LinuxBlog.io

C’è una minaccia alla crittografia moderna che non richiede un computer quantistico funzionante oggi per essere reale oggi: si chiama “harvest now, decrypt later” (raccogli ora, decifra dopo). Un attaccante con risorse sufficienti — uno stato-nazione, tipicamente — può intercettare e archiviare traffico cifrato con RSA o ECC adesso, per poi decifrarlo tra qualche anno, quando computer quantistici sufficientemente potenti saranno disponibili. Per dati con un ciclo di vita lungo — segreti industriali, cartelle cliniche, comunicazioni diplomatiche, chiavi di firma di lungo periodo — la finestra di esposizione è già aperta, anche se il computer quantistico “rompi-RSA” non esiste ancora.

È in questo contesto che Microsoft ha recentemente pubblicato una guida al threat modeling applicato specificamente alla migrazione verso la crittografia post-quantistica (PQC), invitando organizzazioni e team di sviluppo a non aspettare la disponibilità degli algoritmi per cominciare a muoversi.

Perché serve il threat modeling, e non solo un elenco di algoritmi

Il problema centrale che Microsoft evidenzia non è tecnico in senso stretto, è organizzativo: la maggior parte delle aziende non ha un inventario completo di dove e come viene usata la crittografia nei propri sistemi. Certificati TLS, librerie di firma incorporate in applicazioni legacy, hardware embedded con chiavi hard-coded, protocolli proprietari che usano RSA “perché si è sempre fatto così” — sono tutte dipendenze crittografiche nascoste che un aggiornamento generico non intercetta.

Il threat modeling applicato alla PQC serve esattamente a questo: mappare asset, flussi di dati, confini di fiducia (trust boundary) e controlli di sicurezza esistenti per far emergere queste dipendenze prima che diventino un problema urgente sotto pressione regolatoria o, peggio, sotto attacco. Concretamente, significa rispondere a domande come: quali sistemi cifrano dati che devono restare confidenziali per più di 5-10 anni? Quali certificati di firma del codice hanno una validità che si estende oltre il 2030? Quali protocolli interni non supportano l’agilità crittografica, cioè non permettono di sostituire un algoritmo senza riscrivere l’applicazione?

Gli algoritmi: da NIST a nomi che iniziano a essere familiari

Dopo anni di standardizzazione, il NIST ha pubblicato tre standard che è ormai il momento di conoscere, perché stanno entrando nei prodotti che usiamo quotidianamente:

• ML-KEM (Module-Lattice Key Encapsulation Mechanism, FIPS 203) — sostituisce lo scambio di chiavi basato su RSA o curve ellittiche (ECDH). È l’algoritmo che entra in gioco nell’handshake TLS per stabilire un segreto condiviso.
• ML-DSA (Module-Lattice Digital Signature Algorithm, FIPS 204) — l’algoritmo di firma digitale post-quantistico, pensato come sostituto di RSA e ECDSA per firmare certificati, codice e messaggi.
• SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, FIPS 205) — un algoritmo di firma alternativo, basato su funzioni hash anziché su reticoli, pensato come backup conservativo nel caso in cui in futuro emergano debolezze crittanalitiche nei problemi su reticolo.

Sul fronte delle raccomandazioni pratiche, Microsoft insiste su un punto spesso sottovalutato: la migrazione a TLS 1.3 è il prerequisito, non un dettaglio. TLS 1.2 non supporta i meccanismi ibridi necessari per introdurre ML-KEM accanto agli algoritmi classici, e restare su TLS 1.2 significa restare bloccati fuori dalla transizione PQC anche quando gli algoritmi saranno pronti. In parallelo, si consiglia di alzare l’asticella anche sulla crittografia simmetrica e sulle funzioni hash, adottando AES-256 e SHA-384 come standard, per mantenere margini di sicurezza adeguati anche in scenari quantistici (dove alcuni attacchi, come Grover, dimezzano di fatto la sicurezza effettiva degli algoritmi simmetrici).

La timeline che Microsoft si è data per la transizione dei propri prodotti e servizi critici è il 2029 — una data che vale la pena tenere a mente come riferimento di settore, anche per pianificare le proprie migrazioni interne con lo stesso ordine di grandezza.

Cosa c’è già oggi: le API disponibili

La parte più interessante per chi scrive codice è che la PQC non è più solo teoria da paper accademico: le API sono già disponibili e generalmente disponibili (GA) sulle piattaforme Microsoft.

Windows: CNG

Su Windows, il supporto arriva a livello di CNG (Cryptography API: Next Generation), con identificatori di algoritmo dedicati per ML-KEM e ML-DSA utilizzabili tramite le funzioni BCryptGenerateKeyPair e le relative API di key exchange e firma. Il supporto nativo è arrivato a partire da Windows 11 con gli aggiornamenti di novembre 2025: chi gestisce flotte Windows dovrebbe verificare di essere allineato con le patch più recenti prima di pianificare qualunque test.

.NET 10: MLKem e MLDsa in System.Security.Cryptography

Per chi sviluppa in C#, la notizia più concreta è l’arrivo delle classi MLKem e MLDsa direttamente in System.Security.Cryptography con .NET 10. Ecco un esempio minimo di key encapsulation:

using System.Security.Cryptography;

if (!MLKem.IsSupported)
{
    Console.WriteLine("ML-KEM non è supportato su questa piattaforma");
    return;
}

MLKemAlgorithm alg = MLKemAlgorithm.MLKem768;

using (MLKem privateKey = MLKem.GenerateKey(alg))
using (MLKem publicKey = MLKem.ImportEncapsulationKey(
    alg, privateKey.ExportEncapsulationKey()))
{
    publicKey.Encapsulate(out byte[] ciphertext, out byte[] sharedSecret1);
    byte[] sharedSecret2 = privateKey.Decapsulate(ciphertext);

    bool match = sharedSecret1.AsSpan().SequenceEqual(sharedSecret2);
    Console.WriteLine($"I segreti condivisi coincidono: {match}");
}

MLDsaAlgorithm alg = MLDsaAlgorithm.MLDsa65;

using (MLDsa key = MLDsa.GenerateKey(alg))
{
    byte[] data = "Messaggio da firmare"u8.ToArray();
    byte[] signature = new byte[alg.SignatureSizeInBytes];

    key.SignData(data, signature);
    bool verified = key.VerifyData(data, signature);

    Console.WriteLine($"Firma verificata: {verified}");
}

Un paio di note pratiche per chi vuole sperimentare da subito: su Linux serve OpenSSL 3.5 o superiore, mentre chi è ancora su .NET Standard 2.0 può accedere alle stesse API tramite il pacchetto NuGet Microsoft.Bcl.Cryptography. Per il supporto lato TLS 1.3, certificati basati su ML-DSA e SLH-DSA funzionano già in scenari di autenticazione quando sia il sistema operativo sia la controparte della connessione supportano i nuovi algoritmi — un altro motivo per cui la coordinazione tra client e server nella transizione non è opzionale.

Da dove cominciare, in pratica

Per un team che affronta questo tema per la prima volta, un percorso ragionevole è: primo, effettuare un inventario reale di certificati, librerie crittografiche e protocolli in uso, distinguendo per criticità e durata di vita dei dati protetti; secondo, verificare che l’infrastruttura TLS sia già su 1.3 ovunque possibile, perché è il prerequisito tecnico per tutto il resto; terzo, iniziare a sperimentare le nuove API — su .NET 10 il costo di ingresso è basso, si tratta di poche righe di codice — in ambienti non di produzione, per capire l’impatto su dimensioni di chiavi, firme e tempi di calcolo prima che diventi un requisito con scadenza stretta.

La crittografia post-quantistica non è ancora un’emergenza operativa per la maggior parte delle organizzazioni, ma il messaggio di Microsoft è chiaro: il momento di mappare le proprie dipendenze crittografiche e cominciare a testare gli algoritmi è adesso, non quando arriverà l’obbligo normativo o il primo incidente.

Fonte originale: Microsoft Urges Threat Modeling to Prepare for Post-Quantum Cryptography Migration, Petri IT Knowledgebase

Si parla di:
Toggle

Una pagina che imita alla perfezione la schermata di aggiornamento di Google Chrome, un dropper che scarica il payload reale solo dopo, e un abuso sistematico dei servizi di accessibilità Android per leggere in tempo reale le chat di Telegram, WhatsApp e Signal senza mai toccare la loro crittografia end-to-end. È DragonDoll, lo spyware commerciale che il Positive Technologies Expert Security Center (PT ESC) ha tracciato in almeno 26 Paesi, Russia inclusa, con circa 150 campioni caricati in appena due mesi su un repository GitHub pubblico.

Un finto aggiornamento, un dropper vero

La catena d’infezione comincia con un APK che si spaccia per “Chrome.apk” e adotta la tecnica dei tampered headers per ostacolare gli strumenti di analisi statica. Una volta installato, il file mostra una pagina-esca che riproduce fedelmente il branding di un aggiornamento ufficiale di Google Chrome, convincendo l’utente a proseguire con l’installazione. Solo a questo punto il dropper scarica ed esegue il payload reale, denominato internamente K3iwv7VF.apk, decifrato con AES-256-GCM tramite implementazione nativa (libreria compilata in C/C++, non in Java/Kotlin), un’ulteriore misura anti-analisi rispetto ai più comuni spyware Android scritti interamente in linguaggio gestito.

Il vero motore: l’abuso dell’AccessibilityService

DragonDoll non sfrutta exploit del kernel o vulnerabilità 0-day: si affida quasi interamente all’AccessibilityService di Android, l’API pensata per rendere il sistema operativo utilizzabile da persone con disabilità visive. Una volta ottenuto il permesso — spesso concesso dalla vittima stessa, ingannata dalla schermata di richiesta mascherata da parte del sistema — lo spyware può:

• Intercettare tap, gesture e input da tastiera in tempo reale su qualsiasi app in primo piano.
• Leggere il contenuto delle notifiche, incluse quelle di Telegram (liste chat, contatti, testo dei messaggi e timestamp) man mano che arrivano, senza dover violare la cifratura del protocollo.
• Monitorare visivamente lo schermo durante l’uso di WhatsApp e Signal, catturando ciò che compare a video anche quando l’app stessa è protetta da crittografia end-to-end.
• Iniettare overlay fasulli sopra app bancarie per sottrarre credenziali (banking overlay injection), una tecnica presa in prestito dai trojan bancari Android più maturi.
• Raccogliere contatti, SMS, log delle chiamate, screenshot, stato di batteria/Wi-Fi/USB/SIM, IMEI e la lista completa delle app installate.

Per app meno “prioritarie” come Viber, il malware si limita a una raccolta più semplice dei dati visibili a schermo, segno di uno sviluppo modulare e mirato piuttosto che di un tool generico riadattato.

Una campagna globale, con targeting linguistico chirurgico

PT ESC ha individuato la campagna per la prima volta nella primavera 2026, durante l’analisi di attacchi contro utenti in Arabia Saudita, per poi scoprire un’infrastruttura di distribuzione molto più ampia: oltre 26 Paesi colpiti, tra cui Russia, Cina, Corea del Sud e diversi Stati dell’area MENA, con il malware localizzato in 34 lingue di interfaccia. Tra il 6 marzo e il 6 maggio 2026 sono stati caricati circa 150 campioni unici su un account GitHub (kesmanta24, registrato con l’indirizzo kesmantes52@outlook.com), arrivati almeno alle versioni 9.3 e 9.4 — un ritmo di sviluppo che tradisce un progetto attivamente mantenuto e monetizzato, non un esperimento estemporaneo.

L’infrastruttura di comando e controllo si appoggia al dominio channelzones[.]co, ospitato su hosting russo, con canali di comunicazione bidirezionale basati su Socket.IO e autenticazione tramite OkHttp3; la cifratura del traffico combina AES-256-CBC e RSA OAEP in uno schema ibrido. La distribuzione iniziale avviene tramite domini civetta come datewithmealways[.]site, datewithmealways[.]online e digitaladstracking[.]com, pensati per superare filtri di reputazione e ingannare l’utente con nomi apparentemente innocui o a tema dating/advertising.

Perché conta: il mercato in espansione dello spyware commerciale Android

DragonDoll si inserisce in un trend che i ricercatori osservano da tempo: la proliferazione di famiglie spyware Android vendute o distribuite su scala industriale, capaci di aggirare la crittografia end-to-end di app come Signal e WhatsApp non attaccando il protocollo, ma il dispositivo stesso attraverso funzioni di sistema legittime come l’accessibilità. È lo stesso principio dietro altre famiglie recenti individuate mascherate da versioni “clonate” di Telegram e Signal distribuite anche tramite store ufficiali, un problema che ha spinto più volte Google a rafforzare i controlli su Play Protect senza però eliminare il rischio quando l’installazione avviene tramite sideloading da pagine web esterne, come nel caso di DragonDoll.

La presenza della Russia tra i Paesi bersaglio, insieme a un’infrastruttura C2 ospitata proprio su hosting russo, è un dettaglio che PT ESC segnala senza sciogliere del tutto l’ambiguità sull’attribuzione: non è chiaro se si tratti di un operatore locale che colpisce anche il proprio mercato interno, di un tool venduto a più clienti con targeting indipendente, o di un’operazione di sorveglianza mirata mascherata da campagna commerciale opportunistica.

Come proteggersi

• Non installare mai aggiornamenti di Chrome (o di qualsiasi altra app) da pagine web esterne al Google Play Store: gli aggiornamenti legittimi non vengono mai proposti così.
• Verificare periodicamente in Impostazioni → Accessibilità quali app hanno permessi attivi e revocarli per tutto ciò che non sia uno strumento di assistenza riconosciuto.
• Diffidare di APK scaricati da domini a tema dating, advertising o “aggiornamento urgente”, tipici vettori di distribuzione di questa famiglia.
• Su dispositivi aziendali o ad alto rischio, disabilitare il sideloading e imporre policy MDM che blocchino l’installazione da fonti sconosciute.
• Monitorare traffico di rete verso i domini e l’infrastruttura elencati di seguito come indicatori di compromissione.

Indicatori di compromissione

# Infrastruttura C2 e distribuzione
channelzones[.]co                 (C2 primario, hosting russo, canale Socket.IO)
datewithmealways[.]site           (dominio di distribuzione)
datewithmealways[.]online         (dominio di distribuzione)
digitaladstracking[.]com          (dominio di distribuzione)

# Account di sviluppo
GitHub user: kesmanta24
Email associata: kesmantes52@outlook.com
Periodo attivita': 6 marzo - 6 maggio 2026 (~150 campioni, versioni 9.3-9.4)

# Nomi file osservati
Chrome.apk        (dropper iniziale, tampered headers)
K3iwv7VF.apk       (payload finale, AES-256-GCM nativo)

# Paesi colpiti (parziale)
Arabia Saudita, Russia, Cina, Corea del Sud, area MENA (26+ Paesi totali)
Localizzazione: 34 lingue di interfaccia

# Cifratura
Dropper -> payload: AES-256-GCM (nativo)
C2: AES-256-CBC + RSA OAEP (ibrido), autenticazione OkHttp3, canale Socket.IO

Mentre la maggior parte dei top di gamma Android ha ormai abbandonato lo slot per microSD in favore del cloud e di tagli di memoria sempre più generosi, Sony continua a puntarci forte con il suo ultimo flagship, Xperia 1 VIII. E, a sorpresa, è proprio questa la funzione più apprezzata dai possessori del telefono, secondo un sondaggio condotto tra gli utenti giapponesi.

Cosa cercano davvero gli acquirenti di Xperia 1 VIII

Nel sondaggio, che ha raccolto 1.262 risposte valide, alla domanda su quali caratteristiche abbiano pesato di più nella scelta d’acquisto, il primo posto tra gli aspetti “di fedeltà al marchio” va ovviamente all’amore per Xperia e per Sony. Ma se si guarda alle funzioni tecniche, a vincere non sono le specifiche più recenti: il supporto alle microSD raccoglie il 56,10% delle preferenze, superando sia il traguardo dei quattro major update Android promessi (40,73%) sia il sensore fotografico principale, ingrandito di circa quattro volte rispetto al passato (38,51%).

Anche il jack audio da 3,5 mm resta un punto di forza

Subito dopo la microSD, un’altra caratteristica ormai rara sui flagship della concorrenza convince gli utenti Xperia: il jack audio cablato da 3,5 mm, scelto dal 37,16% degli intervistati, davanti persino alla qualità audio wireless e alle prestazioni degli altoparlanti. Ikeda Yuki, che si occupa dello sviluppo audio in Sony, ha spiegato che oggi lo smartphone è il dispositivo più usato per consumare contenuti multimediali, e che offrire sempre la possibilità di un ascolto cablato di qualità resta un punto d’orgoglio per l’azienda, anche se il mercato delle cuffie con filo si è ridotto negli anni.

La strategia di Sony: puntare su ciò che gli altri hanno tagliato

I risultati del sondaggio raccontano bene il tipo di pubblico che sceglie Xperia: utenti che non cercano solo l’ultima specifica tecnica, ma vogliono libertà di espandere la memoria senza dipendere dal cloud e la possibilità di collegare cuffie cablate senza adattatori. Sono proprio le funzioni considerate “legacy” dal resto del settore a rappresentare, per Sony, l’arma più efficace per fidelizzare la sua nicchia di utenti più esigenti.

Google starebbe lavorando a una funzione richiesta da tempo dagli utenti Pixel: la possibilità di spegnere il display con un semplice doppio tocco, senza dover premere il tasto di accensione. La novità è stata individuata all’interno del codice di Android 17 QPR2 Beta 3.

Come funzionerà il doppio tocco per bloccare lo schermo

Dalle stringhe scoperte nella beta emerge che sarà sufficiente toccare due volte un’area vuota della schermata Home o della schermata di blocco per spegnere il display. Diversi produttori Android offrono già gesture simili da tempo, ma sui Pixel questa funzione non è mai stata disponibile come opzione nativa, costringendo gli utenti a cercare il tasto fisico, specialmente quando il telefono è appoggiato su una scrivania o su un supporto.

Un’idea non nuova: le radici in Android 16

La funzione non nasce dal nulla: tracce simili erano già state individuate nella beta 1 di Android 16 QPR1, risalente al 2025. All’epoca, però, il doppio tocco funzionava solo sulla schermata di blocco. Nella versione attuale, invece, il comportamento sembra essere stato esteso anche alla schermata Home, ampliando il raggio d’azione della gesture.

Un interruttore dedicato nelle impostazioni

Secondo quanto trapelato, la funzione potrebbe essere gestita tramite un apposito interruttore nelle impostazioni, probabilmente collegato alle gesture legate a “Tap to check phone”. Non è ancora chiaro quali modelli riceveranno la novità, ma se dovesse arrivare con Android 17 QPR2 potrebbe estendersi anche ai Pixel meno recenti ancora supportati, come i Pixel 6a e successivi.

Va comunque ricordato che si tratta per ora di una funzione individuata in una versione beta, e non è detto che venga confermata nella release stabile. Resta comunque un segnale incoraggiante per chi da tempo chiede a Google di colmare questa lacuna rispetto ad altri produttori Android.

Il nuovo entry level di casa Samsung, Galaxy A08, sembra avvicinarsi sempre di più al lancio ufficiale. Dopo essere passato dalla certificazione FCC, il dispositivo con numero di modello SM-A085F è comparso anche su Google Play Console, che ha svelato alcune delle specifiche principali del device.

Ancora il Helio G99 sotto la scocca

Secondo quanto emerso, Galaxy A08 monterà il collaudato chip MediaTek Helio G99, un SoC octa-core a 6 nm pensato per la connettività 4G, con una media di circa 400.000 punti su AnTuTu v10. Al fianco del processore troveremmo 8 GB di RAM e un display con risoluzione 720 x 1600 pixel, valori identici a quelli del modello precedente, Galaxy A07 4G, a testimonianza di un aggiornamento più orientato all’autonomia che alle prestazioni pure.

Batteria in crescita: si passa a 5.830 mAh

La vera novità riguarda la batteria: secondo i dati emersi in fase di certificazione FCC, Galaxy A08 dovrebbe salire a 5.830 mAh, contro i 5.000 mAh del Galaxy A07 4G, con un incremento di oltre 800 mAh. Una scelta che privilegia chi utilizza lo smartphone soprattutto per streaming video, social e navigazione web piuttosto che per il gaming intensivo.

Design quasi invariato, ma con una nuova colorazione

Le immagini trapelate da Google Play Console mostrano un design molto simile a quello di Galaxy A07 4G, con il comparto fotografico posteriore racchiuso in un modulo verticale a forma di capsula. Il modello avvistato presenta però una colorazione bianca che non era disponibile sul predecessore, lasciando ipotizzare l’arrivo di nuove tonalità per la gamma A08.

Possibile anche una variante 5G

Samsung aveva affiancato al Galaxy A07 4G anche una versione 5G, e non è escluso che la stessa strategia venga replicata con Galaxy A08, anche se al momento non ci sono conferme ufficiali in tal senso. Con la certificazione FCC e la comparsa su Google Play Console, l’annuncio ufficiale del nuovo entry level Samsung sembra ormai questione di tempo: se il prezzo sarà competitivo, la batteria maggiorata potrebbe renderlo una scelta interessante per chi cerca uno smartphone economico e con ottima autonomia per l’uso quotidiano.

Xiaomi sembra pronta a lanciare due nuovi smartwatch entry level della linea Redmi: Redmi Watch 6 Lite e Redmi Watch 6 Active. I due modelli sono già comparsi su siti di comparazione prezzi e su Amazon, rivelando design, specifiche principali e possibili prezzi ancor prima dell’annuncio ufficiale.

Redmi Watch 6 Lite: GPS e sensore a 9 assi

Il modello più completo, Redmi Watch 6 Lite, monterà un display OLED da 1,96 pollici con risoluzione 502 x 410 pixel e uno spessore di soli 9,9 mm, con certificazione di resistenza all’acqua fino a 5 ATM. Non mancano un sensore per il battito cardiaco e uno per la saturazione dell’ossigeno nel sangue (SpO2), oltre a un altoparlante e un microfono integrati per le chiamate. La caratteristica più interessante resta però il GPS integrato, che permette di tracciare corse e uscite in bici senza dover portare con sé lo smartphone, affiancato da un sensore di movimento a 9 assi per una maggiore precisione. Assente, invece, l’NFC, quindi niente pagamenti contactless dal polso. Negli Stati Uniti il prezzo indicato su Amazon è di 75,99 dollari.

Redmi Watch 6 Active: la versione più economica

Il fratello minore, Redmi Watch 6 Active, adotta un display AMOLED leggermente più piccolo, da 1,85 pollici e risoluzione 450 x 390 pixel. Anche questo modello misura battito cardiaco e SpO2 e offre oltre 140 modalità sportive, ma rinuncia sia al GPS integrato (che richiederà quindi l’abbinamento con lo smartphone per tracciare i percorsi) sia al sensore a 9 assi presente sul Lite. In compenso il prezzo scende a 66,49 dollari, posizionandolo come opzione ancora più accessibile per chi si avvicina per la prima volta agli smartwatch.

Annuncio ufficiale ormai vicino

Le prime indiscrezioni sui due modelli erano già circolate a luglio, ma la comparsa su siti di comparazione prezzi internazionali suggerisce che la presentazione ufficiale sia ormai prossima. Xiaomi non ha ancora confermato una data, e i prezzi indicati fanno riferimento al mercato statunitense: per l’Italia bisognerà attendere il listino locale, che potrebbe differire da quello internazionale.

Le buone vendite di Galaxy Z Fold 8 starebbero convincendo Samsung a ripensare la propria strategia sui pieghevoli. Secondo indiscrezioni provenienti dalla Corea del Sud, l’azienda starebbe pianificando per il 2027 un nuovo modello a conchiglia orizzontale con un display ancora più panoramico rispetto a quello attuale, pensato soprattutto per la visione di contenuti multimediali.

Cinque pieghevoli Samsung nel 2027?

Secondo il sito coreano ETNews, per il 2027 Samsung avrebbe in programma ben cinque dispositivi pieghevoli: i successori di Galaxy Z Fold 8, Galaxy Z Flip 8 e Galaxy Z Fold 8 Ultra, un nuovo modello con design a tre ante, e per l’appunto un inedito pieghevole orizzontale con schermo più largo del solito.

Un formato pensato per lo streaming video

L’attuale Galaxy Z Fold 8 ha già ampliato la larghezza del display interno rispetto ai modelli precedenti, migliorando la fruizione di foto e video, ma secondo le fonti di ETNews ci sarebbe ancora margine di miglioramento su questo fronte. Il nuovo modello punterebbe infatti a un rapporto d’aspetto più vicino ai contenuti video tradizionali, con il formato 16:9 indicato come ipotesi più probabile al posto del rapporto quasi 4:3 dell’attuale Fold 8. Un pieghevole aperto in 4:3 mostra spesso fastidiose bande nere quando si guardano video pensati per il 16:9: risolvere questo compromesso significherebbe ripensare l’utilizzo stesso di un telefono pieghevole, non semplicemente ingrandirne lo schermo.

Anche una risposta al pieghevole di Apple?

Il tempismo non sembra casuale: proprio nel 2027 Apple dovrebbe presentare il suo primo iPhone pieghevole, secondo alcune indiscrezioni con un formato vicino al 4:3. Per Samsung, che finora ha guidato il mercato dei pieghevoli, mantenere questa leadership diventerebbe una sfida cruciale proprio nell’anno del debutto della concorrenza di Cupertino.

Al momento non si conoscono nome, dimensioni del display né la data di lancio del nuovo modello. Se le informazioni verranno confermate, il 2027 vedrebbe Samsung ampliare enormemente la propria gamma di pieghevoli, affiancando al classico Fold un modello pensato esplicitamente per l’intrattenimento.

Honor starebbe sviluppando un nuovo smartphone pieghevole a conchiglia orizzontale destinato a fare scalpore: secondo un leak recente, il dispositivo sarebbe già in fase di test con a bordo lo Snapdragon 8 Elite Gen 6 Pro, il prossimo chip di punta di Qualcomm, e monterebbe una batteria monstre da 7.000 mAh.

Il primo pieghevole Honor con il chip di punta di nuova generazione

Secondo il leaker Wisdom Pikachu, il nuovo pieghevole di Honor sarebbe l’unico dispositivo attualmente noto a testare lo Snapdragon 8 Elite Gen 6 Pro, prodotto con processo a 2 nm da TSMC e atteso per garantire un salto prestazionale e di efficienza energetica notevole. Se confermato, si tratterebbe del primo pieghevole orizzontale di Honor a montare il chip più avanzato disponibile sul mercato. Le indiscrezioni parlano di un display principale da circa 7,6 pollici e di uno schermo di copertina da circa 5,5 pollici, con un modulo fotocamere posteriore orizzontale.

Batteria da 7.000 mAh e fotocamera da 200 MP

Il dato che colpisce di più riguarda l’autonomia: una batteria da 7.000 mAh su un pieghevole rappresenterebbe un traguardo notevole, dato che lo spazio ridotto e la presenza della cerniera limitano solitamente la capienza degli accumulatori su questa categoria di dispositivi. Sul fronte fotografico, si parla di un comparto a tripla fotocamera guidato da un sensore principale da 200 MP, affiancato dalla elaborazione d’immagine proprietaria di Honor.

Batterie da oltre 10.000 mAh in arrivo anche su altre serie

Il pieghevole non sarebbe l’unico terreno su cui Honor punta sulla capacità della batteria: secondo il leaker Digital Chat Station, l’azienda starebbe testando anche celle singole da 11.600 mAh, per una capacità complessiva vicina ai 12.000 mAh, oltre a varianti da 9.800 e 9.850 mAh destinate alle serie Win 2, X e Power.

Anche una seconda generazione di Robot Phone in sviluppo

Sempre secondo Digital Chat Station, Honor starebbe lavorando pure alla seconda generazione del suo Robot Phone, il dispositivo del progetto Alpha dotato di fotocamera motorizzata e funzioni di intelligenza artificiale in grado di interpretare l’ambiente circostante. Le specifiche hardware della nuova versione sarebbero già in fase avanzata di definizione, anche se non è chiaro se il design cambierà rispetto al modello originale. Restano per ora tutte informazioni non confermate ufficialmente, ma il quadro complessivo suggerisce che Honor punti a distinguersi soprattutto su autonomia e prestazioni hardware nei prossimi lanci.

La nuova serie Xiaomi 18 potrebbe non debuttare in blocco come accaduto finora con le passate generazioni. Secondo il noto leaker Digital Chat Station, il modello Xiaomi 18 Pro arriverebbe già a settembre, mentre la versione standard, Xiaomi 18, sarebbe rimandata addirittura a dicembre.

Xiaomi 18 Pro atteso per fine settembre

Qualcomm terrà il suo Snapdragon Summit dal 22 al 24 settembre 2026, occasione in cui dovrebbe presentare ufficialmente il nuovo chip di punta Snapdragon 8 Elite Gen 6. Secondo le indiscrezioni, Xiaomi 18 Pro monterà proprio questo nuovo processore e verrebbe presentato attorno al 28-29 settembre, in perfetta continuità con l’annuncio Qualcomm.

Il modello standard slitta a dicembre

Xiaomi 18, la versione base della gamma, arriverebbe invece circa tre mesi più tardi, a dicembre. Una strategia che ricalca quella già vista di recente sulla serie Redmi, dove i modelli di fascia alta vengono lanciati per primi. Separare i lanci permette a Xiaomi di dare maggiore visibilità a ciascun modello, e non è escluso che diventi la norma anche per i futuri top di gamma dell’azienda.

Chip a 2 nm e nuova fotocamera per il modello standard

Entrambi i modelli della serie Xiaomi 18 dovrebbero montare lo Snapdragon 8 Elite Gen 6, prodotto da TSMC con processo a 2 nm, che promette miglioramenti sia in termini di prestazioni che di efficienza energetica. Tra le novità più interessanti per il modello standard c’è il possibile passaggio da una tripla fotocamera da 50 MP a una doppia fotocamera da 200 MP con ottiche a marchio Leica, puntando su un sensore principale più definito piuttosto che su un numero maggiore di obiettivi. Sono attese cinque colorazioni: nero, bianco, rosa, blu e rosso.

Il Pro conferma il display posteriore

Xiaomi 18 Pro continuerà a offrire il caratteristico display posteriore, che secondo le indiscrezioni guadagnerà nuove funzioni come la visualizzazione della bussola e l’accesso rapido a codici di pagamento e di ritiro per il delivery. Il prezzo di partenza dovrebbe attestarsi sui 5.499 yuan, circa 1.000 yuan in più rispetto alla generazione precedente, complice l’aumento dei costi produttivi legati al nuovo processo a 2 nm. Va ricordato che si tratta ancora di indiscrezioni non confermate da Xiaomi, e che la separazione dei lanci tra Pro e modello standard rappresenterebbe una novità significativa rispetto al passato.

Con la serie Pixel 11, Google ha cambiato più di quanto sembri sulla carta. Oltre al nuovo chip Tensor G6, infatti, cambia anche il modem di connettività: dopo generazioni affidate a Samsung, Google è passata a un modem prodotto da MediaTek, con l’obiettivo dichiarato di migliorare velocità, affidabilità ed efficienza energetica.

Un cambiamento atteso da tempo

Il modem ha sempre giocato un ruolo importante nell’esperienza d’uso dei Pixel. I primi Tensor, basati sull’architettura Exynos di Samsung, avevano generato non pochi malumori tra gli utenti per problemi di connettività, surriscaldamento e consumi eccessivi. Con le generazioni successive, in particolare da Tensor G3 in poi, la situazione era decisamente migliorata. Nel 2025, con il Tensor G5, Google aveva compiuto il primo passo importante progettando il chip internamente e affidandone la produzione a TSMC, ma il modem era rimasto di produzione Samsung. Con Pixel 11 e il Tensor G6, anche quest’ultimo tassello cambia: dati provenienti dalla certificazione FCC e dalle informazioni di banda base del dispositivo confermerebbero il passaggio a un modem MediaTek.

Google promette più velocità e minori consumi

Nella pagina prodotto ufficiale di Pixel 11 Pro, Google descrive il nuovo modem come più affidabile, più veloce e più efficiente dal punto di vista energetico. Non si tratterebbe quindi solo di un aumento delle velocità di trasmissione, ma anche di un tentativo di ridurre i consumi durante l’uso della rete mobile, un fattore che incide direttamente su autonomia e surriscaldamento nell’uso quotidiano con il 5G sempre attivo.

Il vero banco di prova sarà l’uso reale

Come sempre in questi casi, i numeri comunicati dall’azienda vanno presi con cautela: si tratta di test condotti su prototipi in condizioni controllate, che potrebbero non riflettere pienamente l’esperienza sul campo. Le prestazioni di rete dipendono infatti fortemente da operatore, area geografica e condizioni del segnale, mentre surriscaldamento e consumi variano in base all’utilizzo. Proprio perché il comparto modem è stato spesso oggetto di critiche sui Pixel del passato, la vera prova del nuovo modem MediaTek arriverà solo con l’uso quotidiano dopo il lancio sul mercato.

A livello di design, Pixel 11 non introduce grandi rivoluzioni, ma sotto la scocca i cambiamenti – dal Tensor G6 al nuovo modem – sono sostanziali. Se il passaggio a MediaTek si tradurrà davvero in un miglioramento della connettività e dei consumi, potrebbe rappresentare uno dei salti in avanti più significativi e al tempo stesso meno visibili di questa generazione.

Google ha rilasciato il 17 agosto la Beta 9 di Android 17 QPR1 per Pixel 6 e Pixel 6 Pro, un aggiornamento che porta con sé diverse correzioni di bug ma che segna soprattutto la fine di un percorso: secondo quanto confermato dall’azienda, si tratta infatti dell’ultima beta mai destinata a questi due modelli.

Cinque anni di aggiornamenti per Pixel 6

Lanciata nel 2021, la serie Pixel 6 ha ormai raggiunto i cinque anni di vita. Google ha introdotto il supporto esteso a sette anni di aggiornamenti – comprensivo di major update, Feature Drop e patch di sicurezza – solo a partire da Pixel 8, lasciando la generazione Pixel 6 fuori da questa nuova politica di supporto più longevo.

Risolto il problema del cambio app dopo Circle to Search

Tra le correzioni introdotte con la Beta 9 spicca la risoluzione di un bug che impediva di cambiare applicazione scorrendo la barra dei gesti dopo aver usato Circle to Search. Sistemato anche un fastidioso bootloop che causava riavvii ripetuti ogni 20-30 secondi su alcuni dispositivi, oltre a un problema che generava improvvisi picchi di volume durante la riproduzione multimediale o la gestione delle notifiche, e a un bug che faceva sparire le icone dalla taskbar all’apertura di alcune app.

La versione stabile di settembre come ultimo traguardo

Per chi sta ancora partecipando al programma beta su Pixel 6 e Pixel 6 Pro, questa Beta 9 rappresenta quindi il capolinea dei test: dopo il rilascio della versione stabile di Android 17 QPR1, prevista per settembre, i due modelli usciranno definitivamente dal programma beta. Da lì in avanti, il supporto software sarà soggetto ai vincoli della politica di aggiornamento più corta riservata alle generazioni precedenti a Pixel 8.

Chi possiede ancora un Pixel 6 o un Pixel 6 Pro farebbe bene ad installare questo ultimo aggiornamento beta e a considerare la versione stabile di settembre come un vero e proprio traguardo finale nel ciclo di vita software del proprio dispositivo.

Non è la sottigliezza ciò che gli utenti Pixel chiedono a Google, ma un uso più intelligente dello spazio interno dello smartphone. È quanto emerge da un sondaggio condotto da Android Authority, secondo cui le due lamentele più diffuse riguardano il surriscaldamento eccessivo rispetto alle dimensioni del telefono e una capacità della batteria che, di generazione in generazione, resta pressoché invariata.

Il 42,3% lamenta il surriscaldamento, il 39% la batteria

Il sondaggio chiedeva ai partecipanti di indicare, tra quattro possibili difetti hardware della gamma Pixel, quello che vorrebbero veder migliorato per primo. La risposta più votata, con il 42,3% delle preferenze, riguarda il surriscaldamento del dispositivo nonostante le dimensioni non proprio compatte. Al secondo posto, con il 39%, si posiziona la scarsa crescita della capacità della batteria tra una generazione e l’altra.

Sommando le due percentuali si arriva all’81,4% del totale, segno che la maggioranza degli utenti non chiede tanto un design più sottile o leggero, quanto un miglior utilizzo dello spazio già disponibile all’interno della scocca.

Meglio un millimetro in più che un compromesso sulla batteria

Tra i commenti raccolti, diversi utenti si dicono disposti ad accettare uno spessore maggiore di uno o due millimetri pur di ottenere una batteria da 6.500 mAh, una vapor chamber più efficiente per dissipare il calore e un sensore fotografico più grande. Altri suggeriscono semplicemente di sfruttare lo spazio già occupato dal blocco fotocamere sporgente per alloggiare una batteria più capiente, invece di lasciarlo inutilizzato.

Le funzioni esclusive Pro non sono la priorità

Solo il 4,7% degli intervistati ha indicato come problema prioritario la disponibilità limitata di alcune funzioni – come HiLight – ai soli modelli Pro. Un dato che, insieme al 14% di chi lamenta più in generale che peso e spessore non siano giustificati da reali vantaggi, conferma come il tema centrale per gli utenti Pixel resti quello dell’efficienza pratica quotidiana.

Google potrebbe continuare a puntare su design più sottili nelle prossime generazioni, ma il sondaggio suggerisce chiaramente che non è questa la direzione più desiderata dal pubblico: la maggioranza preferirebbe un Pixel leggermente più corposo, ma con più batteria, meno surriscaldamento e fotocamere migliori.

Google ha avviato la distribuzione della Beta 9 di Android 17 QPR1 per i dispositivi Pixel. A differenza delle beta precedenti, questo aggiornamento non porta con sé nuove funzioni, ma si concentra sulla correzione dei bug in vista della release stabile prevista per settembre, segno che lo sviluppo è ormai entrato nella sua fase finale.

Coinvolti tutti i Pixel da 6 in poi

La Beta 9 è disponibile per tutti i modelli a partire da Pixel 6. Il rilascio arriva a circa due settimane dalla Beta 8, pubblicata a fine luglio, un ritmo che conferma quanto lo sviluppo di QPR1 sia ormai vicino al traguardo.

Risolto il bug della gesture dopo Circle to Search

Tra le correzioni più rilevanti c’è quella relativa a un problema che impediva di cambiare applicazione scorrendo la barra dei gesti dopo aver utilizzato Circle to Search: Google è intervenuta sulla gestione di sistema delle gesture, assicurandosi che il focus di navigazione venga ripristinato correttamente.

Risolto anche un fastidioso bug che causava un aumento improvviso e non voluto del volume durante la riproduzione multimediale o la gestione delle notifiche – un problema piccolo ma capace di creare non pochi disagi nell’uso quotidiano.

Corretti anche bootloop e problemi sui pieghevoli

Tra gli altri interventi figurano la correzione di un bootloop che su alcuni dispositivi provocava riavvii ripetuti ogni 20-30 secondi, un bug che faceva sparire le icone dalla taskbar sugli smartphone pieghevoli all’apertura di alcune app, e alcuni casi di consumo anomalo della batteria.

Verso il Feature Drop di settembre

Android 17 QPR1 arriverà in versione stabile a settembre come Feature Drop per i Pixel. Google ha definito la Beta 9 come “versione beta finale” per Pixel 6 e Pixel 6 Pro, il che lascia intendere che per questi due modelli potrebbe non arrivare un’ulteriore beta prima del passaggio alla versione stabile. Resta comunque possibile che, in caso di bug particolarmente gravi individuati in extremis, venga rilasciata una beta aggiuntiva anche per gli altri modelli: vista la cadenza ravvicinata tra la Beta 8 e la Beta 9, non è da escludere che gli aggiustamenti proseguano fino all’ultimo.

Su Xperia 1 VIII il sensore di impronte digitali è integrato nel tasto di accensione laterale, proprio come sui modelli più recenti della gamma Sony. Dal 2024, con Xperia 1 VI, l’azienda aveva però eliminato la necessità di premere fisicamente il tasto: è sufficiente sfiorare il sensore anche a schermo spento per sbloccare il telefono. Una comodità che porta con sé un effetto collaterale, e sul forum Esato è ora spuntato un metodo per riportare il comportamento a quello di un tempo.

Il problema dello sblocco accidentale in tasca

Con il sensore sempre attivo, capita che il telefono si sblocchi (o tenti di farlo) semplicemente perché un dito lo sfiora mentre è riposto in tasca. In caso di ripetuti tentativi falliti, il sistema può richiedere l’inserimento del PIN per sbloccare il dispositivo, costringendo l’utente a un passaggio in più proprio quando vorrebbe accedere rapidamente al telefono.

La soluzione passa da un comando ADB

La procedura condivisa su Esato prevede di installare su un PC Windows Android SDK Platform-Tools e i relativi driver USB, attivare le Opzioni sviluppatore e il debug USB sullo smartphone, quindi collegare il telefono al computer e autorizzare la connessione. A quel punto, da terminale, va eseguito il seguente comando:

adb shell settings put secure somc.disable_fps_screen_off 1

Una volta applicata, la modifica disattiva la scansione dell’impronta a schermo spento: il sensore tornerà attivo solo dopo aver premuto il tasto di accensione, esattamente come accadeva sui modelli precedenti a Xperia 1 VI.

Come tornare al comportamento originale

Per ripristinare la scansione costante è sufficiente rilanciare lo stesso comando sostituendo l’ultimo valore da “1” a “0”:

adb shell settings put secure somc.disable_fps_screen_off 0

Una volta completata l’operazione, è consigliabile disattivare nuovamente il debug USB dalle Opzioni sviluppatore per motivi di sicurezza.

Un trucco non ufficiale, da usare con cautela

Va precisato che si tratta di una modifica non supportata ufficialmente da Sony, applicabile a proprio rischio, e che un futuro aggiornamento software potrebbe disattivarla o modificarne il funzionamento. Il metodo, sperimentato su Xperia 1 VIII, dovrebbe in teoria funzionare anche su altri modelli Xperia con la stessa impostazione. Nel frattempo, resta una soluzione interessante per chi trova fastidiosi gli sblocchi accidentali e spera che Sony introduca in futuro un’opzione ufficiale per scegliere tra le due modalità di funzionamento del sensore.

Poco si prepara a lanciare in India il nuovo Poco M8x 5G, e dalle prime indiscrezioni emergono già diverse informazioni su specifiche e prezzo del dispositivo, ancora prima dell’annuncio ufficiale.

Snapdragon 4 Gen 5 secondo il teaser, ma spunta anche Dimensity 6300

Il teaser ufficiale pubblicato su Flipkart, che si occuperà della vendita del dispositivo in India, indica il chip Qualcomm Snapdragon 4 Gen 5, orientato a un utilizzo quotidiano fatto di social e streaming video piuttosto che gaming intensivo. Il leaker Yogesh Brar, però, sostiene che a bordo ci sia in realtà il MediaTek Dimensity 6300, creando un’incertezza che solo l’annuncio ufficiale potrà risolvere.

Display da 6,9 pollici a 120 Hz

Sul fronte display, le indiscrezioni parlano di un pannello LCD da 6,9 pollici con risoluzione HD+ ma refresh rate a 120 Hz, che dovrebbe garantire una buona fluidità nello scorrimento nonostante la risoluzione contenuta. La configurazione di memoria prevista è 4 GB di RAM e 128 GB di storage, con possibilità di espansione tramite microSD. A livello software, il dispositivo dovrebbe debuttare direttamente con HyperOS 3.

Batteria da 6.000 mAh e ricarica a 33 W

Il vero punto di forza del nuovo Poco sembra essere l’autonomia: la batteria avrebbe una capacità di 6.000 mAh, un valore piuttosto generoso per questa fascia di prezzo, abbinata a una ricarica rapida da 33 W. Nessuna informazione, invece, sul comparto fotografico, che resta ancora un punto interrogativo.

Prezzo sotto le 20.000 rupie

Secondo le previsioni, Poco M8x 5G dovrebbe posizionarsi sotto le 20.000 rupie indiane, un prezzo che, unito al display ampio e alla batteria generosa, potrebbe renderlo una scelta interessante per chi cerca un dispositivo economico orientato all’intrattenimento e all’autonomia. Resta però da chiarire la questione del chip, vista la discrepanza tra teaser ufficiale e indiscrezioni: con l’annuncio ormai vicino, non dovrebbe volerci molto per avere conferme definitive su tutte le specifiche.

Per anni, i possessori di Galaxy che non usavano la tastiera SwiftKey di Microsoft, preinstallata di serie su molti modelli Samsung, hanno dovuto convivere con un’app che non era possibile rimuovere del tutto dal dispositivo. Con l’arrivo di One UI 9, questa limitazione sembra finalmente superata.

SwiftKey diventa disinstallabile come una qualsiasi app

Fino ad oggi SwiftKey, integrata come app di sistema in virtù dell’accordo tra Samsung e Microsoft, poteva essere solo disattivata o privata dei relativi aggiornamenti, ma mai rimossa completamente. Su Galaxy S26 Ultra con One UI 9 Beta 5, invece, è stato confermato che l’app può ora essere disinstallata normalmente, liberando circa 55 MB di spazio – una quantità certo modesta con gli storage attuali, ma comunque un passo apprezzato da chi preferisce tenere il proprio telefono libero da app inutilizzate, magari perché già affezionato alla tastiera Samsung.

Un segnale di un rapporto Samsung-Microsoft in evoluzione

Il cambiamento potrebbe riflettere un’evoluzione nei rapporti commerciali tra le due aziende. L’accordo tra Samsung e Microsoft prevedeva finora la preinstallazione di app come Office, OneDrive, OneNote e, appunto, SwiftKey, oltre a funzioni di integrazione con OneDrive all’interno di app Samsung come Galleria e I miei file. Diversi segnali recenti suggeriscono che questa partnership stia cambiando forma, e la possibilità di rimuovere SwiftKey sembra rientrare in questo quadro.

Sempre più Galaxy senza SwiftKey preinstallata

Oltre alla possibilità di disinstallarla, cresce anche il numero di modelli su cui SwiftKey non è nemmeno preinstallata: è il caso di Galaxy Z Fold 8 e Galaxy Z Fold 8 Ultra, e la stessa sorte potrebbe toccare al prossimo Galaxy Z Flip 8 con One UI 9. Anche alcuni modelli della serie Galaxy A risultano già privi dell’app di serie.

Più libertà di scelta per gli utenti

SwiftKey resta apprezzata da molti per le sue capacità predittive, ma non tutti gli utenti la utilizzano, specialmente chi preferisce la tastiera nativa di Samsung. Con One UI 9, i possessori di Galaxy avranno maggiore libertà di mantenere sul proprio dispositivo solo le app che utilizzano davvero. Per ora la novità è stata osservata sulla beta, ma è probabile che venga confermata anche nella versione stabile, in quello che appare come un ulteriore segnale dei cambiamenti in corso nel rapporto tra Samsung e Microsoft.

GIMP prepara un nuovo formato di progetto basato su XML compresso per superare i limiti dello storico XCF e supportare funzioni future

🔗 Leggi il post completo

Anvil è una GUI web minimale per pacman su Arch Linux, con backend FastAPI, supporto AUR, transazioni interattive e aggiornamenti in tempo reale

🔗 Leggi il post completo

Ad aprile 2026, Jon Seager, vicepresidente dell’area Engineering di Canonical, ha parlato con The Pragmatic Engineer (lettura articolo completo a pagamento), dicendo loro che Ubuntu all’interno di Windows Subsystem for Linux (WSL) sta crescendo...

🔗 Leggi il post completo

Il #compleanno di #Debian è occasione molto sensata, oltre che per celebrare, anche per estrarre dal cilindro 33 curiosità, alcune delle quali qualcuno potrebbe non aver mai sentito, che aiutano a comprendere ancora meglio la natura del progetto e la sua storia fino ad oggi.
Una storia destinata a continuare nel tempo.

🔗 Leggi il post completo

Il kernel GNU Linux-libre è una versione del kernel Linux modificata appositamente per garantire la massima libertà del software a chi desidera utilizzare un sistema operativo completamente privo di componenti proprietari. L’obiettivo centrale è...

🔗 Leggi il post completo

Srain è un client IRC open source moderno e multipiattaforma, con GTK, supporto IRCv3, ricerca canali, notifiche e configurazione avanzata

🔗 Leggi il post completo