Il Samsung Galaxy Z Fold 8 sta registrando vendite superiori alle previsioni iniziali dell’azienda, al punto da costringere Samsung ad accelerare la produzione e, secondo alcune fonti coreane, a dirottare verso il pieghevole componenti originariamente destinati ad altri prodotti.

Il collo di bottiglia: i chip DDI per il display

Al centro del problema ci sarebbero i Display Driver IC (DDI), i chip fondamentali per il controllo dei pixel dei pannelli OLED. Progettati dalla divisione System LSI di Samsung e prodotti dalla fonderia taiwanese UMC su processo a 22 nanometri, questi componenti non sarebbero facilmente scalabili in tempi brevi, poiché la capacità produttiva di UMC su quel nodo risulterebbe già quasi satura.

Samsung chiede la priorità produttiva a UMC

Per far fronte alla domanda, Samsung avrebbe richiesto a UMC l’accesso al programma “Super Hot Run”, una linea di produzione a priorità massima riservata ai clienti più importanti, proprio per accelerare la fornitura dei DDI destinati al Galaxy Z Fold 8.

Scorte di altri prodotti dirottate sul Fold 8

Nel frattempo, per tamponare la carenza a breve termine, Samsung starebbe attingendo alle scorte di DDI originariamente destinate ad altri dispositivi, incluse linee di prodotto ancora in sviluppo. Una misura che appare temporanea, ma che potrebbe complicare la gestione delle scorte in vista del lancio della serie Galaxy S27, attesa tra circa sei mesi.

Perché il Fold 8 sta andando così bene

Il successo del Galaxy Z Fold 8 sembra legato soprattutto alla riduzione delle dimensioni rispetto ai modelli precedenti, un fattore che ha reso il dispositivo più maneggevole senza rinunciare ai vantaggi del formato pieghevole. Non è escluso che anche l’attesa per il primo iPhone pieghevole di Apple, atteso il 9 settembre, stia contribuendo ad accendere l’interesse generale verso questa categoria di prodotti, portando benefici indiretti anche alle vendite Samsung.

Il Google Pixel 11 Pro XL introduce una ricarica cablata fino a 45W e una nuova modalità chiamata “Extreme Charging”, pensata per velocizzare ulteriormente i tempi di ricarica. I primi test indipendenti mostrano però risultati altalenanti: le condizioni per ottenere la massima potenza sono piuttosto rigide e, in alcuni casi, la funzione Extreme Charging non risulta nemmeno disponibile.

Serve un alimentatore molto specifico

Nei test, il Pixel 11 Pro XL ha raggiunto un picco di 40,7W utilizzando un caricabatterie ufficiale Google, restando quindi sotto il valore dichiarato di 45W ma comunque superiore ai circa 35W ottenuti dai precedenti modelli Pro XL. Per avvicinarsi a questa potenza è però necessario un alimentatore compatibile con lo standard USB Power Delivery PPS a 21V/2A: molti caricabatterie PPS in commercio si fermano infatti a 11V, limitando sensibilmente la potenza reale erogata. In un test con un alimentatore PPS da 67W, ad esempio, la potenza effettiva si è fermata attorno ai 25W.

Tempi di ricarica non rivoluzionari

Nonostante il picco di potenza più alto, i tempi di ricarica complessivi non sono migliorati in modo drastico: 21 minuti per raggiungere il 50%, 35 minuti per il 75% e 69 minuti per la carica completa. Il tempo per la ricarica totale risulta inferiore rispetto al Pixel 10 Pro XL, ma i primi minuti restano in linea con le generazioni precedenti, nonostante una batteria leggermente più piccola, da 5.115 mAh. Alcuni test segnalano anche un aumento della temperatura durante la ricarica.

Extreme Charging, funzione introvabile per alcuni utenti

La funzione Extreme Charging, che secondo Google dovrebbe permettere di raggiungere il 75% di carica in soli 30 minuti accettando temperature più elevate, non sarebbe però sempre disponibile. Pur rispettando i requisiti dichiarati da Google — batteria sotto il 50% e alimentatore capace di erogare almeno 30W — alcuni test non sono riusciti ad attivarla: l’opzione dedicata risultava del tutto assente dalle impostazioni o disattivata nel pannello rapido.

Un problema che potrebbe risolversi da solo

In alcuni casi segnalati dagli utenti, la funzione Extreme Charging sarebbe comparsa spontaneamente dopo alcuni giorni di utilizzo del dispositivo, un comportamento che fa pensare a un sistema di apprendimento in background legato allo stato della batteria. Google non ha ancora fornito spiegazioni ufficiali in merito. In attesa di eventuali aggiornamenti software, chi acquista il Pixel 11 Pro XL dovrebbe quindi non aspettarsi, almeno per ora, un salto prestazionale così netto come i 45W e l’Extreme Charging lascerebbero intendere.

Oppo si prepara a rivoluzionare il comparto fotografico della prossima serie Find X10, in arrivo a settembre. Da un lato l’azienda ha ufficialmente presentato ProXDR, una nuova tecnologia di elaborazione capace di raggiungere una gamma dinamica fino a 17 EV; dall’altro, alcune indiscrezioni sul modello Find X10 Pro Max parlano di una configurazione a tre sensori da 200 megapixel ciascuno, una soluzione più unica che rara nel panorama smartphone.

ProXDR: gamma dinamica fino a 17 EV su foto e video

ProXDR si basa sulla nuova tecnologia di sensore HDR “DeepPix” e interviene sull’intero processo di scatto, dalla cattura della luce fino alla visualizzazione sullo schermo. Secondo Oppo, la tecnologia consente di ottenere fino a 17 EV di gamma dinamica in un singolo scatto, riducendo drasticamente le zone bruciate nelle alte luci e i dettagli persi nelle ombre, tipici delle scene in controluce o con forti contrasti. La funzione si estende anche al video, con registrazione 4K HDR a piena risoluzione e un occhio di riguardo ai consumi energetici durante le riprese prolungate. Un aspetto interessante è che l’elaborazione HDR avanzata si attiva automaticamente in base alla scena inquadrata, senza che l’utente debba selezionare manualmente una modalità dedicata.

Find X10 Pro Max: tre fotocamere, tutte da 200 megapixel

Secondo il leaker Digital Chat Station, il Find X10 Pro Max potrebbe adottare sensori da 200 megapixel non solo sulla fotocamera principale, ma anche su ultra grandangolare e teleobiettivo, una configurazione finora quasi inedita nel settore. Per il sensore principale si parla del Samsung ISOCELL HPC da 1/1,3 pollici, capace secondo le prime informazioni di raggiungere proprio quei 17 EV di gamma dinamica citati per ProXDR, con supporto allo zoom in-sensor, scatti HDR a 16 bit e video fino a 4K a 180 fotogrammi al secondo.

Anche ultra grandangolare e teleobiettivo più grandi

Il sensore ultra grandangolare, secondo le voci di corridoio, monterebbe un’unità da 1/1,56 pollici, nettamente più grande rispetto a quella vista sul Find X9 Pro, con benefici attesi soprattutto in condizioni di scarsa illuminazione. Per il teleobiettivo si parla invece del sensore OmniVision OV52A da 1/1,28 pollici, già impiegato sulla fotocamera 3x del Find X9 Ultra. Uniformare le dimensioni dei sensori su tutte e tre le fotocamere potrebbe ridurre le differenze qualitative che spesso si notano passando da un obiettivo all’altro, sia in foto che in video.

Una nuova app fotocamera e attesa per settembre

Oppo ha inoltre confermato di essere al lavoro su un rinnovamento dell’app fotocamera, che dovrebbe accompagnare l’introduzione di ProXDR con un’interfaccia e un’esperienza d’uso ripensate. Sia ProXDR sia la presunta configurazione a tre sensori da 200 megapixel dovrebbero debuttare a settembre con l’annuncio ufficiale della serie Find X10, anche se, trattandosi ancora di indiscrezioni non confermate da Oppo, i dettagli definitivi potrebbero cambiare rispetto a quanto trapelato finora.

La tedesca Sovereign Tech Agency (STF) ha stanziato oltre 508.000 € per lo sviluppo di Flatpak nei prossimi due anni. L'iniziativa, coordinata da Modal e Para-Real, punta a colmare i gap di sicurezza e isolamento (sandboxing) introducendo nuovi Portals dedicati ad audio, rete, VPN e riempimento automatico delle password.
L'articolo 508.000€ per Flatpak: la Sovereign Tech Agency investe sul des...

🔗 Leggi il post completo

LinDiskInfo è un nuovo monitor S.M.A.R.T. e NVMe per Linux con interfaccia Qt, grafici, temperature e strumenti per controllare la salute dei dischi.L'articolo "LinDiskInfo porta CrystalDiskInfo su Linux con monitor S.M.A.R.T. e NVMe" proviene da Linux Easy.
Questo contenuto è distribuito con licenza CC BY-NC 4.0 non riprodurre questo articolo o immagini senza permesso.

🔗 Leggi il post completo

Ubuntu 26.04.1 LTS è disponibile al download con immagini ISO aggiornate, correzioni di bug, patch di sicurezza e pacchetti aggiornatiL'articolo "Ubuntu 26.04.1 LTS è disponibile: arriva il primo aggiornamento di “Resolute Raccoon”" proviene da Linux Easy.
Questo contenuto è distribuito con licenza CC BY-NC 4.0 non riprodurre questo articolo o immagini senza permesso.

🔗 Leggi il post completo

LibreOffice 26.8 introduce un nuovo sistema per la gestione dei paragrafi, Draft View, miglioramenti a Calc e nuove funzioni per Writer, Impress e DrawL'articolo "LibreOffice 26.8 è disponibile: tante novità per Writer, Calc, Impress e Draw" proviene da Linux Easy.
Questo contenuto è distribuito con licenza CC BY-NC 4.0 non riprodurre questo articolo o immagini senza permesso.

🔗 Leggi il post completo

La Germania ha deciso di sostenere concretamente lo sviluppo di Flatpak con un investimento di 508.640 euro destinato a finanziare due anni di attività. Il finanziamento arriva dalla Sovereign Tech Agency, attraverso il programma Sovereign Tech Fund, e punta a rafforzare uno dei principali sistemi utilizzati oggi per distribuire applicazioni Linux in modo indipendente dalla […]L'articolo "L...

🔗 Leggi il post completo

Calibre ha rilasciato la versione 9.14 della propria applicazione di gestione di e-book per i sistemi Windows, macOS e GNU/Linux come aggiornamento del ramo stabile dedicato all’introduzione delle copertine generate con l’intelligenza artificiale e...

🔗 Leggi il post completo

NVIDIA ha rilasciato la versione 595.99.02 del proprio driver grafico per i sistemi GNU/Linux come aggiornamento di manutenzione del ramo Production Branch (ramo di produzione stabile) dedicato quasi interamente alla correzione di bug. Il...

🔗 Leggi il post completo

Il rilascio del 26 agosto

Kubernetes v1.37, nome in codice Garhwal, è stato rilasciato il 26 agosto 2026 dopo il consueto ciclo con enhancement freeze a metà giugno e code freeze a fine luglio. Il changelog conta 86 enhancement complessivi, di cui 16 passano a Stable e altri 28 sono classificati come “Graduating” tra Alpha e Beta. Per chi gestisce cluster in produzione, due filoni meritano un approfondimento perché toccano direttamente i costi operativi e la resilienza del control plane: lo scale-to-zero nativo dell’HPA e una serie di ottimizzazioni interne pensate per proteggere l’API server sotto carico estremo.

Scale-to-zero: l’HPA impara a spegnere tutto

Da anni chi vuole azzerare le repliche di un workload realmente idle (un job batch, un ambiente di staging fuori orario, un microservizio a bassissimo traffico) deve appoggiarsi a soluzioni esterne come KEDA, che introducono un ulteriore componente da gestire e monitorare. Con la KEP-2021 (“Support scaling to/from zero pods for object/external metrics”), che in questa release passa da Alpha a Beta, l’Horizontal Pod Autoscaler nativo guadagna questa capacità senza dipendenze esterne.

La differenza pratica rispetto al comportamento precedente è che ora si può impostare minReplicas: 0 quando l’HPA è configurato su metriche di tipo Object o External (non su CPU/memoria, per ovvie ragioni: non esiste un consumatore da cui misurare l’utilizzo se non ci sono pod):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-scale-to-zero
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metric:
        name: queue_messages_ready
        selector:
          matchLabels:
            queue: orders
      target:
        type: AverageValue
        averageValue: "30"

Tolleranza configurabile: basta con il 10% fisso per tutti

Una seconda modifica, meno appariscente ma altrettanto utile in produzione, riguarda la KEP-4951 (“Configurable tolerance for Horizontal Pod Autoscalers”), che con questa release passa a Stable. Fino a v1.36, l’HPA applicava una tolleranza fissa a livello di cluster (il classico 10%) prima di decidere che uno scarto tra metrica osservata e target giustificasse un’azione di scaling. Questo valore, impostato una volta a livello di kube-controller-manager, andava bene come default generico ma era un compromesso scomodo per workload con esigenze molto diverse tra loro: un servizio latency-sensitive vorrebbe reagire a scostamenti minimi, mentre un batch job tollera oscillazioni ben più ampie senza bisogno di “flappare” in continuazione.

Ora il campo di tolleranza è configurabile per singolo HPA, direttamente in spec.behavior:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: latency-sensitive-api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-gateway
  minReplicas: 3
  maxReplicas: 20
  behavior:
    scaleUp:
      tolerance: "0.05"
    scaleDown:
      tolerance: "0.20"
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

Proteggere l’API server: il vero collo di bottiglia dei cluster grandi

Il secondo filone di novità riguarda chi gestisce cluster di grandi dimensioni, dove l’API server è spesso il componente che soffre per primo sotto carico. La KEP-6178 (“Concurrent Watch Object Decode”) affronta un problema molto concreto: durante le migrazioni di versione delle Custom Resource Definition, ogni evento di watch attivo deve essere convertito nella nuova versione dello schema, e questa conversione avveniva storicamente in modo sequenziale. Su cluster con oltre 10.000 workload e numerosi watcher attivi, questo causava timeout verso etcd e, nei casi peggiori, errori HTTP 500 lato API server proprio nei momenti di maggior carico.

In questa release, il feature gate ConcurrentWatchObjectDecode passa a Beta ed è abilitato di default, permettendo la decodifica e conversione parallela degli eventi di watch. Per abilitarlo o disabilitarlo esplicitamente sull’API server:

kube-apiserver \
  --feature-gates=ConcurrentWatchObjectDecode=true \
  # ...altri flag esistenti

Altre novità che meritano attenzione

Il changelog di v1.37 include diverse altre graduazioni utili nella pratica quotidiana:

• Pod-level resources (KEP-2837): permette di definire un pool condiviso di CPU, memoria e hugepages a livello di pod invece che per singolo container, migliorando l’utilizzo delle risorse per pod con più container che hanno pattern di consumo complementari;
• Storage Version Migrator in-tree (KEP-4192): porta nativamente nel cluster, tramite l’API storagemigration.k8s.io, la funzionalità di riscrittura automatica dei dati quando cambia la storage version di una risorsa, un’operazione che prima richiedeva strumenti esterni;
• CBOR come formato di serializzazione (KEP-4222, Beta): fino a 8 volte più veloce in encoding e 2 volte in decoding rispetto a JSON per le Custom Resource Definition, un dettaglio che pesa parecchio su cluster con molti CRD ad alta frequenza di aggiornamento;
• Nomi Service più permissivi (KEP-5311): i nomi ora possono iniziare con un numero (es. 123-backend), passando dal vincolo RFC 1035 al più permissivo formato DNS Label;
• Pod Certificates (KEP-4317): distribuzione di certificati X.509 ai pod senza passare da bearer token, tramite il nuovo oggetto PodCertificateRequest, utile per chi sta migrando verso autenticazione mutual TLS tra servizi;
• ClusterTrustBundles (KEP-3257, Beta): permette di montare bundle di trust CA come volume proiettato nei pod, semplificando la distribuzione di certificate authority personalizzate senza dover gestire ConfigMap manualmente.

Cosa verificare prima di aggiornare

Come per ogni major/minor release di Kubernetes, prima di pianificare l’upgrade su cluster di produzione vale la pena controllare tre cose in particolare: primo, se si usano CRD con più versioni attive contemporaneamente, testare il comportamento con ConcurrentWatchObjectDecode abilitato in un ambiente di staging che replichi il volume di watcher reale; secondo, se si dipende oggi da KEDA solo per lo scale-to-zero su metriche esterne (code, topic Kafka, metriche custom da Prometheus Adapter), valutare se la KEP-2021 in Beta copre già il caso d’uso, tenendo presente che è comunque prudente aspettare la Stable prima di rimuovere KEDA da workload critici; terzo, verificare la compatibilità di eventuali webhook di ammissione e operator custom con i pod-level resources, se già si sfruttano richieste/limiti a livello di container in modo granulare.

Nel complesso, v1.37 conferma una tendenza chiara delle ultime release: meno feature “vistose” rivolte all’utente finale, più lavoro di fondo su efficienza e resilienza del control plane, proprio nei punti dove i cluster più grandi iniziano a sentire la pressione della scala.

Fonte: 4sysops, con dettagli tecnici da PerfectScale e dalle note di rilascio ufficiali del progetto Kubernetes.

Due vulnerabilità critiche, due superfici di attacco diverse

Il 25 agosto 2026 il team di Next.js ha rilasciato un aggiornamento di sicurezza fuori dal normale ciclo di rilascio, anticipando la pubblicazione dopo aver identificato una seconda vulnerabilità critica in una dipendenza upstream mentre stava già preparando la patch per la prima. Il risultato sono due falle di Remote Code Execution non autenticata con severità critica, entrambe corrette nelle versioni 15.5.24 (Maintenance LTS) e 16.3.3 (Active LTS). Per chi gestisce applicazioni Next.js in produzione, specialmente self-hosted, questo è un aggiornamento da applicare senza rimandare.

CVE-1: RCE tramite l’Image Optimization API su file AVIF

La prima vulnerabilità (GHSA-2xp9-vwfh-vxw4, CVSS stimato 9.5) risiede in libheif, la libreria usata da sharp per la decodifica delle immagini AVIF, a sua volta impiegata dall’Image Optimization API integrata in Next.js. La falla upstream (GHSA-g89c-p67h-r497) è un heap buffer overflow nel codice di scaling delle immagini: un file AVIF costruito ad arte, con riferimenti annidati di tipo identity-derivation e auxiliary item, induce il decoder a costruire un’immagine con una profondità di bit del canale Alpha incoerente rispetto al buffer allocato. Lo scaler alloca spazio per dati a 8 bit ma vi scrive valori a 16 bit, scrivendo circa 16.384 byte oltre il limite dell’allocazione: la combinazione classica che apre la strada all’esecuzione di codice arbitrario.

L’aspetto più critico è la superficie di attacco: qualunque endpoint Next.js che passi un’immagine controllata dall’utente attraverso l’Image Optimization API (upload di avatar, contenuti caricati da terzi, immagini remote proxate) è potenzialmente sfruttabile senza autenticazione. Le versioni patchate risolvono il problema nell’immediato disabilitando l’ottimizzazione AVIF finché la fix upstream in libheif non sarà completamente propagata nella supply chain.

CVE-2026-75604: RCE su server Windows con Pages Router + App Router

La seconda falla (CVE-2026-75604 / GHSA-p293-qw3h-jr36, CVSS stimato 9.0) è più circoscritta ma non meno seria per chi ospita Next.js su Windows. Colpisce le applicazioni che utilizzano contemporaneamente Pages Router e App Router senza avere Cache Components attivo, quando il server gira su un filesystem Windows: in questo scenario è possibile innescare un path traversal che porta a RCE non autenticata sfruttando le differenze di gestione dei percorsi tra i due router in ambiente Windows.

Linux e macOS non sono affetti da questa specifica vulnerabilità, il che la rende particolarmente rilevante per ambienti enterprise .NET/Windows Server che ospitano frontend Next.js accanto a backend .NET, uno scenario comune in molte aziende italiane con infrastruttura ibrida. Il team Next.js è stato esplicito: non esiste una mitigazione applicativa nota per le applicazioni Windows-hosted affette; l’unica strada è l’aggiornamento.

Versioni interessate

• Path traversal su Windows (CVE-2026-75604): Next.js 13.4–15.5.23 e 16.0–16.3.2
• RCE via AVIF: Next.js 10.0.0–15.5.23 e tutte le versioni 16.x fino alla 16.3.2
• libheif: tutte le versioni fino alla 1.23.1 inclusa

Come verificare l’esposizione e aggiornare

Il primo passo è capire quale router state utilizzando e se l’Image Optimization API è esposta a input non fidati. Un controllo rapido nella codebase:

# Versione installata di Next.js
npm ls next

# Cercate se esistono sia pages/ che app/ nello stesso progetto
find . -maxdepth 2 -type d \( -name "pages" -o -name "app" \) -not -path "*/node_modules/*"

# Verificate se il Cache Components flag è attivo in next.config
grep -R "cacheComponents" next.config.*

npm install next@15.5.24   # ramo 15.5 (Maintenance LTS)
npm install next@16.3.3    # ramo 16.3 (Active LTS)

# con pnpm
pnpm add next@15.5.24
pnpm add next@16.3.3

# con yarn
yarn add next@15.5.24
yarn add next@16.3.3

Perché conviene reagire subito, anche se si usa Vercel

Le applicazioni ospitate su Vercel sono protette automaticamente lato piattaforma, ma questo non copre chi fa self-hosting su VM, container Docker, Kubernetes, Azure App Service, IIS o qualunque altro ambiente gestito direttamente. Per i team DevOps italiani che gestiscono deployment Next.js su infrastruttura on-premise o su Windows Server per motivi di compliance o integrazione con sistemi legacy .NET, il rischio è concreto: si tratta di RCE non autenticata, quindi sfruttabile da un attaccante remoto senza credenziali, con impatto potenzialmente totale sul server applicativo.

Alcune azioni consigliate oltre al semplice upgrade:

• Inventariate tutte le applicazioni Next.js in produzione, incluse quelle gestite da team diversi, e verificate la versione installata con npm ls next o controllando il package-lock.json.
• Se non potete aggiornare immediatamente, valutate di disabilitare temporaneamente l’Image Optimization API per sorgenti non fidate, o di filtrare a livello di reverse proxy/WAF le richieste verso l’endpoint /_next/image.
• Per gli ambienti Windows, se non è possibile aggiornare a breve, considerate la migrazione temporanea del workload su un host Linux/macOS finché la patch non è applicata, dato che non esiste mitigazione nota per Windows.
• Automatizzate il monitoraggio delle security advisory di Next.js e delle sue dipendenze critiche (in particolare sharp e le librerie di decodifica immagini) tramite Dependabot, Renovate o strumenti equivalenti, per ridurre il tempo di reazione a futuri annunci simili.

Conclusione

Questo doppio rilascio di sicurezza è un promemoria utile su due fronti. Il primo è tecnico: le pipeline di elaborazione immagini, spesso trattate come funzionalità “di contorno”, restano una delle superfici di attacco più insidiose nelle applicazioni web moderne, perché processano input binario complesso proveniente direttamente dagli utenti. Il secondo è organizzativo: la disponibilità di RCE non autenticate senza mitigazione nota per specifiche piattaforme (in questo caso Windows) impone di conoscere esattamente dove e come sono ospitate le proprie applicazioni Next.js, non solo quale versione del framework stanno eseguendo. Chi gestisce ambienti misti Windows/.NET con frontend Next.js dovrebbe trattare questo aggiornamento come priorità operativa immediata.

Fonte: Next.js – August 2026 Security Release e The Hacker News – Next.js Patches Critical AVIF and Windows Flaws Enabling Unauthenticated RCE

Negli ultimi anni Google ha riversato sui Pixel un numero crescente di funzioni basate sull’intelligenza artificiale, ma non tutte arrivano sui modelli più datati: spesso mancano la potenza di calcolo o il chip TPU necessari, anche quando il telefono riceve ancora gli aggiornamenti software. Una domanda sorge quindi spontanea: se Google offrisse la possibilità di sbloccare le funzioni AI più recenti sui vecchi Pixel dietro pagamento, gli utenti sarebbero disposti a pagare? Un sondaggio condotto da Android Authority tra i propri lettori suggerisce una risposta piuttosto netta, e poco incoraggiante per un eventuale modello a pagamento.

Il sondaggio: oltre 8 utenti su 10 dicono no

Alla domanda se sarebbero disposti a pagare per usare le funzioni AI più recenti su un vecchio Pixel, Android Authority ha raccolto oltre 2.000 risposte. Il risultato è netto: l’82,5% degli utenti ha definito l’ipotesi “uno spreco di denaro”. Un dato che segnala come, per la maggioranza dei possessori di Pixel meno recenti, le nuove funzioni basate sull’intelligenza artificiale non rappresentino un valore aggiunto tale da giustificare un costo extra, magari perché già soddisfatti delle prestazioni del proprio telefono o perché usano raramente questo tipo di funzioni.

Meglio comprare un Pixel nuovo

Non tutti gli intervistati, però, hanno scartato l’idea di continuare a usare l’AI su Pixel: semplicemente, la maggior parte preferisce un’altra strada. Circa il 10% degli utenti ha dichiarato che, pur di accedere alle funzioni più recenti, preferirebbe acquistare uno smartphone nuovo piuttosto che pagare un abbonamento per sbloccarle su un modello già in proprio possesso. Solo il 6,8% si è detto disponibile a valutare un servizio a pagamento pur di allungare la vita utile del proprio Pixel attuale.

L’intelligenza artificiale non è (ancora) decisiva per l’acquisto

I produttori di smartphone, Google compresa, puntano sempre più sull’intelligenza artificiale come elemento distintivo dei nuovi modelli. Il sondaggio di Android Authority, però, mostra che le funzioni AI da sole non bastano sempre a spingere gli utenti verso un upgrade a pagamento o verso l’acquisto di un nuovo dispositivo. Va ricordato che si tratta di un campione formato dai lettori di un sito specializzato, quindi non necessariamente rappresentativo di tutti i possessori di Pixel. Resta comunque un dato interessante per Google, soprattutto considerando che molti Pixel più datati godono ancora di anni di aggiornamenti software garantiti: il fatto di non poter accedere alle ultime funzioni AI, secondo questo sondaggio, non sembra bastare da solo a convincere gli utenti a cambiare telefono o a pagare un extra.

Google sta lavorando a un nuovo pacchetto di protezioni per Android 17 che va oltre le classiche funzioni di sicurezza già annunciate. Il colosso di Mountain View punta stavolta a rendere più sicura la connessione di rete stessa, un aspetto a cui gli utenti pensano raramente ma che espone dati sensibili a chi intercetta il traffico. Tra le novità più interessanti ci sono il supporto a un protocollo che cifra anche l’indirizzo dei siti visitati, nuove difese contro le finte stazioni radio base e limiti più stretti per le app che curiosano sulla rete Wi-Fi di casa.

ECH: anche il sito che si visita resta privato

La novità più rilevante riguarda il supporto a Encrypted Client Hello (ECH), un protocollo che cifra le informazioni scambiate all’avvio di una connessione, incluso il nome del server a cui ci si sta collegando. Oggi gran parte del traffico web è già cifrato, ma la fase iniziale della connessione lascia ancora trapelare dati utili a chi osserva la rete, ad esempio per capire quali siti un utente sta visitando. Tecnologie come DNS-over-TLS avevano già affrontato parte del problema, ma ECH fa un passo ulteriore proteggendo anche questa fase. Secondo Google, Android 17 sarà la prima grande piattaforma mobile ad adottare ECH su larga scala, e la diffusione di Android potrebbe spingere anche più siti web ad attivare il supporto lato server.

Stop alle finte stazioni radio base e agli SMS Blaster

Android 17 introduce anche nuove contromisure contro le celle radio base fasulle, dispositivi che si spacciano per antenne legittime per intercettare comunicazioni o inviare messaggi indesiderati. È il caso dei cosiddetti SMS Blaster, apparecchi capaci di inondare gli smartphone nelle vicinanze con SMS di phishing senza passare dalla rete dell’operatore. Con la nuova versione del sistema operativo, gli operatori telefonici potranno attivare più facilmente protezioni lato rete, offrendo una difesa che non richiede alcuna configurazione manuale da parte dell’utente.

Meno fingerprinting sulla rete locale, certificati sempre verificati

Il terzo fronte riguarda l’accesso delle app alla rete locale, ad esempio quella Wi-Fi domestica. Android 17 limiterà la possibilità per le applicazioni di scansionare liberamente i dispositivi collegati alla stessa rete, un comportamento che oggi può essere sfruttato per il fingerprinting, cioè per identificare un utente o un dispositivo senza il suo consenso, o per individuare apparecchi vulnerabili da attaccare. A completare il quadro arriva anche il supporto nativo alla Certificate Transparency, il meccanismo che verifica l’autenticità dei certificati SSL usati nelle connessioni sicure, rendendo più difficile per un malintenzionato spacciarsi per un sito legittimo.

Nel complesso, Android 17 punta a spostare parte della protezione della privacy a livello di sistema, senza richiedere interventi da parte dell’utente. Resta da vedere quanto rapidamente i siti web e gli operatori telefonici adotteranno queste nuove tecnologie, ma la direzione presa da Google conferma quanto la sicurezza della connessione di rete stia diventando un tassello sempre più centrale nell’ecosistema Android.

Per anni i Pixel di Google sono stati penalizzati da una ricezione di rete non sempre all’altezza della concorrenza, con problemi di consumo della batteria e surriscaldamento spesso attribuiti al modem. Con la serie Pixel 11, Google ha cambiato strategia passando dal modem Exynos di Samsung a un nuovo modem MediaTek, nella speranza di lasciarsi alle spalle questi difetti storici. Un test comparativo tra Pixel 11 Pro e Pixel 10 Pro conferma che la strada intrapresa sembra quella giusta, anche se il nuovo modem non vince su tutti i fronti.

5G più stabile dove il segnale è debole

Il test, condotto con la stessa SIM su entrambi i telefoni e Wi-Fi disattivato, ha misurato la potenza del segnale in tre condizioni diverse: area interna con segnale debole, area con segnale normale e ambiente esterno. Nell’area interna con ricezione scarsa, il Pixel 11 Pro ha mantenuto la connessione 5G a -99 dBm, mentre il Pixel 10 Pro è sceso al 4G a -101 dBm. Anche nell’area con segnale normale il Pixel 11 Pro ha registrato valori leggermente migliori. All’aperto, dove il segnale è forte, è stato invece il Pixel 10 Pro a ricevere un segnale più intenso: il nuovo modem, quindi, non è superiore in assoluto, ma dimostra un vantaggio proprio dove serve di più, cioè nelle condizioni di ricezione difficile.

Download fino al 22% più veloce

Sul fronte della velocità, il Pixel 11 Pro ha mostrato un vantaggio costante in download. All’aperto la media è stata di 671 Mbps contro i circa 593 Mbps del Pixel 10 Pro, circa il 13% in più, con ping leggermente più basso e risultati più costanti. Il divario è cresciuto negli ambienti interni, dove il segnale è tipicamente più debole: qui il Pixel 11 Pro ha raggiunto circa 493 Mbps contro i 405 Mbps del Pixel 10 Pro, un miglioramento di circa il 22%. In upload, però, la tendenza si è invertita, con il Pixel 10 Pro leggermente più veloce sia dentro che fuori casa: il nuovo modem, insomma, non porta benefici uniformi su ogni parametro.

Consumi ridotti in streaming, ma serve conferma nel lungo periodo

Google sostiene che il nuovo modem sia più efficiente anche dal punto di vista energetico. Per verificarlo, il test ha incluso 30 minuti di riproduzione dello stesso video YouTube in 1080p a 60 fps con HDR, usando solo la connessione dati mobile. Il Pixel 11 Pro ha consumato il 3% di batteria, contro il 5% del Pixel 10 Pro. Si tratta di un test breve, e i consumi dipendono anche da altri componenti oltre al modem, ma il risultato va comunque nella direzione di un miglioramento dell’autonomia in mobilità.

Nel complesso, il passaggio al modem MediaTek sembra un cambiamento nella direzione giusta per la serie Pixel 11: 5G più stabile in condizioni difficili, download più veloci sia in casa che fuori, e consumi più contenuti durante lo streaming video. Resta da capire come si comporterà nel lungo periodo e su reti e operatori diversi, ma per chi ha sempre lamentato problemi di ricezione e autonomia sui Pixel, la nuova generazione sembra offrire finalmente un passo avanti concreto.

OPPO ha avviato il rilascio dell’aggiornamento di agosto per ColorOS 16, la sua interfaccia Android, introducendo novità che vanno dall’editing fotografico basato sull’intelligenza artificiale a nuove protezioni di sicurezza, passando per home screen e app Note. Non si tratta solo di funzioni inedite: anche la difesa da app sospette e pop-up malevoli riceve un potenziamento, rendendo questo update rilevante sia per chi cerca nuove funzionalità sia per chi bada soprattutto alla sicurezza del proprio smartphone.

Smart Cutout: ritagli precisi con l’AI Remix Collage

La novità più visibile riguarda la funzione AI Remix Collage, che si arricchisce dello strumento Smart Cutout. Grazie a questa funzione è possibile ritagliare automaticamente un soggetto da una foto per usarlo come sticker o per comporre collage con più elementi, con la possibilità di gestire i livelli per un editing più libero rispetto al passato. Una funzione pensata soprattutto per chi pubblica spesso contenuti sui social e vuole velocizzare la creazione di immagini personalizzate.

Più sicurezza contro app sospette e pop-up malevoli

Sul fronte della sicurezza, le app Security e Phone Manager guadagnano nuove capacità di rilevamento in tempo reale. Dopo l’aggiornamento sarà possibile individuare comportamenti sospetti da parte delle applicazioni installate, oltre a pop-up malevoli e app che consumano batteria in modo anomalo, con notifiche immediate in caso di problema rilevato. In un momento in cui la sicurezza dello smartphone è sempre più centrale, poter individuare più facilmente attività sospette in background è un miglioramento dal taglio molto pratico.

Home screen più ordinata e widget per il cambio valuta

Anche la schermata home riceve alcuni ritocchi. I badge di notifica sulle icone delle app potranno ora essere cancellati tutti insieme con un semplice gesto di pinch, comodo per chi preferisce tenere la home pulita senza controllare ogni singola notifica. Debutta inoltre il widget Currency Converter, disponibile nei formati 2×2 e 4×2, per consultare il tasso di cambio in tempo reale direttamente dalla home.

Note con disegni e annotazioni sulle immagini

Anche l’app Notes si aggiorna, aggiungendo la possibilità di disegnare a mano libera, evidenziare parti di un’immagine o aggiungere annotazioni direttamente sulle foto salvate negli appunti. Una funzione utile per chi usa le Note per fermare screenshot, evidenziare dettagli in una foto o lasciare promemoria visivi sul lavoro o nella vita quotidiana.

L’aggiornamento di agosto è in distribuzione per i pieghevoli Find N5 e Find N6, per tutta la serie Find X9, per Find X8 e Find X8 Pro, oltre ad alcuni modelli della serie Reno. I tempi di rilascio possono variare a seconda del mercato e del dispositivo, quindi chi possiede uno dei modelli compatibili farà bene a controllare la disponibilità dell’aggiornamento dal menu impostazioni. Tra nuove funzioni AI, sicurezza e piccoli miglioramenti di usabilità, si tratta di un pacchetto piuttosto corposo per gli utenti coinvolti.

Nuove indiscrezioni sulla famiglia Galaxy S27 di Samsung riguardano stavolta un modello finora solo vociferato: il Galaxy S27 Pro. Alcuni render basati su file CAD, pubblicati online, mostrano un dispositivo che riprende quasi fedelmente il design del Galaxy S27 Ultra ma con dimensioni più contenute, proponendosi come una sorta di “Ultra in formato compatto” per chi cerca prestazioni al vertice senza rinunciare alla maneggevolezza.

Stesso look dell’Ultra, ma senza slot per la S Pen

Dai render, il Galaxy S27 Pro condivide con l’Ultra la barra fotocamere orizzontale sul retro, con tre sensori disposti in linea. Il colore mostrato nei render è puramente indicativo e potrebbe non corrispondere alle tonalità che arriveranno sul mercato. La differenza più significativa rispetto all’Ultra riguarda l’assenza dello slot per la S Pen, che suggerisce un posizionamento pensato per chi non ha bisogno dello stilo: una sorta di Ultra “alleggerito” nelle funzioni accessorie ma non necessariamente nelle prestazioni.

Display da 6,6 pollici, più compatto dell’Ultra

Le dimensioni indicate per il Galaxy S27 Pro sono di circa 154,06 x 73,77 x 7,95 mm, con uno spessore quasi identico a quello dell’Ultra ma un display da circa 6,6 pollici, circa 0,3 pollici più piccolo. Anche altezza e larghezza risultano ridotte rispettivamente di circa 9 mm e 5 mm rispetto al modello di punta, un dettaglio che potrebbe migliorare sensibilmente l’uso a una mano, un aspetto sempre più richiesto in un mercato dominato da display sempre più grandi.

Snapdragon 8 Elite Gen 6 Extreme e fotocamera da 200 MP

Sul fronte hardware, il Galaxy S27 Pro dovrebbe avvicinarsi molto alla scheda tecnica dell’Ultra. Come SoC si parla dello Snapdragon 8 Elite Gen 6 Extreme di Qualcomm, con un possibile Exynos 2700 riservato ad alcuni mercati. La RAM dovrebbe partire da 12 GB, con un taglio da 16 GB per le versioni con storage più capiente, disponibile nei tagli da 256 GB, 512 GB e 1 TB. Per la fotocamera si vocifera di un sensore principale da 200 megapixel abbinato a un ultragrandangolare da 50 megapixel, mentre il teleobiettivo dovrebbe fermarsi a un più modesto zoom 3x da 12 megapixel, invece del 5x montato sull’Ultra.

Batteria al silicio-carbonio da 5.200 mAh

Le voci parlano anche di una batteria da 5.200 mAh, resa possibile dall’adozione della tecnologia al silicio-carbonio già annunciata per i pieghevoli Galaxy Z Fold 8 e Galaxy Z Flip 8 del 2026. Se confermata, questa capacità supererebbe quella del Galaxy S26 Ultra, offrendo un buon compromesso tra dimensioni compatte e autonomia.

Al momento non ci sono conferme ufficiali sui tempi di lancio, ma seguendo il calendario delle passate generazioni la presentazione della serie Galaxy S27 potrebbe avvenire a febbraio 2027, in concomitanza con il Mobile World Congress. Sul fronte prezzi, alcune indiscrezioni indicano un possibile aumento generale per la gamma, con il Galaxy S27 Ultra tra i 1.399 e i 1.499 dollari, mentre il nuovo Galaxy S27 Pro potrebbe attestarsi intorno ai 1.299 dollari. Va ricordato che si tratta per ora solo di render basati su dati CAD e informazioni non ufficiali, quindi tutto potrebbe ancora cambiare prima dell’annuncio definitivo.

Diversi utenti della nuova serie Pixel 11 segnalano chiusure improvvise delle applicazioni, un problema che secondo alcune testimonianze coinvolgerebbe anche modelli precedenti come il Pixel 9. Al momento la causa non è nota, e sembra che anche Google stia seguendo da vicino le segnalazioni arrivate dagli utenti.

App che si chiudono da sole, anche su Pixel 9

Secondo le segnalazioni raccolte su Reddit, i modelli Pixel 11, Pixel 11 Pro e Pixel 11 Pro XL sarebbero soggetti a chiusure improvvise delle app in uso. Il problema si presenta in modo incostante: in alcuni casi l’app si chiude dopo alcuni minuti di utilizzo, in altri il crash avviene subito dopo l’apertura. Nello stesso filone di discussione, alcuni utenti riferiscono lo stesso comportamento anche su Pixel 9, un dettaglio che suggerisce come il problema possa non essere legato all’hardware specifico della serie Pixel 11, ma piuttosto a un bug software o a incompatibilità con alcune app.

Google Foto e Spotify tra le app coinvolte

Le app interessate non sembrano seguire uno schema preciso. Alcuni utenti segnalano crash frequenti su Google Foto, in particolare durante la modifica delle immagini, mentre su Spotify alcuni riferiscono un comportamento ancora più insolito: la riproduzione salta automaticamente al brano successivo senza alcun intervento dell’utente. Al momento non è chiaro quanti utenti siano effettivamente colpiti né quanto sia esteso il fenomeno, e non tutti i possessori di Pixel 11 riscontrano il problema.

Google consiglia di provare la modalità provvisoria

Google è intervenuta nella discussione su Reddit, suggerendo agli utenti di avviare il telefono in modalità provvisoria per verificare se il problema dipenda da app di terze parti. Se in modalità provvisoria i crash non si verificano, la causa potrebbe essere una delle app installate, e in tal caso Google consiglia di disinstallarle una alla volta per individuare quella responsabile. Alcuni utenti riferiscono invece di aver risolto il problema iscrivendosi al programma beta di Google System Services e aggiornando all’ultima versione beta disponibile, anche se non è garantito che questa soluzione funzioni su tutti i dispositivi.

La serie Pixel 11 è arrivata sul mercato da poco, e le segnalazioni di crash casuali delle app si aggiungono ad altri problemi già emersi nei primi giorni di utilizzo. Non è ancora chiaro se la causa sia da attribuire a singole app o a un problema più generale del sistema, e resta da vedere se e quando Google fornirà una spiegazione ufficiale o un aggiornamento correttivo.