HN user
mdwrigh2@ncsu.edu
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.
Wrong Ian -- Ian Hickson wrote about that in a blogpost, this post is about Ian Lance Taylor
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.
When we refer to "log", this is almost always means a camera gamma - an OOTF.
Wouldn't this be the OETF? OOTF would include the EOTF, which is typically applied on the display side (as you noted).
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
// Hack hack hack... then: > m -j sync && syncrestart ```
Where `syncrestart` is an alias for:
``` syncrestart () { adb remount && adb shell stop && sleep 3 && adb sync && adb shell start } ```
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.
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 :)
[1] https://www.displaymate.com/iPhone_13Pro_ShootOut_1M.htm#Whi... [2]: https://www.displaymate.com/Galaxy_S20_ShootOut_1U.htm#White... [3]: https://support.apple.com/en-gb/HT208909 [4]: http://yuhaozhu.com/blog/chromatic-adaptation.html
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.
[1] https://www.khronos.org/registry/EGL/extensions/ANDROID/EGL_...
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.
Google slides: https://www.theverge.com/2018/11/8/18076502/google-dark-mode... Display energy modeling: https://onlinelibrary.wiley.com/doi/am-pdf/10.1002/stvr.1635
[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.
It's "Don't be evil" and it's still in the code of conduct:
And remember… don’t be evil, and if you see something that you think isn’t right – speak up!
Some of these exist:
learn how to build Android from sources
https://source.android.com/setup/start has instructions.
put some binary drivers from official image
https://source.android.com/setup/build/gsi is a set of builds you can flash on any sufficiently modern Android device alongside their binary drivers.
May be even some guides how to reverse engineer proprietary drivers and rewrite them as open source.
You're on your own for this, but given the kernel and HAL APIs are both open source you could theoretically figure out how to build a viable implementation, but no matter how you go about it, building something like a GPU driver is a substantial task. You could probably build things like the lights HAL without too much difficulty though.
While the kernel theoretically has the ability to preempt you, it's not supposed to when using a realtime priority thread. Per the RH realtime guide[[1]:
""" SCHED_FIFO and SCHED_RR threads will run until one of the following events occurs:
- The thread goes to sleep or begins waiting for an event
- A higher-priority realtime thread becomes ready to run
If one of these events does not occur, the threads will run indefinitely on that processor, and lower-priority threads will not be given a chance to run. This can result in system service threads failing to run, and operations such as memory swapping and filesystem data flushing not occurring as expected. """
SCHED_DEADLINE, which is newer and not mentioned in the guide, can provide a bit stronger guarantees because it can fail if it thinks the requirements you set aren't actually obtainable based on other system load (including high priority kernel tasks that might need to run, etc).
[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
It was always "don't be evil" [1]
Note that 'their "service"' includes the Play Store, which is a not insignificant revenue generator for Google.
Skia does not have a stable ABI, which is a requirement for inclusion in the NDK: https://github.com/google/skia/blob/master/experimental/c-ap...
If the battery does degrade to the point of needing to be replaced, there is a message in the battery settings page: http://media.idownloadblog.com/wp-content/uploads/2017/12/iP...
"Google/Alphabet doesnt have to pay them for the content now."
When a video is demonetized, only a small subset of advertisers or no advertisers can be shown on that video. If no ads are being shown then neither Google nor the creator are making money (and Google is spending money to host and serve the content), so really this is a lose/lose for both of them.
That's not necessarily because you could do it in a single frame; a lot of the old touch controllers would maintain high levels of hysteresis as a really crude technique to mitigate low SNR. Couple that with a fairly dumb implementation of pointer tracking and you end up easily fooling touchpad into thinking the two pointers are the same. Note also that this is a much rarer and more user-friendly failure scenario than choosing to have the software err in the other direction (erroneously splitting a moving finger into two separate pointers, one of which may look like a tap gesture).
Source: I occasionally work with touchscreens, many of which experienced the same issue in early devices.
Note that you can always mute a tab in Chrome, which I suspect would remove the exemption as well.
Android was also mostly left alone for a number of years.
I was thinking of a test program that inverts/cycles the screen colour on registering a keypress. Put a photodiode in front of the monitor and use an electrical switch across the controller button contacts. Cheap parts and an oscilloscope will give microsecond resolution for the end-to-end net case.
This, essentially, is one of the ways we measure end-to-end touch latency on modern phones.
For those of you writing Android apps, this is essentially what the monkey[1] tool is for.
Flats in the UK are often not sold as in the US, but rather you purchase a long term (100+ year) lease to the property with the option to extend essentially indefinitely (for a reasonably small cost). Some flats comes with a share in the freehold (ownership of the actual building), but at least in London those are fairly rare.
A couple parts of it remind me a lot of JBQ's post on "dizzying but invisible depth": https://plus.google.com/+JeanBaptisteQueru/posts/dfydM2Cnepe
Sure, Gonk is below the application level, but it isn't the kernel nor is it drivers.
Last time I looked, Gonk used a significant amount of Android code as well that wasn't drivers[1]. That being said, they are fairly significantly different at a few levels.
[1] https://mxr.mozilla.org/mozilla-central/source/widget/gonk/l... is pretty much all taken from Android.
Yep, client certs installed on a device with verified boot and an account authenticated via 2FA would be a good start.
Thanks for caring to fix it!
For what it's worth, I agree with pretty much the rest of your post. Too often I see people start to complain about "pre-mature optimization" but when you're trying to do something like hit a smooth 60fps animation then a lot of these things really matter. Profiling is great when you have hotspots, but too often these things are plagued by a death of a thousand cuts.
Well, good luck, because Android devices have touchscreen latency of 100+ ms.
For what it's worth, this statistic is a little outdated, a little wrong, and not necessarily the one you care about.
A little outdated: It was done in 2013, and in the past couple years the touch panels on most flagship Android devices have gotten significantly better. Even the linked article was comparing Apple's latest device to older flagship models. The Nexus 5, released a week after Touchmarks published their numbers, consistently has about 70ms of latency, for example. The M8 reportedly[1] gets around 50ms of latency, which is pretty astounding.
A little wrong: There were multiple issues with the Touchmarks benchmark. They reportedly "discovered an optimization in our iOS test app that was not present in our Android or Windows Phone test apps", they had known race conditions that could introduce additional delay on Android that were never fixed, etc.
Not necessarily the one you care about: That statistic measure physical touch down to visible response, but you only actually care about the time until the application receives the event because that's the point you actually can kick off the network activity. Considering the display latency side of it is ~48ms, that's a fairly significant difference.
[1] http://www.phonearena.com/news/Funky-metrics-HTC-One-M8-has-...
We use it for basic device recognition so we can do things like normalize keymappings on Android. See https://source.android.com/devices/input/key-layout-files.ht...