Comment by johdo
3 years ago
>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_...
That's completely fucked up. Arrogance much or?
They just don't care
[dead]
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
Of course, this issue did not get fixed in Google’s apps.
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.
That isn’t any better!
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.
This is absolutely horrifying.