>Google was passing "w" to a call to parseMode(), when they should've been passing "wt" (the t stands for truncation). This is an easy mistake, since similar APIs (like POSIX fopen) will truncate by default when you simply pass "w". Not only that, but previous Android releases had parseMode("w") truncate by default too! This change wasn't even documented until some time after the aforementioned bug report was made.
Reading about this silent API change makes me feel like I'm losing braincells. What's going on with the processes behind Android's development?
This is par for the course for Android, having had to work with it at the hardware enablement level. Google will refactor and break everything in a dot release, and then swear up and down that their code is perfect, even as you point them directly to the commit that caused the issue.
This is clearly unacceptable, but I've seen so much worse.
> and then swear up and down that their code is perfect
Even worse when they don't do this and just flat out admit they broke a usecase intentionally and label it Won't Fix because the team that implemented the breaking change is also the team that triages the issue. See logcat access being completely broken in Android 13: https://www.reddit.com/r/tasker/comments/wpt39b/dev_warning_...
I have some pretty unique insight into this since I work with AOSP a lot and have worked with a few engineers on Android's core system apps:
Google's engineers working on Android at a system level regularly break basic functionality in the "userspace"*. Google's engineers working on Android apps get early access to the Android versions and work through the resulting bugs, bubbling them back up until they get fixed.
(*userspace being used loosely here, it's all userspace vs being in a kernel, but it's interfaces that are implemented at the OS level and consumed at the app level)
Like Google is large enough that I'm sure someone will take offense to implying that such questionable engineering takes place there, but this isn't a story I've heard just once. People working on apps that are part of every GMS enabled Android image have confirmed this completely bizarre setup on multiple separate occasions
I think that just proves how stupid of a process it is?
You're relying on your internal teams' relatively outlay to catch contract breaking. And sure in this case internal is Google, meaning there are some pretty widely used apps acting as filters... but relative to the millions of apps out there, they're not likely to catch all the regressions.
They must have automated testing, but at the point where it's just accepted that things will break and your own engineers regularly have to "convince" your OS team that they broke things, you know something is wrong.
? it sounds like you didn't look at the actual commit that changed it. it was an overly elaborate refactoring gone wrong, not someone explicitly and clearly deleting a "case 'w'" or whatever.
It sounds like you don't have any understanding of sound engineering if you think modifying the default behavior of this kind of API with no fanfare is okay because "we are elaborately refactoring". Whether there was a specific intent or not.
Not that I would truly recommend to use brew on linux as there are better alternatives - docker images, distrobox with a rolling distro for newer python, or LTS distro to keep an older version, pyenv etc, but..
If you've had a problem with brew, it was most certainly caused because you sourced it in your .profile, .bash_profile or .zprofile. Never do that.
It's what brew's homepage recommends, but it can break a LOT of things and not just python. Brew should be in the $PATH only when you need it, from your current instance of interactive shell used for development, and not login-wide. The brew version of various pieces of software should not ever be able to take over what your system has or very unpredictable things will happen.
They give you a secret, in the form of a QR code (for smartphone users) or a text string.
You put the secret string in a password manager that supports one time code generation, like Gopass or KeepassXC.
When you login with your user name and password, the 2FA adds a second step where it asks for a "one time code", which your password manager provides. That code is temporary and only works for a short time frame.
at the end of my password entries and the app will treat that field as the source to generate one time codes. There's a browser addon and all I have to do is click the one time code and CTRL+V it into the field.
Reading about this silent API change makes me feel like I'm losing braincells. What's going on with the processes behind Android's development?