Google makes Android development private, will continue open source releases
arstechnica.com
arstechnica.com
Android was already a platform on life support. Google has wielded its authority to dictate how apps should behave such that even 3rd party stores do not stray far from Google's rules. Users of android phones have little hope to run a program from 5 years ago, or to roll back a bad update in an era full of bad updates.
Android is actually much much better than iOS. For some older unmaintained apps I've dug out the APKs and most of them run without major issues, though a scary warning saying it's designed for older versions of Android.
Every few months they force you to upload new builds that use the latest "api level" .. This change makes zero difference to how the app functions.
Its a massive pain updating them and I have let several apps lapse and be taken down cus I couldnt be bothered jumping though googles arbitrary hoops.
Which I guess is google's aim, and also that they are doing this to clear as much space as they can and save a small amount of money on storage, as part of their general enshittification process.
That's not true, different api levels have different restrictions and defaults even if you don't change any of your app code, that's why they force you to target a new api level.
For example, one Android 15 change is "Apps that target Android 15 must be the top app or running an audio-related foreground service in order to request audio focus.", or another one "For apps targeting Android 15, the `elegantTextHeight` `TextView` attribute becomes `true` by default".
It's not always a no-op. There's zero chance that storage costs are the concern here, they've long struggled to fix overly permissive APIs and poorly designed legacy APIs on apps that target old api levels.
Android has a yearly release to target a new API and this has been in place for quite some time, it's not really arbitrary.
Do I agree with it? Not really, but let's at least be honest with the time line -- and if you want to keep your apps available, the very least is a once-a-year update, shouldn't be that difficult...
- Unless you don't want Google to know your location constantly, no matter what setting you use for the GPS chip.
- Unless you want security updates past a year.
Ironically Googles Pixel phones have the longest support of any phone OS with guaranteed at least 7 years of security updates.
That's not been the status quo any more for a while since the EU started to mandate several years of OS and security updates. Samsung and I believe Google as well have stated they'll do 7 years of udates.
> 1 Availability and timing of Android OS upgrades and security updates may vary by market, network provider and/or model.
note that it says "up to 7 years" and may vary by market. and has only been in effect for 15 months so there isnt a track record to say it will actually happen.
On my phone it is off and stays off. Unlike on iOS when it turns itself on.
Their map of wifi SSIDs allows pretty accurate geo-location, with no GPS.
This doesn't apply to you if you travel in an area with no wifi hotspots. The hotspots don't need to be publicly acessible, only the SSID needs to be visible for the hotspot to serve as a geo-location waypoint.
Android used to split storage into various partitions, which is why this used to work - It was able to unmount the partition and let your PC manage it. This meant any apps using that partition needed to be stopped, etc etc. It was a pain, and I can totally understand why they moved away from this approach.
Personally I prefer the new way, yes using MTP has some limitations as you've noticed but it does mean the storage can remain mounted on android while your PC accesses it.
In the case of plugging a "phone", as a device, into a USB host computer, the USB device (the phone) can present a filesystem endpoint to the host, and allow read/write access. The OS of the phone then passes these read/writes through to its mounted filesystem, with whatever mapping and access controls to the mounted filesystem it wishes to implement.
Thus the USB connection doesn't require that the raw filesystem of the phone be mounted by 2 hosts at the same time.
This already happens with every USB "stick" you plug into a host computer. The memory in the USB stick is accessed by firmware on a CPU inside the memory stick, which then presents that memory to the host as a USB storage class device. The firmware may not have a linux or iOS OS, but it does perform mapping to preserve and remap sectors to alleviate flash endurance issues, perform secure mounting, and other features.
There's no technical reason android can't do this.
p.s. MTP clients accessing an android device are a major PITA! Especially, ironically, for a linux OS USB host...
If the host and guest both get presented with the same “array of bytes” mass storage interface, then they will compete and potentially mess up each other’s reads and writes, let’s say if they both treat that array of bytes as an ext4 file system and try to write a file system metadata to the same physical location at the same time.
Of course you have have a “virtual file system” exposed over USB, but isn’t that exactly what MTP is? The point is that USB mass storage is not a virtual file system.
People often lament about the early days of smart phones where you could put in a microSD card to expand storage and even move apps to it. But nobody remembers the details of how janky it really was. AOSP and Googles own Nexus phones never supported apps on microSD, it was added by other manufacturers and was not perfect, often apps crashed when running from microSD or ran slowly.
I'm not defending MTP either, it's a mess too and hasn't gotten any real multiplatform improvements since back when it was first being used for MP3 players.
> its existence is to serve Google's whims
Ah, yeah... the existence of every major project is to satisfy the companies paying for the development. Linux has been over 80% corporate commits every year since 2003. Blender is funded by 35 corporations. Not one open source project larger than a library has gotten anywhere major without corporate sponsorship.
So it's bad faith because they didn't open source as much as you wanted, and you want parts that aren't open source because you don't find it useful enough.
Have you considered that maybe this is not a great bar?
Your claim of bad faith is based on what you want, and not based on how any of the people involved actually operated.
Perhaps you should not claim bad faith without evidence the people involved actually operated in bad faith.
Thankless people for whom somebody's particular open source project is not enough and feel like they are entitled to more are one of the worst things about open source as an ecosystem overall.
On top of that, i'm very curious to understand what exactly you think would be the state of the world had AOSP not been released.
(Also, as an aside, open core did not exist at the time AOSP was released)
I think something like "Is it actually reasonably possible to build something usable from the parts that are Open-Source?" Is not a bad line in the sand, though it's not a very clean one.
You can quibble about it generally, or talk about case-by-case specifics, but your outrage seems a bit out of proportion, it's a reasonable position to take.
At a time when none really existed. Not even close.
They also went out of their way to generate open drivers and rewrite those where vendors would not give them some, and ensure they had contracts that let them do so.
Calling this open core is also insane even if it wasn't a retcon. At the time, >95% of all android code in existence was open source. Probably closer to 99%. The remaining pieces were mostly related to prototype phones that never saw the light of day.
How is it possibly "less misleading" to call this release "open core"?
How it is a reasonable position to literally accuse them of bad faith because the parent didn't think it "useful enough"?
Admittedly I think open core is just a definition someone made up to beat others over the head with for "not being open source enough", so I wouldn't use it anyway[1].
But here, moving the goal posts because it didn't include whatever particular piece the parent wants does not make it a reasonable position, and it definitely is not a reasonable one. Nor is the completely unsubstantiated bad faith accusation.
My outrage is because i tire of watching people tear down things and literally accuse folks of bad faith because, 20 years later, they decided it wasn't good enough for them. The fact that this doesn't outrage more people says a lot more about how the open source community behaves than it does about android.
If this is the bar for reasonable positions, it's a really crappy bar.
[1] FWIW - while i was not always, i'm fairly consistent these days in believing that all the forms of trying to shit on open source releases or come up with no-true-scotsman terms to use for not being "something" enough are a plague, regardless of whether that something "accepting features that i want" or "releasing pieces that i want" or whatever. The sense of entitlement involved is often impressive. Was it released under an open source license? Cool it's open source. Period. I'll just be thankful someone took the time to share and use what ever they did share to build cool things. They don't owe me crap.
Why not? What useful feature is gated behind a proprietary API. Casting is one I can think of. But I think you can still get plenty of use out of a phone without casting.
There is technically a casting API in AOSP but it's old and doesn't integrate with Chromecast as well.
You're example of Linux is a bad one. Its contributions are corporate, but they are collaborative. With Android, Google dictates and others follow. Linux is not this way.
Samsung tears most of the UI layer off Android and installs their own look and feel. Google does the same with Pixel, Huawei does with their phones, and so on. You have to follow some of Google's rules to get Play Services, but Android varies immensely depending on vendor. Ditto for things like background tasks and battery life management.
The same applies to Linux. The kernel changes significantly on vendor as well, with changes making it upstream only if the famously tribal Linux maintainers find it interesting. I am sure that the same applies for code from Samsung or Qualcomm to the Android codebase.
Let's think on this statement a little. From top of my head:
- VLC
- Darktable
- rsync
- KDE as in the Desktop Environment
- Clementine Music Player
- MusicBrainz Picard
- GIMP
- Zotero
- GNU Octave
- Kid3
- KMail
- etc, etc...These apps are not sponsored by corporations directly.
Also, your point is untenable. The moment someone patches something while being employed by a company, that thing becomes "developed via corporate paycheck". This also makes the small tools developed by oneself "developed via corporate paycheck", because while the person was at home, and it was 2AM, They also had a job paying their bills somehow.
There's a big difference between all/most of the interest coming from a large company, compared to the numerous organizations that work together to make Linux what it is.
Bold statement. Who is the corporate sponsor of Emacs?
What do you mean by this? I have had changes upstreamed into AOSP and I'm not a Google employee.
>Its massive codebase that requires immense resources to build is not open for negotiation
So is every other operating systems. Do you think the millions of lines of codes for Windows builds instantly? You can get by building AOSP on a normal desktop workstation.
iOS must not even exist anymore because it’s closed source. I can feel my iPhone disintegrating before my eyes.
Look-but-don’t-touch source, except for how there are multiple successful alternative builds like /e/os, LineageOS, and GrapheneOS
The second largest country in the whole world gets by using Android without Google Play services even being available there, with Android commanding a 77 percent marketshare.
Sure, I fully agree that Google isn’t super enthusiastic about open source for Android beyond the ways in which it benefits them, but there’s a lot of hyperbole in your comment.
Android is unhealthy versus its former self in that it has been increasingly hostile to developers. Your examples of /e/os and lineage are representative of the "look-but-dont-touch" nature of Android.
Not to diminish the hard work of the developers of them, as they are useful, but they do not stray far from what Google provides them for better and worse. As you say, they're alternative builds, primarily to reduce the ties to Google, but they largely adhere to the same APIs, have the same menus, have the same quirks. Perhaps graphene goes above and beyond, I have not used it. I remember Cyanogenmod having more divergence in feature set and appearance from what Google provided versus what Lineage can do for you now. I miss when Android was good, but it's just become the platform I don't want to upgrade and see what I lose next.
Now changes in toolkits made it so that e.g. copying text from apps sometimes doesn't work. Google Android has a work around by using OCR (?) in the overview to select text. I feel like the former change is directly related to the ability of the OS to copy text anyway. This might not be a deliberate choice to limit AOSP but it shows how they design with proprietary Android in mind. Thus AOSP gets less useful as an OS as the design is not well thought out.
the point is that you're not going to be able to upstream any changes
Why don't you go back to 2006 and tell me which complete open source mobile OS you want to use.
An immense amount of time was spent beating up vendors and others to be able to release, as open source, an OS that you could actually build and put on a phone. These were the days that verizon and AT&T and other controlled exactly what OS's were allowed to run on phones.
Even being able to unlock a bootloader was not a thing.
The only thing that has happened for "as long as i can remember" is that different factions of open source folks have never been happy with the precise contours of AOSP vs what they want, and choose to shit on the immense hard work of lots of people as a result.
Yet i doubt any of them would be close to where they are, at all, had android not been released as open source.
Can we please stop rewriting history because we have some disagreement with the contours. It was an immense leap forward for open source OSes on phones.
Apple released the iPhone and basically told all of the carriers "tough crap, you can't put your bloatware on our phones. This started with AT&T (exclusive carrier for iPhone) and by the time that agreement ended, every carrier was clamoring for the iPhone on their network. It was the next big thing after all. If you don't want us on your network you can explain to your customers why they can get an iPhone on a competitor, but not on your network." Vendors had no choice.
I dunno, Early iphone did not have the market share to command this in the way it does now. Android did fairly quickly, knocking off Symbian and RIM much faster and getting to higher market share much faster than apple.
Honestly, I think it was both in combination - and more particularly, that none of the up and comers (apple or android) were willing to accept control on the part of the carriers.
Back then Google was even bidding on spectrum :)
I'm unsure what would have happened if only one of android/iphone had existed.
Apple did not go for market share, that’s what makes you misunderstand what happened. Android was nothing when the ball started rolling, which is when Apple used its leverage (and Cingular’s struggle at the time) to be as independent of the carrier as it could. The early success of the iPhone spooked Verizon, which put a huge amount of resources behind the Droid campaign, which is when Android really took off. This is fairly well documented. RIM obsoleted itself by not taking it seriously, and then seriously fucking up the Torch.
Android ended up getting the largest market share because it was in the right place at the right time. Google had the technical abilities and humongous resources to develop it, so the OS was good enough. And the OEMs rushed to provide modern hardware cheaper than iPhones. Google itself did not need to get money from phone sales and was happy to let OEMs die if they failed to race to the bottom.
I disagree pretty strongly with this - I was around at the time, involved in the contracts and very close with the business folks.
This is definitely not the version of history i lived or remember :)
But honestly, it was also 2 decades ago so i don't care enough to go dig up data to refute it, so i'll drop it.
Citation please. Android was already becoming quite a topic before Verizon jumped on the bandwagon.
Finally an alternative to WinCE without getting stuck with Apple. I don't remember anyone claiming that Verizon caused Android to "really take off".
This is also true of iOS. What alternative would you propose?
Obviously, you will be able to find plenty of examples of things that don't work, and you probably have a bank app or some other thing that you need Google for, but alternatives do exist, and I'd argue that you can have a healthier, more productive, and more enjoyable experience if you can have all your needs met by software that isn't treating you as a product.
My opinion is you should use whatever works; I do. But try not to absolutely need software that you can't control.
Some countries have tied their banking to their phones, with apps that use SafetyNet to check how Googled you are.
Somehow corporations and nations have given sovereignty away for convenience and so you may need 2 phones: the google one and the good one, to properly be f-droid only.
Makes me wonder what the tradeoffs/alternatives are. Maybe they could have still moved features to a Play Services-esque library but published the source for it. Considering we're commenting on a post about how developing in the open is too inconvenient for modern Google, the difference might have been moot.
AOSP is a compromise, because device manufacturers don't want to share anything. Google effectively negotiated with device manufacturers to open source part of their software. Device manufacturers lose some of their secret features to competitors. In exchange, they don't have to develop those features themselves. App developers get a standard platform, which benefits everyone: users and manufacturers and app developers.
This is very much a win-win situation, because the alternative is that every manufacturer has their own proprietary system.
No, it's a lose-lose situation. If we have 100 different mobile OS's it's a matter of time until a "good one" appears, and we get some sort of innovation in the space - be it from a technical perspective, from an UX perspective, or whatever.
Now we're all stuck with Android, where manufacturers can't really do anything interesting with their phones, users get an incredibly bloated, technically incompetent system, and all parties have to abide by Google's every whim.
Hopefully they can still function like this
Nice. While Android was not open source for a long time, at least it's not openwashed anymore.
What do you mean by this? Maybe you couldn't get your contributions in, but you could fork Android any time.
Moreover, without closed source and kernel targeted drivers, it’s not possible to even boot hardware with Android for an eternity now. None of the companies will give you even an object file which you can link against a more modern kernel (given the delta is not that big so ABI is not broken), yet alone the source code.
As a result, Android is a big mountain of open code, without the crucial parts needed to make it work. AOSP is a shell of its former shell, and being emptied day by day.
Now it’s moving to a cathedral model from a bazaar one, and who knows when Google will release the source code of the “new version” of AOSP. They may even strip the tree to GPL parts since they have to open these parts and conveniently forget to update the MIT parts on the open part.
IOW, silently stop as Oracle did for the parts they can.
https://groups.google.com/g/android-building/c/T4XZJCZnqF8
https://news.ycombinator.com/item?id=3235926
> This release includes the full history of the Android source code tree, which naturally includes all the source code for the Honeycomb releases. However, since Honeycomb was a little incomplete, we want everyone to focus on Ice Cream Sandwich. So, we haven't created any tags that correspond to the Honeycomb releases (even though the changes are present in the history.)
Discussion: https://news.ycombinator.com/item?id=43484927
If the stuff the AI companies are promising has any truth in them, Android and iOS or any software should become irrelevant soon.
Lock threads to a particular core on creation, every core does a Round-robin over all threads. You're 50% there.
Have the core detect congestion, and move yeet threads to another random core when it's congested. You're 75% there.
Use three lists for priorities instead of one. You're 90% there.
Make up for the other 10% with sane design in other subsystems.