> * Google drop "real" Android source-code updates to OEMs _and_ the public every half.
All of the major OEM shave access to the internal source with a _very_ small delay. OEMs don't ship these intermediate releases because they choose not to, not because Google witholds the source for them.
Oh! I had thought they stopped at the same time they closed off AOSP commits - that makes this entire rabble-rousing effort _exceptionally_ silly, then; I can't see the angle GrapheneOS are trying to push at all in that case (like, I get their side of the _concern_, but "Google are shipping features to Pixels that you don't get" becomes... quite a poor argument indeed in that scenario).
The whole security embargo things seems incredibly stupid. OEMs are always too late rolling out security patches. So Google thought, "let's create an embargo of months so that the OEMs have time to integrate the patches". Anyone could see it coming that nothing would change and the OEMs would still wait until the very last moment.
So now everybody is off worse. Not only are OEMs still slow with security updates, while CVEs float around for months among those within the know (or reverse engineering skills) for months.
I think the overall source embargo is rational _until_ fixes appear in a released binary build. Otherwise there's an integration/QA/rollout window where a source patch is public while the binary patch is unavailable to anyone, including attackers, which is undesirable. In "full" open source this has always been a time-suck mental gymnastics exercise around hidden mailing lists and obfuscated commit messages (which probably aren't useful in the LLM era anyway). It makes sense for Google to avoid engaging with that given they don't need to; I think it would be fully logical for them to perform source drops gated on the rollout cadence to the first available binary release channel.
I fully agree the slower-than-Pixel "vendor lead time" windows are really detrimental. Once the binary patch is out, the source patch and disclosure is effectively out too; those extra windows just let OEMs continue to be lazy as a matter of policy (which they love to do regardless) while exploits are already available.
Yeah, that's exactly what happened with the Pixel C. A lot of politics around who would own tablets and laptops at the time that meant the winds changed direction ~yearly, hence the horribly confusing product line ups that happened.
You can disable them, which is functionally uninstalling. Actually being able to uninstall them isn't technically possible because their base images live on a read-only partition so they survive factory reset (which erases all RW partitions). The OS could _pretend_ they're uninstalled, but that seems strictly worse than the existing presentation which more accurately reflects reality.
Not exactly the same situation, but I keep wondering : is deleting personal data only "pretending", since most of it could potentially be restored for quite some time (especially on transistor storage) ?
> The ritual to compile, pack and flash super.img into the device is absurd.
I typically only do a full flash for the first build after a sync. Afterwards I just build the pieces I'm changing and use `adb sync` to push them to the device, skipping both the step that packs the image files and the flash. The `sync` target will build just the pieces needed for an `adb sync` if you don't know exactly what you need to build; I typically use it so I don't have to even think about which pieces I'm changing when rebuilding.
So typical flow goes something like:
```
// Rebase is only needed if I have existing local changes
> repo sync -j12 && repo rebase
// I don't actually use flashall, we have a tool internally that also handles bootloader upgrades, etc.
> m -j && fastboot flashall
Incremental compiles while working on native code are ~10 seconds with this method. Working on framework Java code can be a couple minutes still because of the need to run metalava.
AFAIK, sync works on Linux only since it needs $ANDROID_PRODUCT_OUT. The problem is that I develop on a Windows machine (vscode with ssh extension) and my source code is on remote Linux machines (in premises), dedicated to building AOSP. Since I build at least for another 5 platforms, my working PC cannot cope with the current (and future) workload/space, so I asked to move all the source to dedicated hardware for building. Perhaps I can do it with ADB through Wifi...
I always thought sync worked with frameworks or packages, but since you mentioned "native" I guess it will also sync vendor stuff?
I'm not the parent you're asking, but figure you might be interested anyways since I could've likely made the same comment:
I work on displays within an OS team. Having some basic understanding of colour theory is critical for a significant number of modern display projects, particularly for the high end. For example, enabling colour accurate rendering (games, photos, etc), shipping wide-gamut displays (how do you render existing content on a WCG display?), etc. More specifically to the planckian locus, it generally comes up when deciding which white point to calibrate a given display to at the factory (e.g. iPhone is 6470K, S20 is 7020K in Vivid)[1][2] and if you're doing any sort of chromatic white point adaptation, like Apple's True Tone[1][2].
My background before joining the team was a degree in math, but I really enjoyed doing low level projects in my spare time, so ended up on an OS team. We also have colour scientists who study this full time and have a _significantly_ better understanding of it all than I do :)
> It seems somewhat silly on a non-realtime OS to grab one frame, request a 15ms wait, and then grab another frame, when your deadline is 16.6ms
A couple reasons this isn't as silly as it seems
1) ~All buffers in Android are pipelined, usually with a queue depth of 2 or 3 depending on overall application performance. This means that missing a deadline is recoverable as long as it doesn't happen multiple times in a row. I'd also note that since Netflix probably only cares about synchronization and not latency during video play back they could have a buffer depth of nearly anything they wanted, but I don't think that's a knob Android exposes to applications.
2) The deadline is probably not the end of the current frame but rather than end of the next frame (i.e. ~18ms away) or further. The application can specify this with the presentation time EGL extension[1] that's required to be present on all Android devices.
Skia has been around for 15 years (open source for 12) and is used in a number of high priority projects for Google (e.g. Android, Chrome). It's incredibly unlikely it will be killed any time soon.
> At a meta-level, I'm surprised that something with so factual (and testable) an answer can still not be settled.
It is absolutely settled, and has been tested over and over again. Power is roughly proportional to the amount of light emitted[1], so having dark grey is absolutely a power savings over pure white.
[1]: This isn't totally true mostly because the display is broken into RGB elements emitting light of differing efficiencies and human perception of the brightness of those elements is not identical.
All of the major OEM shave access to the internal source with a _very_ small delay. OEMs don't ship these intermediate releases because they choose not to, not because Google witholds the source for them.
reply