According to Camera2 Test output (not the best, but sufficient), the report in question (pic attached) doesn't seem valid as the reported white levels are 1023. The guy is just likely excited by quality of 10-bit raw video and there's nothing to see there. Considering that P8P actually has 16:9 DCG you can force by a prop, there's a chance that P10 has something similar, but Google doesn't seem interested in exposing such a mode until they make it 4:3.

setprop vendor.camera.force.sensor.mode 10 or setprop vendor.camera.force.sensor.mode 11 followed by killing of camera stack (no command at hand, but you should figure it out) will give you the 16:9 12 bit DCG mode in question on P8P.

I realized that Qualcomm really insists that 8s SoC series shouldn't be hitting the complete capabilities of premium chips from years ago. The 1080p480 slowmo and an 8k60 decoder strongly imply that 8sg4 wouldn't have an issue with 4k120/8k30 encoding.

I understand that earlier gen premium SoCs with vendor and kernel refreshes are a viable option, but it'd be nice to see something natively fresh and more efficient, while matching the performance and feature set of earlier generations. Snapdragon 855 has no business in being better in encoding than a modern subflagship SoC.

So yeah, mode 10 is 30 fps 16:9 DCG, mode 11 is 60 fps 16:9 DCG. If their per-frame noise is equal, always pick mode 11, as frame rate selection should extend its blanking to achieve lower frame rates just fine.

https://www.androidauthority.com/how-android-sideloading-restrictions-may-work-3595355/

I trust the promise of ADB installations (because I don't think Google is so eager to advertise the currently tiny competition with more freedoms), but daaamn. Previously a master toggle in dev settings (somewhat noob-proof), then granular, but more accessible screen right during installation as if to please regulators by showing how easy it is to sideload, and now an attempt at consolidation while making things look "the same" to an end user.
It looks like I was right and sideloading apps from undoxed devs will remain as a thing, but made more painful. Global stock ROMs may now become China simulator where you need to install Shizuku to conveniently sideload a split apk without physical connection. And now Google allows themselves to choose what they'll stamp on, so even Shizuku may have to be sideloaded over ADB first. Guess Google already started counting that YouTube premium money expected from noobs who gave up xD
(just kidding, they'll probably download random malware from Google Play as long as it stops YouTube ads)

okay fuck Waymo’s, lmao

It locked with my phone inside and it has no way to contact support on the outside

I had to block it from leaving and use a random persons phone to call them

Waymo aside, a friend promised me a guide for all of you (and me) on how not to use an ancient gcam and yet have a natural output. Stay tuned.

https://www.privacyguides.org/articles/2025/09/08/chat-control-must-be-stopped/

Let your representatives know that poking holes in end-to-end encryption doesn't make anyone safer and will also affect them.

https://grapheneos.social/@GrapheneOS/115164183840111564

Delaying access to security patches by 4 months to nichest OEMs and the public to satisfy sloppy biggest partners with bureaucratic update policies is a little bit crazy.
Government-funded threat actors are safely assumed to be in possession of patches in question as they're exposed to lots of individuals for the sake of not creating any inconvenience. It's hard to not agree with GOS on this one.

Unless some semantics are involved and they're referring to QPRs as if they're SPL (still a valid concern)? 🤔

♻️🌱 (it's also combined with Snapdragon 6 gen 3, which is a refresh of first gen)

https://www.androidauthority.com/android-risk-based-security-updates-3597466/

So this is great news for the laziest OEMs. If Google determines that no patch is important enough to make it a part of monthly SPL (despite being aware of vulnerabilities), an OEM is literally ennoscriptd to a free string update. Yes, an update that literally changes nothing except the security patch date – the date alone.

But wait, if Google knows what constitutes an important patch, why OEMs can't even name the less important vulnerabilities they decided to patch out of their own will? Oh, maybe they aren't as much unimportant as Google would want you to believe and malicious parties can now count on a longer exploit lifecycle... That would be unfortunate.

Honestly, this is really ugly. As much as it's hard to swallow it, GOS is absolutely right in their Mastodon thread. Not relying on an OS vendor known to merge private patches as soon as possible now means being months behind instead of just one. Unless they start leaking and getting merged by more custom ROM projects, a person reasonably expected to be targeted no longer can trust any builds (including stock) that aren't known to utilize them.

In current state of things, yes, no important person should use anything but an iPhone or the supposed special edition of GOS. I'm mad that I have to shill them.

Btw, to this day, there are people who think moon modes actually work like this (they don't, they just invent craters)