Hacker News new | comments | ask | show | jobs | submit login
Android Oreo (android.com)
778 points by axg on Aug 21, 2017 | hide | past | web | favorite | 641 comments

The most interesting part is the way they are planning on tackling fragmentation in O onwards with Project Treble [0]

If your device ships with O it should be running an immutable semantically versioned HAL. In essence you should be able to be able to flash AOSP on every new device. No matter what the vendor does.

Edit: I can see it now, in the technical specs of each device you will see a list of HAL Versions. The newer your HAL the longer you can expect support from AOSP if not your vendor.

[0] http://androidbackstage.blogspot.co.uk/2017/08/episode-75-pr...

I'm very skeptical of the level of optimism that is thrown towards Project Treble.

In the end it's just a way to make OEM's lives easier while developing updates. It will still require them to actually make updates for devices. Despite Project Treble they will still not have an economic incentive to update devices. And that is the core issue here, really.

My expectation is that Project Treble will help speeding up Android updates - they should come to devices sooner than they are released now, because Treble shortens the development process of updates. I don't expect devices to be updated any longer than they are now, or receive much more updates. OEMs will remain economically unpunished for not updating and likely will just pocket the money saved in the development process.

The only way to solve this problem is to build a "Windows Update for Android" whereby system components are updated in a modular and OEM independent way. The fundamental issue in Android's update problem is that OEMs are fully responsible for device updates and not motivated to do this job well, and Project Treble does not signficantly change this [1].

Don't get me wrong, Project Treble is a great move for Android. I however don't think it will make a huge difference in the Android update story.

[1]: EDIT: it's worth pointing out that Project Treble looks like a necessary move to make a "Windows Update for Android" happen though. Let's see if that becomes a reality.

>and Project Treble does not signficantly change this

This hits the nail on the head. ProjectTreble thing will make no significant change in the long run. OEMs don't care about updating Android, they only care about selling hardware and developing shitty custom launchers.

Google is the only one that could change this. They could "tie" the Android licensing (Play Store and their custom bits) to forcing the OEM to release n major version updates . But they won't do this because it will hurt them financially (less licenses sold in the long run..)

To be honest, I think Google has LG, HTC, Sony, Nokia, Lenovorola, and almost every other Android manufacturer in the pocket here. These companies don't have the capabilities to independently make a competitive OS and app ecosystem and will have to comply with Google wherever it goes. With the exception of LG, all of these companies have even significantly dialed down their efforts to customize Android from AOSP or "Google's Android flavour" (that ships on Pixels) in the first place.

However, when Google would make such a move then they will see Samsung leave immediately and Huawei shortly thereafter. And Samsung makes 50% of Android devices - it will be a very hard business decision to justify destroying their ties with Samsung over device updates [1]. Note that Samsung periodically trots out their Tizen operating system to remind everybody that they can be independent of Android should they want to. Huawei will probably just fork Android and attempt to maintain their own app store.

The Android device market is rife with politics and the consumer is mostly on the short of the stick for it. And Apple is the real winner there - they can sell more expensive devices because people are rightly happy to pay a premium not to deal with Android's bullshit.

[1]: Ironically, Samsung is likely the best Android OEM for device updates - if and only if you consider their high end Galaxy S and Galaxy Note lines. The real issue is that Samsung wants to also flood the market with cheap crappy devices and never update them - and will likely happily ditch Android for Tizen to continue to do so.

Honestly, I'm not sure it's any threat from Samsung that means Google won't do this. I think it's (justified) fear from their legal team that adding any additional licensing terms to the Play Store right now given the European Commission are about to come down on them like a ton of bricks under anti-competition law is suicidal.

Shame Google wasted a lot of capital they had trying to do some really silly things in Android for a few years, and didn't lance this boil while they still had the chance.

Couldn't Google use an immutable HAL as a way to make updates themselves? Let users drop manufacturer customizations and get stock android on an older phone.

They might. In an edit above, I remarked that for such a system to exist indeed Project Treble is a necessity. But taking centralized control over the way Android updates will be a very ballsy political move by Google to make.

Some smaller vendors might appreciate that these responsibilities are taken away from them. Sony, HMD/Nokia and Lenovo/Motorola are basically only adding some apps, themes and tweaks to AOSP at this point anyway, but do tend to have relatively good update reputation (or used to). But other vendors will not appreciate giving away this control at all. Some vendors are likely partially motivated to not have devices updated in the first place.

So will Google make such a ballsy move? They themselves barely have good business reasons to do so. Android completely dominates the market anyway, without Google upsetting the politics amongst the vendors and pouring money into doing things that vendors refuse. It seems Android's bad reputation in regards to updates doesn't really hit anyone that hard.

Having said that, Project Treble does seem to be a move in that direction. Maybe Google cares enough about theirs and Android's reputation, or maybe they even care enough about being responsible. Maybe they'll make "Windows Update for Android" an opt-in thing for vendors. Maybe there are other ways they can create a more responsible market (and better repution for Android) without upsetting vendors. Let's hope they find a way at least.

> Android's bad reputation in regards to updates doesn't really hit anyone that hard.

I think this is an issue for Google when they want to introduce new platform features for developers, e.g. Project Tango. If updates take years to get to users, it handicaps Google's ability to be innovative.

There might be another way.

I heard from "Security Now" podcast that there is a new law that require all government purchased IOT devices must be update-able to fix security issue.

Expand the law a bit:

Make all internet connected device makers (Include phone maker) liable for any loss of private consumer info, hack for 10 years from any internet connected devices release.

Anyone can file lawsuit against them easily or in class actions against the vendor if they don't provide security fixed/upgrade within 4-6 months of from being notify of the vulnerability.

Establish an ISO security standard for IOT (and all Phone): such as

1) Standardize SW/FW update requirement, method and audit. ssl, security hash, CA, etc.

2) Requires system to monitor and log all program/critical system components creation/execution/all internet connection and download for auditing by owner of device.

3) Require system vendors to have source code / tools chain / build system in place to rebuild and fix security issues.

Once the vendors are liable for hack. They will need Insurance. The Insurance Company can follow the ISO security standard to audit and estimate the potential cost.

At least for companies rolling mostly stock Android, rather than the Samsung's of the world, Treble may well make it possible for them to simply forward what is coming from Google without the SoC source being an impediment. Something Google themselves were burned by when Qualcomm dropped support for the SoC used in a Nexus model, forcing Google to cut their support time short.

Android have been promising to finally tackle fragmentation in every release since KitKat. It seems people have a very short memory.

I think they did a great job at reducing fragmentation by pulling out most of the OS into upgradable components.

All applications are upgradable, even Play Services are upgradable, and developers get the support library to get all the new things to all devices.

So I believe they did a great job at reducing fragmentation in the sense that it no longer really matters what version you have, you still get all the newest stuff. Just look at every iOS version announcement: 3/4 of the new features are in the apps: iMessages, maps, home screen...

> by pulling out most of the OS into upgradable components.

That's not true (the most of the OS part). They untangled their own stuff (Play Store, Google services and so on) and can update those as they see fit. The OS stuff is still monolithic. Most of serious security issues still require full OS updates. Also supporting a new major version of Android runtime still require a full OS update.

Most security issues are handled by security updates, which don't require a letter update. They're issued as patches, so OEMs can issue them for an older device without updating it to a new release. https://www.android.com/security-center/monthly-security-upd...

They can, but most don't.

Most of the major OEMs do. The security update rate for upper tier phones runs about 75% within 3 months these days.

Anyway, I was responding to the comment "Most of serious security issues still require full OS updates." This is demonstrably inaccurate since the security patches do not require a full OS update.

And they have been, gradually. Treble is a relatively big step, comparatively, but it's not like it's the first thing they've done.

There's a reason that "new emoji" is a headline feature now, a lot of the system has been pulled out and is distributed seperately to the OS now so it doesn't have to go through the vendor's QA cycle.

While I agree with the skepticism because, frankly, Google can not be trusted to deliver on most product promises they make...

... they have gotten better at this.

Functional planned obsolescence. Hardware vendors will find a way to break hardware abstraction layers... so they can sell more hardware. Its the business model.

I bought a series of Nexus phones.

The Nexus 5 no longer works.

The Nexus 4 still works, but its battery is puffing out.

The Nexus S has no hardware problems at all, but it's too underpowered to run modern software.

The model "phone vendors nefariously build products with short lifespans, regardless of what people want to buy, so that they can sell more hardware" has trouble explaining why the longest-lived phones are the earliest ones. It seems more likely that the phone vendors of today build phones with short lifespans because bitter experience tells them that building a robust, long-lived phone is all cost and no benefit -- the phone costs more, it's heavier, it's fatter, and all your customers replace it before the cheaper, sleeker, more attractive phone would have failed anyway, meaning they actually get zero minutes of extended lifespan.

It's the same reason animals age and die.

> The model "phone vendors nefariously build products with short lifespans, regardless of what people want to buy, so that they can sell more hardware" has trouble explaining why the longest-lived phones are the earliest ones.

Maybe because first you try to make your earlier products good to get customers, and then once your business is going and you've grabbed a portion of the market you find it profitable to take risks like this?

This doesn't make any sense. It assumes there's no competition between manufacturers, and that users don't switch. If older phones were actually "better", manufacturers would just make those and steal customers from anyone making the newer devices.

The phones of today aren't "built with shorter lifespans in mind", but they are built with more tightly packed components, more energy-dense batteries (to support their power-hungry CPUs and large amount of RAM), etc. Because that's what you need to do so you're not "too underpowered to run modern software." Which is necessary to sell phones to people.

If you made a phone and said "hey, this will live as long as a Nexus S, but it's not going to run FB or Clash of Clans or VR or take very good pictures (HDR is compute intensive)".... good luck selling that.

Did you mean to respond to me? It seems like we agree, but this is basically how I would have responded to throwaway613834.

You're right. mis-replied in the thread.

My phone did died too (Nexus 6P). This doesn't mean all Nexus phones will die within opening the box.

I am still using my Nexus 4 from 2012, the only issue with it is that I don't get any upgrades anymore

> It's the same reason animals age and die.

With the difference that younger (newer) animals are better built. :-)

What difference?

The Nexus S appears to be immortal. That means that when young, it was terrible (by modern standards), and now that it's old, it's still terrible, but no worse.

The Nexus 5 is mortal. When young, it is good. When old, it is even worse than an old Nexus S. Just like an animal, it's strong in youth and decrepit in age.

I think most 50+ would disagree on this point... :-)

In the context of how much longer the item is likely to last, I expect I'll still agree even after I turn 50.

The code speaks for itself. Any Android implementation is now split in two halfs, one which is easily replaced and one which is not.

If vendors choose to not use this feature it is on them.

Actually since Google is still allowing customizations, it will hardly change anything.

They can impose whatever they want to OEMs who want to ship the Play Services and Google apps. That's pretty much all of them.

If they say "install it this way or no Play Store for you", every manufacturer will follow.

They almost certainly cannot do that in Europe at the moment given the regulatory situation. Indeed, I expect to see far fewer restrictions going forward, not more.

Why would they do that? Isn't Play Store the way Google monetizes android?

That is what I have been wishing for years, and yet they still choose not to do it.

Actually, this is not an allowed customization.

Then spend one hour of your life listening to ADB Podcast, where Android team explicitly states that, saying that they don't want to encumber the work of them creating unique experiences.


I sit next to Iliyan; I mentioned your comment to him and he chuckled.

That'd be a significant change to the Android license. AFAIK no such change has taken place.

So you'll still be vulnerable to kernel bugs but most everything else will get regular updates? A bit better I suppose.

Actually it also helps for this.

O standardize how HAL interfaces between the framework and the low level vendor implementation.

So you can update either, as long as the interface contract is respected, it should be transparent. It is of course more work for Google since the framework will need to keep supporting old version of this interface but that's a necessary evolution.

I think the idea is that you can update the HAL portion as well, and the system on top of it can be verified to have not problems with that HAL independently (and you can wait for that or or just update the HAL as available if you think it's important enough).

Since it's semantically versioned, you can theoretically have fairly high assurance of what updates might cause problems and what should purely fix a bug that doesn't affect normal functionality.

Have we reinvented Windows CE yet?

"WiFi Assistant

Auto-connects you to high quality open WiFi and secures your connection with a VPN back to Google."

Let's hope the VPN can be set to non-Google too, or it's optional or opt-out feature.

You can already have an always-on third party VPN that has nothing to do with Google.

This is just a feature that was on some phones that's rolled out to the base OS now. It's opt in AFAICR, there's a prompt to enable it when you first boot the phone.

It's not when you first boot, it's when you first connect to an unsecured public wifi network. the opt-in is per-network, not just a single opt-in.

and it's not rolled into the base OS either, it's part of "google connectivity services" which is distributed separately.

As someone who knows nothing about this, I wonder (and hope) if this is helpful for UBPorts/Halium.

https://ubports.com/ https://halium.org/

Intuitively, it seems that it would be since it provides a HAL that these projects can target.

huh .. I always suspected Fuchsia/Magenta were going to be a basis for Android going forward to get around the fragmentation situation. They still could be in the future, since no one is really sure what they're being developed for.

i haven't read up on fuchsia/magenta too much yet, but my impression is that it's going to be a much larger shift in general.

If Google can take some less drastic strides to fix this problem before a huge change like fuchsia, theres probably a better chance for an easy(er) transition.

There cannot exist an easy transition because they are completely different,

Java/Kotlin/C++ vs Dart for user space, Linux vs Magenta for the kernel and drivers.

this is why I should stop commenting I stuff I haven't gotten super familiar with. I didn't know Dart was the choice for user space. I suppose they could theoretically include an compatibility layer for java/kotlin userspace apps, but that seems like a lot of baggage depending on what the real goal is.

Project Treble is the most important thing in this release

>The biggest change to the foundations of Android to date: a modular architecture that makes it easier and faster for hardware makers to deliver Android updates.

With any luck, this will end the huge security/update problem Android has. Right now an update is dependent on the chip manufacturer's drivers, then the OEM adding them to the ROM with their custom "improvements", and finally the carrier pushing the update to devices. Right now it just takes one break in the link and a device goes without updates, which is a security disaster. If Google can push updates from the Play Store (presumably the end goal of Treble), none of this will be a problem.

I remember many years ago when a few carrier and chipset execs stood up on Google I/O stage and announced a new program to ensure Android devices get updated quicker. Nothing came out of that.

The proof here will be when they ship.

Thankfully, 'Google Play Services' and distributing more and more services through the Play Store is a step in the right direction.

> I remember many years ago when a few carrier and chipset execs stood up on Google I/O stage and announced a new program to ensure Android devices get updated quicker. Nothing came out of that

Google remembers that too, and this change allows Google to bypass those same execs when pushing out updates. The HAL layer will not change from version to version, meaning no driver support will be required from the OEM for new Android versions.

They were supposed to not put any user app on the system partition but rather install them using play services when the user logs in. I've only seen one device implement it and it was a low end device so it kind of choked anyway.

I've seen plenty of devices implement this. Of course, they were all ones I'd flashed with CyanogenMod...

> Thankfully, 'Google Play Services' and distributing more and more services through the Play Store is a step in the right direction.

A move towards replacing an open OS with an entirely proprietary solution full of tracking by a single vendor is "a step in the right direction"?

There's thousands of solutions for how you can update core OS components, none of them require what Google's doing to open source.

Look, the reality of the market is that most people are a lot more concerned about getting timely (security) updates than an 'open source' mobile OS.

Good point. However, that's a short term benefit at the cost of long term is what we should all remember

Wow! This implication to open source software is largely overlooked in the discussions here. Good catch.

>There's thousands of solutions

Yes, but only if you declare the business models of everyone involved a non-goal.

You can still have a Google-branded version of the same product that provides additional, Google-only features.

An open core business model was always what Android was like, but now the opem core is shrinking with every further commit.

All true, but what does that tell us about any solutions to slow or non-existant updates and fragmentation? What are some of the thousands of solutions? Or are you saying that there never was a problem in the first place?

The issue: apps that are only updated with the OS end up outdated.

The current solution: Move them out of AOSP, into Google's internal projects, distribute updates via the Play Store.

An alternative solution: Move them out of AOSP, onto GitHub, distribute updates via the Play Store.

Yes, Google had to decouple them from AOSP. But that’s no reason not to put the code anywhere else in the open. These issues are entirely orthogonal, and Google uses it as a way to force more people onto the proprietary ones.

Open sourcing Google's apps is not a solution to Android's core problems though. Not every part of the OS that needs to be updated can be moved into open sourced apps.

Also, open sourcing the apps takes away any leverage Google has to recoup the costs of developing Android.

All the apps were open source in the first place. Google Music, Books, Search, the Phone Dialer, the contacts, the SMS app, Google Talk, all of them used to be open source.

This all worked in the past.

No it hasn't worked in the past if we're talking about the problem of fragmentation and timely updates.

It should have been possible for Google to open up much of what they are pushing, but they don't. And i wonder if that has to do with the likes of Amazon and Xiaomi.

As an Android developer this is a big pain in the arse if you intend to develop apps using google apis.

The development is easier, but if you plan to distribute on other stores, google play services are useless and will make your development more time consuming as they are exclusive to devices with google play store.

Or even if just gets the chip manufacturers out of the equation, that alone fixes most of the problems.

The OEM side is usually pretty easy / trivial in comparison. And there are a number of OEMs who would happily push updates but can't, because they can't get hardware packages from Qualcomm / Amlogic / Freescale / etc.

That, more than anything else, holds back new Android releases on lots of hardware.

Supposedly the carriers are real pains as well. I've heard horror stories of months-long approvals processes on Verizon and AT&T ROMs.

It's a game I wish they'd get out of entirely. There's no such thing as a useful carrier overlay.

> I've heard horror stories of months-long approvals processes on Verizon and AT&T ROMs.

Six months and counting, waiting for Verizon to approve the Nougat update on my HTC One M9. It has literally hit everyone else:






Verizon is the Comcast of wireless. The next omen of the apocalypse will be when the Trump administration approves their merger.

Good thing their lawyer literally runs the FCC. They also have the best coverage, also like Comcast. Unlike Comcast, however, you don't have to get Verizon depending on where you live.

Verizon wireless being evil is exactly why I stuck with T-Mobile for such a long time even as they keep making billing "mistakes" to the tune of about ten dollars every month for a while. (I believe they're just supremely incompetent but the errors somehow always are to their benefit.) With Verizon or Cingular, I assume it is just pure malice.

I've talked to people about how Verizon is trying to use its network as an advantage for advertising with supercookies and such on one end and Yahoo!/Aol on the other end but it seems to alarm nobody.

Can I ask what some examples of these "mistakes" are?

P.S. also, was Cingular a joke about AT&T? I think I missed what the joke is...

Two in particular.

1. Cramming https://arstechnica.com/tech-policy/2014/12/t-mobile-gives-u...

2. They had a "free for life" 200MB? data plan for the Nexus 7 tablet kept billing me every month. It was a monthly ritual for about six months. Call, explain, get adjusted.

Huh, I see, thanks for mentioning this! I'll have to let people know to watch out...

Honestly, even after years of following Android, I still don't understand what the carriers even do to the ROMs. It's not like it needs special proprietary software tweaks just to connect to an ordinary GSM band. And it's also not like I get any kind of visual voicemail, WiFi calling, etc baked directly into the system either. Those carrier features are usually still separate apps, anyway.

Honestly, what are they doing, and why does it take them multiple months to do it?

Carriers generally have deals with other companies for preinstalled apps which may or may not still be active by the time it comes around for an update. Also they have to test the devices, but considering the sheer number of Android devices they probably prioritize new high end devices first.

This problem is made worse on Verizon and Sprint which use CDMA 3G networks, as opposed to the worldwide GSM standard.

Also this could be a result of marketing as well. You can get the latest Android on a new device, or you can wait an indeterminate amount of time (a few months to never) to get a free update on your old device.

> Also they have to test the devices

Why? The whole point of GSM is that carrier and phone can (and should) be entirely disconnected, decoupled and only connected through the means of whatever SIM the user puts in his phone.

The notion that a carrier needs to be involved in the making of a phone makes about as much sense as if my ISP needed to test and "approve" what Ethernet hardware I use at home.

It's frankly none of their business.

> This problem is made worse on Verizon and Sprint which use CDMA

So don't use them, just like you wouldn't use an ISP which doesn't speak IP.

Pretty much any argument for network/device tie-in is fallacious on its face for the simple reason that there are many countries out there which don't have that arrangement. And yet the phones there work fine, and so do the networks.

It is none of their business, but they desperately want a piece of the pie so they brand their phones (and probably sell them at a small discount - this is the value proposition here). Branding also results in shifting responsibilities from OEM manufacturer to carrier with regard to testing and stuff.

Also, plenty ISPs actually do sell branded wireless routers with branded firmware, so it's not uncommon practice in other neighboring industries.

This is about cost: updates sometimes fail (incredible, I know), and carriers are the first place people go to get their phones back in working order. This kind of support is quite costly so carriers don't push too hard for updates to happen.

Every fifth security vulnerability in Android should cause the radio to spam reconnect attempts or similarly onorous behavior.

I imagine carrier responses would look a lot different then.

> carriers are the first place people go to get their phones back in working order

That only applies to phone bought from carriers.

Most people buy them in electronic shops where they buy tvs and laptops and stuff (since that allows you to get the best deal any carrier can offer, and not just be restricted to one).

This is half true and I think it falls neatly along generational lines, with exceptions for "really good deals". Most iPhone owners became first time AT&T customers when the iPhone came out. When Android hit the market, people went to their carrier because before this more or less was how you had to do it.

More people are just buying whatever phone and sticking a simcard in it but there is still a huge number who live by what their carrier gives them.

> More people are just buying whatever phone and sticking a simcard in it but there is still a huge number who live by what their carrier gives them.

Interestingly enough I see that as the wrong way around.

Going to a carrier specific-store is also guaranteed to offered me inferior choice both in phones and subscriptions. What's in it for me as a customer?

My electronic store is giving me the phone and carrier which provides me with the best deal. I have no reason to give a carrier, a transparent transport network, any sort of loyalty.

I don't have a "my carrier" which I care about. I do however have a "my phone", and I care about that deeply.

They want you renting a new phone from them every year. Dragging their feet on updates shifts sales to their newer lineup.

But if a carrier has the nerve to actually block updates to my phone and I find out, I'll switch my phone to another carrier the next day.

What's in it for them?

Most people don't think about such things when buying (renting) a new phone. If you do consider it, you're an exception to the rule.

What do you mean rent?

I buy my phone. It's mine. I can put it on any network I like.

You certainly can't put whatever software on it that you like. They go well out of their way to ensure that.

Carriers are a red herring. The world at large couldn't care less about how the customers of AT&T can supposedly only install AT&T-approved firmware. Most people can, but they're not seeing any updates.

Google needs to fix their upgrade story. Even if the North American customers continued to run old vulnerable versions forever, updating everyone else's systems would be a tremendous improvement. (It would also make it difficult for the US carriers to continue those particular business shenanigans.)

Do you have any facts to back this up?

Prior to the iPhone changing how phones were sold-- carriers meddled with everything so they could get their hands in media playback, app sales, feature upgrades etc. I don't think much has changed in this where anyone gives them an inch (which is nearly everyone but Apple).

Note: I worked for T-Mobile for four years prior and a little after the originals iphone came out.

Facts to backup what? That most mobile phone users are outside the US? Or that most of the world buys phones in home electronics stores, not from their carrier?

The iPhone brought a bit of the outside world to the US telco market. This was only a matter of time, as the market becomes more globalized there is increasing competition in the consumer market, and carrier bound phones are less flexible and more expensive in the long run. Everybody knows this.

(I believe that even the US broadband market sooner or later will transformed in much the same way. For a long time it looked like Google was about to do it, but with that seemingly stalled for the time being we might have to wait a few more years.)

It is not reasonable to describe the iPhone as changing how phones were sold outside of a select few countries. Therefore we should not accept that explanation as to why Android phones do not receieve updates either. Those markets are small on a global scale, especially for Android which clearly dominates the lower end of the market, which is predominantly deregulated.

Funny, i felt that the iPhone brought the US mobile market crapfest to the world. Especially when i watched Apple play favorites with what operator in my country, down to dictating the style of plans the iPhone could be combined with.

Where I lived it was common before the iPhone for people to go to electronics stores or carrier-agnostic "phone stores" to buy their phones. You could get an unmolested phone on subsidy/contract and everything. This was in Europe though, where cheap prepaid SIMs for young people and MVNOs were already very popular.


You would walk in, and find a wall of phones, alongside a list of carrier plans.

Then you could pretty much mix and match plan and phone to find some price you were comfortable with.

Come the iPhone's "worldwide" launch however Apple sat down and insisted that only one carrier would get the iPhone, and defined in detail the kinds of plans that said carrier could offer.

Before the iPhone, how prevalent were software updates to phones? I know of no one who ever got had an update.

There is absolutely no reason for carriers to need to do anything at all, else it would not make sense that I can change the SIM card out and voila I’m on a new carrier. The manufacturer is the one doing the testing, and the carrier simply provides the infrastructure.

I feel US perhaps has a different experience, because of their ridiculous CDMA infrastructure. Is it Verizon or what, where it’s not a SIM card but the phone itself that’s setup to a specific carrier?

Nokia had firmware updates, but only technically savy people would do them.

It was done via the desktop application to manage the phone.

However one would ususally only get bug fixes on the Series 30 and 40.

On Symbian towards the end of it, there were some OS updates still, but usually only once.

By the time iPhone hit, Nokia were doing over the air updating on their more recent models.

And Nokia was not alone, my Sony Ericsson C702 were capable of being getting new firmware OTA as well.

Keep in mind that this was back with the original iPhone that needed to be wired to a computer with iTunes installed.

Frankly the iPhone introduction feels more of a rollback than a upgrade from non-American point of view.

I only started using around Android 2.3 time frame, because I held to my trusty Symbian until it died on me, by then Nokia was already showing signs of not being sure what to do after Belle.

Belle already had lots of features that took Android and iPhone years to catch up with.

Nokia were sadly caught in a innovators dilemma.

they had Maemo, they had Symbian. But they were afraid that focusing on Maemo would lead to Symbian dying before they could get Maemo to the same level.

And then boardroom meddling was added, and they went much the same way as HP...

It's not just just Verizon. AT&T, in particular, has a habit of locking important features (VoLTE, Wi-Fi Calling) to phones running AT&T-branded and certified software. So unless the device you want is sold by AT&T and you get the AT&T-branded version, you're SoL. They even do IMEI blocking, so even if your device could otherwise work...

I have the impression that Nokia had trouble getting into the US market because they refused to let US carriers modify phone firmware to disable features.

In particular when Nokia tried to introduce SIP support.

Sony Ericsson's non-smart phones (e.g. K800) had OTA software updates. They would pop up a dialog from time to remind you to check for updates, then download them and update, all on the phone. (Carriers would often hold them back, though, if you had a carrier-customized model.)

I'm pretty sure I got an actual update at least once.

Near the end of the dumbphone era I remember getting an OTA update to mine that added a chat-style view to SMS text messaging. I don't think the iPhone would even get OTA updates for years, it was all purely through iTunes.


Both Nokia and Sony Ericsson were doing OTA firmware updates at that point, for "featurephones" no less.

iPhone didn't get that ability until iOS5, in 2011.

My Nokia 5800 went through several UI redesigns via OTA updates.

True. That's a totally different problem that Treble isn't intended to address, as far as I'm aware.

Probably because they have to test the ROMs on their network in different regions, with different frequency bands, with roaming, etc. That work is tedious given all of the phones they support.

Do they do all this testing for all GSM phones in the world? All new and old? All GSM phones ever sold?

I guess not. I guess instead they rely on the GSM specification to allow seamless independence between the phone and the carrier for 99.999% of the phones out there (if not more).

So why do they need to "test" the remaining 0.001% when they have a update in user-facing functionality the carrier will never see or interoperate against?

No carrier in Europe does this.

Does your ISP control what OS updates you can download? No. And why should they?

That carriers needs to do testing is a lie perpetuated to allow for customer-hostile business-practices. Stop repeating it.

Err... all carriers in Europe do this.

It happens with Apple OS updates too, Apple just have sufficient market clout to tell networks they must complete the testing in the week between the gold master release and the public release.

GSM isn't some magic specification. It's entirely possible for a crappy radio firmware to cause significant disruption to a network it connects to (indeed, I've seen a pre-release firmware from a mid-tier Android manufacturer that managed to cause a reboot in every cell tower it connected to from one of the UK's networks). That's an extreme example, but carriers frequently do testing on that basis, and it often holds up the European releases of Android software updates.

Resources are finite. I don't know what your point is? That they should simply give up and do nothing?

>That carriers needs to do testing is a lie perpetuated to allow for customer-hostile business-practices. Stop repeating it.

Other than your opinion, what evidence do you have that this is a lie?

All of Europe? Where GSM was invented?

This kind of bullshit only happens in the US where carriers are free to bullshit as they like due to absolutely lacking regulation.

In Europe we know better, we do better.

I'd rather say the burden of evidence is on the other side of the argument: prove to me why do you need to do testing as a carrier.

>I'd rather say the burden of evidence is on the other side of the argument: prove to me why do you need to do testing as a carrier.

And yet you make absurd claims without evidence yourself. So because you're confused as to the reason, that makes them a liar.. Nice.

The iPhone doesn't suffer from this problem. It should be up to the phone manufacturer (HTC, Samsung, etc.) to test their product.

The carrier can still, of course, test the new firmware all they like - they just shouldn't be able to interfere with its release.

The iPhone doesn't suffer from this problem. It should be up to the phone manufacturer (HTC, Samsung, etc.) to test their product.

Moreover, in some European countries it is normal to buy a phone and a subscription separately. In some countries bundling is even illegal. I have never had a carrier-branded phone since I switched to smartphones, including my Android excursion (Nexus 4, Moto X 2013, Moto G, Moto X 2014) and some Windows Phones that I played with (Lumia 710/920/640). They all worked on multiple carriers.

Everyone should stop perpetuating the carrier testing myth. For this we have the GSM standards and in many parts of the world a large number of phones are not carrier-branded.

TBF, Apple did release one update that caused issues with the radio on the Verizon network[0]. Carrier testing should have caught that.

[0] https://www.theverge.com/2016/10/17/13306776/apple-iphone-7-...

Apple makes products available to carriers pre-launch for testing IIRC. I don't think they skip the line.

They certainly have the market power to skip the line, but they still go in the line, unlike some suggestions here.

Good thing they don't have to test these iPhones!

They do. Apple makes them available to carriers pre-launch IIRC.

Probably, but they won't delay the launch for months if the carriers drag their feet

The carriers are not the problem. They may be an additional problem but even when they aren't involved (i.e. outside America) Android updates still suck.

God, this can't come soon enough. It's awful out there. Even manufacturers that promise updates don't come through (ahem, HTC, ahem).

Verizon especially makes it miserable. Ah, but who am I kidding, I'm sure Verizon will still find a way to ruin it.

And even then, in the US HTC rolled out a recent update for the HTC 10, while we're still on the January patches in the EU (and the rest of the world).

As I commented in another HN story, I don't believe OEMs and telecom operators will release updates, if Google doesn't force them to do so.

They already admitted on the ADB Podcast that they don't want to remove the ability for OEMs and mobile operators to customize their forks of Android.

We will still be forced to buy new devices even if they are VTS certified.

> VTS certified

If it passed VTS it should be able to run AOSP. The new CTS will be an AOSP System image running their VTS passing "drivers".

Even if your vendor doesn't push any updates. At least you should be able to run a number of newer versions of AOSP as long as Android doesn't deprecate those VTS drivers.

Providing your bootloader can be unlocked, of course.

You've said this in a few different places, do you have a source for that? You are saying you could load AOSP on an S9 regardless of what Samsung does?

If so, this is indeed huge, but I have some serious doubts about it, perhaps because I have felt so very burned by Android so many times in this respect on anything but Nexus devices.

Maybe - the bootloader must allow you to run that AOSP ROM, which only is possible if the bootloader isn't locked. Lots of OEM:s lock their bootloaders. But otherwise, yes, there's nothing else stopping you.

There are a bunch of things potentially stopping you in practice. The HAL isn't a total wall, and I expect to see many OEMs go around it in some places, either due to incompetence, the HAL being inflexible, or timescales.

So even in situations where you can install such a ROM, there's very little guarantee key bits of hardware will operate properly. Any non-standard hardware/hardware feature is also fairly likely to break.

Usually common users don't flash their devices and that is what matters for the Android dashboard.

How in practice would you go about putting AOSP on a device without the vendor cooperating? Is there some kind of secure boot system that always accepts AOSP images?

I think the idea is that they cooperate once, and then Google promises to stop breaking the HAL interface for x years at the cost of increasing their development difficulty.

You would still have to jump through hoops to boot a new ROM, but when you did it would actually work rather than having some drivers missing.

The sad thing is that it shouldn't be on Google to force them. It should be Google to enable them and the users to "force" them.

They have argably been enabled for a while, but Treble is making it even easier. Hopefully this pushes the needle over the line for at least some OEMs/teclos.

In Germany there are quite a few stores still selling budget Android 4.4 and 5.1 devices, which people keep on buying.

Same is in Bulgaria. And when you ask them "Hey actual version is 7.0. Why you use outdated OS with vulnerability? How you buy that devices?" They told "I have seen 7.0 there was nothing new."

But no one want to get computer with Windows 95 (or 98) anymore. Just Android 4.4 is "OK".

There are no cheap windows 95 computers where everything works on the market. Android 4.4 does do everything people need (like running whatsapp), and the devices are out there to buy.

Security vulnerabilities? Nobody was ever affected by those (at least in the social circles of the people buying the devices), so why should they care?

Tons of sites full of "amateur porn" think you shouldn't worry either. Who cares if all of your pictures are freely available to anyone on the planet, right?

> But no one want to get computer with Windows 95 (or 98) anymore. Just Android 4.4 is "OK".

They should do a yearly release (eg. Android 2018). Then at the store when they display phones, they'd have to write "Android 2013" instead of "Android 4.4 KitKat."

Doing yearly releases is such an obviously great idea that there must be a big reason why they are NOT doing it.

In the UK last year, I bought a Samsung android tablet for the kid (my first Android device). It was running 4 and I ass7med Samsung would have an upgrade available. Ha! No chance.

You can get a Nougat device for as low as Rs 3500($55) in India. Which would be considered low end mobile.

It seems people have made their choice they don't care. If they cared about updates they wouldn't be buying Android.

You're thinking like a technical person. Aunt Susan doesn't know her phone is an Android phone. In her mind, it's a Samsung phone. It's not a question of not caring, she simply doesn't know.

There is such a thing as not knowing because you don't care, and I wouldn't even say that it's irrational. There's simply too much to know and care about in the world, so you have to be selective and event driven.

Some of them do care, but with an average salary of 500 euros or less, they have better things to do with the money than spending on iPhones.

The only viable alternative was Windows Phone, but that is gone now.

That is very true, and I have to say it's disappointing and baffling how Microsoft dropped the ball on this one.

Microsoft are the only ones who ever managed to make the separation between OS vendor and hardware vendors work (at least on the PC side). They are sorely missed in the mobile space.

They didn't choose, they just didn't know.

This is why software/hardware needs best before dates.

I agree. There are two parts to the Android update problem. I'd wager OEMs having no motivation to release updates is bigger than them having no ability.

I completely agree. It's good they broke it apart to make updates, in theory, easier but after working for a company that modified software that was delivered to them and then reshipped elsewhere it really never mattered how module the original was; the updates still go through the same channels, testing, etc and the OEMs will likely want to modify things not as cleanly separated (an API design never passes its production usage without warts).

I doubt we'll see much change. I hope it'll make it slightly faster but without an agreement with OEMs that has teeth forcing them to be more expedient I can't see this getting much better.

Except, of course, getting your hands on a phone that has Oreo.

For instance, the Galaxy S8 is the hottest new thing on the market right now, and it launched with Nougat. It will probably be six months to a year before Samsung pushes an Oreo update to it, if at all.

Samsung actually has a decent track record of updating their software -- my family's Galaxy S5s on T-Mobile (purchased 2014) are actually still receiving security updates, despite being on Marshmallow API level.

Only on the S series, the other ones is a guessing game.

well, he did use an S8 as an example.

Honestly though, I think all of the company use the same strategy. Only the flagship line is the one getting extended support for update

You kidding me right?

They literally didn't update note tablets once!

There was an implied "in my experience" on that. My family has used S-series devices, and those have generally gotten prompt security updates.

Do those security updates also include kernel vulnerabilities?

LineageOS is the cure to all ills.

It doesn't help with things like firmware vulnerabilities (without some extensive reverse engineering). I can get LineageOS on my Nexus 5 just fine, but it doesn't have broadpwn fixed.

(note that I wasn't able to actually replicate broadpwn on Nexus 5, if anyone was, some info would be appreciated)

I'm cautiously optimistic about Treble. I welcome userland updates not being subject to device/soc manufacturers whims, but wonder if this means devices will see kernel updates even less frequently than they already do.

Then again, this new architecture likely makes it easier to move the Android userland to a new (non-linux) kernel, so maybe it'll be a moot point.

It is nice to see the updated Bluetooth 5 stack as a feature of Treble

That's good, but I really, really want to set the Supervision timeout to something other than a rudiculous 20 seconds:


Why do you think so? On that page is just this sentence and nothing more. I don't believe in a significant improvment unless Google takes ownership of all OS updates themselves.

Treble is the first step to Google updating devices themselves. Now that drivers are more or less independent from the rest of the operating system, Google has the option to push updates to the OS without having to tailor it specifically for every device

Every time I seriously consider the Android platform, I hear about this kind of shortcoming and I'm immediately turned off. I want to buy a phone, not a carrier. This fragmentation per device/carrier is killing this amazing platform. They need to lock it down Apple style (at least for phones).

Not saying that everything else is bad, but one thing that strikes me is how much they have run out of interesting things now that they had to use fillers[1] like:


Support for tooltips (small popup windows with descriptive text) for views and menu items.

Normally, this would be relegated to a git changelog in the support library. But this is on the global marketing landing page.

I like to imagine a fictional internal mail thread going like this:

> Folks! please, give us something, anything, to put on the landing page!

> Someone replies duh, maybe tooltips

> What's a tooltip?

> uhh, small popup windows with descriptive text

> What's a popup window?

> uhh...

> Nevermind, its on!

Obligatory /s and yeah its Google, but seriously I can't imagine any other circumstances on how this specific copy, which tries to explain what a "tooltip" is by using the words "popup window", "view" and "menu item", came up.

This could be a good sign though, of the maturity of the platform (and harder to feel left out if you didn't upgrade).

1: https://www.android.com/versions/oreo-8-0/

To be fair, I have an iPhone and I'm still waiting for the "remotely sane text selection" feature to ship. Just in case you think this is hyperbole: https://www.youtube.com/watch?v=YhWz7rMj56Y

So it's not just me? I thought I must be doing something wrong between all these people talking about using their iPads as their main work machines and then text selection just doesn't work for me most of the time.

I really wonder what's going on here.

That is nuts. I had no idea such a basic feature was so broken on the iPhone.

Pretty horrible indeed, though limited mostly to Safari (which incidentally is one of the places you want to use it more often than in others in my experience)

I just tried the 7+'s text selection and it works great unlike in that video.

Good to know. This is probably my biggest frustration with the iPhone. Any interaction with text is miserable, and it has been forever. Somehow Apple has not seemed to care for 6 generations.

I think a lot of major changes are in Google's apps, not Android itself. For example a big update to the Photos app would be part of a major OS update in iOS but just another regular app update on Android.


That is one of the big things that annoy me when i hear people talk about iOS updates.

Because when Apple announce their big updates, often the items they present will not be present on older devices for various "reasons".

Thus what most people got where perhaps some security updates and some spurious API changes so that all those apps have to be updated or stop working.

Apple, during Jobs both terms, were more marketing than anything. Watch them slowly slide back into 90s mediocrity outside of USA now that he is no longer around to apply his "reality distortion field".

I'd imagine there are a lot of performance updates which would be too technical for the marketing page, so they filled the space with minor enhancements instead

Noticed the same but for a different item in the changelog. "TextView autosizing" - it's such a minor thing and could well be a minor changelog item in the support library update..

That actually got some decent cheers at Google I/O iirc, it's bigger than it sounds at first. It's scaling the font size of the text to fit the available space, which is a fairly unique twist and is great for localization efforts (looking at you, German...)

Don't get me wrong, the feature itself is indeed useful.

It's just that its so.. minor. If you ever wanted to implement this in your app then there are multiple ready-made solutions for this or you could write your own in a short amount of time. Presenting this as one of the key new features in a major new OS versions seems just strange.. like there wasn't anything else substantial.

It's really hard to do well, and in a performant manner. I'm glad they built it.

Measuring glyphs, dealing with reflow, kerning, whitespace breaking rules, etc is no fun

Not only that but would non Android developers even understand the feature?

I imagine there are plenty of instances where apps do not account for space well

Frankly i get the feel that most apps don't care.

They develop for a certain size and resolution, maybe what is currently on the Samsung flagship, and if it also work outside of that box they are happy. And if not they simply flag it as not supported in the Play store.

Android has had from day one all manner of capabilities for fitting a UI to different devices. But still i run into UIs that seems fixed in some manner because of some Photoshop designer with a chip on their shoulder.

> Photoshop designer with a chip on their shoulder.

I think you are attributing malice to something where laziness would be an easier explanation. As an occasional Android dev, I know the laziness problem all too well when trying to get UI to fit multiple devices.

That got some internal cheers in my company(s Android team) as well.

At least they are bringing back PIP. This was such a great regression in N for Samsung users.

PIP somewhat exists already. Some apps, like tinycam already do it.

That's an overlay, rather than using windowing features. And they don't scale quite the same way into full-screen apps. This ought to be easier to implement for most apps since Android itself handles most of the window management and since rendering shouldn't change too much.

You had to scroll past quite a few animated announcements and read past several lines of other updates in order to find this 'also-ran' item in the footnote.

How do tooltips even work on a touch based OS?

Chrome OS has first class support for Android apps nowadays. You can use a keyboard and mouse through USB OTG or Bluetooth on an Android as well.

Something that has been with Android since 3.0.

Really wish i could find an android tablet with a full size A port these days that didn't run a ancient version...

Android has long has deep support for keyboard and mouse navigation where this could be more useful.

Indeed. It is one of those things that seems to go unspoken of, because even Google don't want to acknowledge that they once tried to pitch Android as more than a media consumption platform (Android 3.0, aka honeycomb, aka the tablet/landscape focused Android variant).

Which lead to the situation that although Windows Phone failed in the market, Windows 10 seems to be on good track to win the hybrid tablets market.

All the consumer stores on my city have mostly Windows 10 hybrid laptops on sale, with the exception of a few Samsung and Huawei ones with Android.

In particular as Microsoft has waved the license on smaller screens.

The other day i found a 10" tablet with a keyboard dock and no less than two A ports on the tablet part.

I am presently contemplating grabbing one to use with a RTLSDR dongle i picked up on a lark.

In android it works right now on the app toolbar with a long touch of a button for which you want to see the tooltip (if it is programmed right). The text shows up sort of like a toast message.

Devices with a stylus (like the Galaxy Note series) can use it by hovering on the element.

Speaking of the note series, I wonder if the note 8 will ship with Oreo and if so how well it keeps the treble stuff.


The only place I can recall using tooltips (if I understand what you're referring to) on iOS is to read the extra caption on XCKD (the title attribute of the img element), which you access by press and hold.

Just put LineageOS on my Note 3 and it turns out the touch screen is sensitive enough to implement a "Touchscreen hovering" feature.

Dunno exactly what they are referring to, but on Fragment UIs one can tap and hold on buttons to get a small popup/tooltip.

Honestly, I prefer this over the popular alternative of making UX changes for the sake of adding something new.

I'd probably give most places the benefit of the doubt — companies will rarely make UX or UI changes just because. There's usually a problem they are aiming to solve, and the solution they choose is some sort of interaction. Is it always the right answer? That's up to the users.

Raymond Chen (core Windows engineer) once explained in his book that some UI changes are near-mandatory (at least for paid product) for most people to feel that the upgrade is/was worth it.

Say the engineers have done massive internal performance and stability improvements, better filesystem and what not; but those things are almost invisible to regular users. Most users want something more tangible, otherwise they will have hard time to justify spending few hundred bucks as they will feel "it's the same as before, I see no difference".

It's also (my theory) a bit of identity thing. All big companies slightly tweak their logo (even if it's just changing or removing shadow thickness) every decade or so that it feels fresh. The same applies to UI of applications and OSes.

And here i sit, using a WM that has not changed in ages...

Am I the only one who's really disappointed by the platform's shift in its stance on background execution? I was originally drawn to Android because it wasn't iOS. I wanted to develop on a platform where I could run a service in the background if the user wanted that. Apps that were bad stewards of battery life and phone resources were supposed to be scrutinized by users and removed if they were too poor. You can be a good steward, it's just harder especially when your monolithic app is an uninformed port of some legacy iOS code.

By issuing a hard restriction on background usage Google has brilliantly improved battery life for the masses while condonig the same lazy architectural patterns of the past, locked people into Firebase Cloud Messaging--a Google service not part of the AOSP, and potentially stunted Android adoption in domains outside of mobile. It's the turning of an era for Android, and my interests have moved elsewhere (from an app platform perspective, embedded Android is still vialble since everything you ship runs as a system app with no restrictions).

That might be good for power users, but for the average user it's a disaster. How many people actually read the app permissions when they install something? Most apps request background privileges and if you don't like that your only other option (until recently) was to not install the app.

Users blame Android when Facebook and other popular apps started eating all their battery by running in the background. Google's only choice was to aggressively punish these apps.

All developers think their app is the most important thing running on the user's system, and that is how we get into situations like this.

Yeah I understand why we're in this situation. I'm lamenting the fact that it's reached this point. Maybe I'm a minority but I don't think my apps are the hottest shit around and I try to make an effort to be a good steward. IMO engineers should push back when product asks for things that clobber system resources. However the few bad examples should not ruin it for the use cases where you really do need something running in the background. I also partly blame these DI solutions that encourage devs to stuff everything in a graph they do or don't realize is tied to their application instance. I've seen this multiple times in production apps.

What are these apps doing in the background? I've always assumed they're collecting/streaming device and user metrics. Running apps, location, WiFi SSIDs, etc. If that's the case, then a reduction in data collection could mean a reduction in metrics/income.

Its a mix of things.

Android by design leave apps in the background when you exit them via the home button.

Before 4.0 introduced the switcher button, and the accompanying swipe action to fully close an app, the only way to properly exit an app was to hit the back button until you exited back to the home screen.

This because the initial design of Android was less about apps and more about "activities". These were the individual parts of an app, and what enables that one app launch parts of another app to complete a user action (the most prominent likely being the share menu).

This was presented back in the day as a metaphorical stack of cards. As more user actions where taken that opened more activities, those activities would be added on top of the stack. Then as the user hit the back button he would be flipping backwards in that stack. To enable all this, Android keep apps around in RAM until it runs low, and then start to close down the oldest ones (first by waking them up and telling them to exit gracefully, then forcing them).

Thus often an app will sit in the background even though it is doing nothing.

One good way to observe this (until recently) was to run something like OSMonitor and look at CPU time of various app processes. Often they would be present but basically show no indication of actually doing anything. They would just sit there idle, waiting for user actions.

So make it an opt-in mode, just like sideloading apps.

Apps that were bad stewards of battery life and phone resources were supposed to be scrutinized by users

If HN allowed emoji in comments, I'd have a U+1F923 here. Since I can't do that, you're adorable. The users, eh? The users are supposed to be burdened with checking the wake status and radio activation schedule of their apps? How was that supposed to work, exactly?

I'm not sure what your point is here and your tone indicates you're not really looking for honest discussion. But FYI Android reports energy usage statistics to the user on a per-app basis. What I don't like is Android the platform telling me the user how my phone is best used. It's pretty crippling. Let's say I'm deploying Android on hardware that is always plugged in--something kiosk-style. Why shouldn't I be able to have an app that keep a persistent connection open to a network service for say real-time communication? You can't do that now.

And what about the mysterious Android OS/Android System "apps" that show up on the battery usage screen? How do I know which app is hogging resources here? Should we expect users to inspect wakelocks?

Blame shitty mobile developers who screwed the pooch on Android. Even if you avoid shovelware, the quality is abysmal.

My Android phone still randomly lights up its screen several times a day, without a new notification having come in. Reporting overall energy usage doesn't help me track down the culprit.

It's not like anyone's written apps for real work on these devices anyway. It's all just second class software.

And if Android itself didn't tell you enough, there were apps line OSMonitor that could give you more detail (at least until Google shitcanned the permissions that it relied on for "security" reasons).

You can disable "Battery Optimization" per app, so this isn't very restrictive. It just applies by default.

I'd like to do that, but when I 'exit' an app and/or swipe it off of the list of program cards I want it to ACTUALLY exit (at least within 30 seconds).

What if that app is say and open source messenger app that doesn't use GCM/FCM. For that to work you need to maintain a connection with a remote service. You don't need the UI hogging memory the whole time but you definitely want messages to come in immediately. IMO the system should offer a way to completely kill and app but "killing the UI" should not stop critical services utilized by the app.

Okay so maybe you could argue that if you never "swipe kill" the app it should be allowed to have background services executing much like e.g. Slack on macOS. But you can't even do that. Having your ui in the recent tasks list does not exempt you from background restriction.

There is a way to kill an app process, but it's in Setting and takes several clicks. I think it's for the best that killing isn't easier, because users don't generally know the implications of killing an app. In Square's Register app for example, force killing the process could prevent the app from uploading important payment data in a timely fashion.

You just don't know much about android dev it seems.

When an app gets put in the background it gets an event from the OS it's then the devs job to not keep everything loaded in the background but most don't.

> swipe it off of the list of program cards I want it to ACTUALLY exit

Swiping it away instantly kills the app unless it has a foreground service with an associated notification.

Elsewhere to what? What are you gonna do, run Windows Mobile?

I like native app development because it's not a browser. Android was the most honest manifestation of that on mobile (iOS is basically a "client OS"). I look towards domains where people are still putting powerful applications on connected hardware. Mobile is starting to look like a commodity web experience with half the history of JS, so why not just use that?

Point being the delta between what a native app and what a browser app can do has all but disappeared. BT and Graphics are the last few notable things and both will be supported by browsers soon (webgl already is and webbt is incoming). I'm not saying go use JS.. I very much do not enjoy it. Im asking why we need to build native when there's increasingly less to justify the overhead.

WebGL is a poor cousin of OpenGL 4.6.

Even comparing WebGL 2.0 to OpenGL ES 3.0, which it is based on, there are nice features like geometry shaders missing.

Nitpick: Geometry shaders came in GLES 3.2 (there was also a geometry shader extension for GLES 3.1).

In WebGL 2 you can still do geometry processing, and store results in buffers for subsequent draw calls, using transform feedback.

You are right, I mixed it up.

Like that idea for WebGL 2.0, will have a look into it.

At least in Android 7 you can explicitly allow this for a specific app. This question can even be triggered by the app itself (e.g. Conversations and Signal ask you to do this if they can't use GCM). This is hopefully still possible.

> It's the turning of an era for Android, and my interests have moved elsewhere (from an app platform perspective, embedded Android is still vialble since everything you ship runs as a system app with no restrictions).

Google making it more and more difficult to avoid gapps is nothing new.

There is some level of opt-out, but it doesn't work reliably, and your app might still get killed.

Even the K9 team had issues with that, and many other open apps did so, too. I've been trying to work some kind of push messaging into the IRC bouncer for which I wrote an Android client, but the issues with legality (I can't just connect to a third party without explicit opt in), API keys (people who host an IRC bouncer don't want to register with Google), liability (I don't want to relay all messages through a server of my own), Google's ToS (I can't just publish an API key for everyone to use), confidentiality (I can't actually put content into the FCM messages due to legal issues), etc are so problematic that it's basically stalled everything.

I've filed a complaint with the EU, this seems like the only option I've got left. I can't tell everyone running a bouncer to register with Google, I can't relay all messages of all IRC users through a server of mine, and I can't bake in a Google API key into IRC bouncers (as that violates Google's ToS)

Can you point me to the relevant info? This is news to me (and sounds exciting).

No doubt we've seen it coming for awhile. But I'm still sad to see it finally come to this, at least ideologically. iOS is a closed ecosystem that's been opening up. Android was an open ecosystem that's becoming more locked down.

[1] Seems to do the trick but I don't do Android dev so I don't know any details about this.

[1] https://github.com/siacs/Conversations/blob/2b9cdde558ed96c2...

I looked into this. It seems this is something that was added in M pertaining to Doze and App Stanby modes and is not related to the new O background execution limits (which apply generally). In any event, app exemptions must be approved by Google so we've already crossed the open platform line. They do list that voip-style/message apps will receive approval if they can't use FCM for some technical reason: https://developer.android.com/training/monitoring-device-sta...

What part of that page indicates that you can't use the platform like that? They just say "more control over how apps run in the background".

Presumably you can still give your users a good reason for why you need to run uninterrupted in the background and they can approve it similarly to how they now approve other permissions.

The way this is implemented is that the system will kill any background services your app has after a grace period, just like iOS. In order to have a background service that "good reason" equates to a persistent notification in the tray and icon in the status bar--which nobody agrees is a good product experience.

Why is that not a good experience? Now I need to dig through Settings to find all these background services. If they're important enough to be running constantly they're important enough to take up some space to prominently show me that they're running.

Yes, and you're okay with having 20 to 30 notifications at all times just to run open source apps, or would you say "this is too annoying, I'll switch back to the closed ones that spy on me".

If you want the open source products to win, they need to be able to provide the same usability as the proprietary solution. This is not possible here - you need Google's FCM or you get major disadvantages, and this is problematic.

I've filed a complaint with the EU, this seems like the only option I've got left. I can't tell everyone running a bouncer to register with Google, I can't relay all messages of all IRC users through a server of mine, and I can't bake in a Google API key into IRC bouncers (as that violates Google's ToS)

This doesn't inherently have anything to do with open source, but the problem that whatever license the apps on the phone are under they can't all be implementing their own push/pull message queue, having 30 open network connections constantly waking up the phone is going to drain the battery.

If I install 100 apps that have their own messaging implementation should the phone just not be showing that to me, even though my battery is now drained in half the time as a result? I'm pointing out that as a user this is very pertinent info to be showing me, if I have 30 apps running in the background I'd like to see it.

That’s a fallacy. I tested it, the battery impact is zero if properly implemented.

I implemented a prototype before, where I had a standardized protocol, and apps give the GCM library (I modified microG’s) a URL to connect to, and an auth token.

microG’s GCM library would keep all those sockets open, just as it does with the sockets for Google’s several cloud messaging services, and upon receiving a message, wake up the app.

As result, only one app runs in background, every app can use its own notification service, you have no battery loss, and you can keep everything open.

All this can work. Google just doesn’t want it to.

There are a few things here. From a technical level, how do you think GCM/FCM is implemented? A socket is hardly a scarce resource and keeping 2 open is only 1/65535 more "expensive" (from a kernel standpoint not power/energy) than multiplexing two streams on one connection. It's possible FCM uses some micro polling strategy so that the radio can sleep for short bursts, but I don't see why the same mechanism can't be exposed to other apps if that was the case.

Second, from a product level there is a double standard now. Apps that build infrastructure using Google's platform services don't have to put a persistent notification in front of users and clutter the phone ui. Apps that choose not to depend on google (the "open source" as it pertains here but you're right it's not limited to open source apps) do. That's a pretty obvious power play.

If you want to see all the stuff going on in the background why are things that buddy up with google exempt from that in your eyes? I could flood your phone with a high priority FCM message every 500ms effectively making my app run all the time and you wouldn't know. There will be apps that do it (as there are with APNS on iOS) and it is in fact far worse for battery life. Maybe we differ on this point but there are certainly things I want happening in the background that don't need a ui. That's the precedent on the desktop anyway.

BTW The ordering of FCM messages is not guaranteed so they're not even as useful as a TCP connection.

Has Google ever released a report on how much time it takes an average flagship device to get the latest android version? Even if you've paid $$$$ in getting Samsung Galaxy S8 just recently, you're not going to get Android O tomorrow morning. But that's definitely the case with iOS. That makes a huge difference in the world where Software updates play a huge role in performance and functionality than hardware update (read. Image processing vs 13Mp to 16Mp camera) Google hasn't been successful in that.

Just like you have to buy an Apple phone to get Apple updates immediately, you need to buy a Google phone to get Google updates immediately. Pixel and Nexus rollout is starting nowish (and beta participants are already getting the OTAs).

This is really not a secret at this time anymore and should be taken into account when you succumb to Samsung marketing.

Everybody else will be probably 4-6 months late.

But Apple supports iPhones for 4-5 years. Google has said they will only support their flagship Nexus and Pixel phones for no more than 2 years. For a $700 device this is unacceptable.

That's not entirely true:

Pixel phones get security updates for at least 3 years from when the device first became available on the Google Store, or at least 18 months from when the Google Store last sold the device, whichever is longer.


Apart from what Ironlink said below, there's also the fact that Google and Apple support mean different things.

For Apple, updates often mean some subset of the full operating system updates, or a crippled version.

Whereas Google updates tend to be all of nothing - meaning if your phone does get the update, it gets all of the features of that particular version.

This seems to have changed somewhat with moving a lot of the stuff to Play Service (and now obviously with Project Treble), so you get the best of both world (in theory)...

> For Apple, updates often mean some subset of the full operating system updates, or a crippled version. Whereas Google updates tend to be all of nothing - meaning if your phone does get the update, it gets all of the features of that particular version.

Eh? Aren't you swapping something here? On Apple you get OS updates with nearly all features for at least 5 years, of course they can't create a NFC device into a phone that doesn't ship with one... I would love to see _any_ Android phone with support for 5 years, that does not come from google directly. it would be a no brainer if something exists in the 200-300€ range. because I don't care which phone I have, it just needs to be long liveable and have a price below 400€. currently I use used iPhones, which I get relativly cheap.

I think he's pointing out a vital difference in update paradigms here. Taking an example of an update that added NFC processing to a phone, iOS devices would get the update even if NFC were the only feature in it and their device didn't support NFC (and that feature would just be turned off or "crippled"). Android users, on the other hand, just wouldn't get the update at all.

In reality, what we see is a bunch of features bundled together into a single update. If one of those features is NFC functionality, iOS phones will get that update minus NFC (and any other features their hardware doesn't support), while Android phones often just won't get that update at all if any of the features (e.g. NFC) aren't supported by the hardware. This also explains, in a basic sense, why iOS devices get updates for longer periods, while Android devices "fall off" or aren't promised updates for as long.

There's, of course, pros and cons to each of these update strategies, as many times it becomes "mandatory" to update (for security updates, to get maintenance/support, to get some other necessary features, etc), and iOS-style updates have historically been too much for device memory/processing/resources to handle (effectively making the phone so slow you're required to buy a new one[1]), while Androids not getting the update at all also requires you to buy a new one.

Neither approach is foolproof, but I think that's what he's referring to by "Google updates tend to be all or nothing" and "Apple updates often mean some subset of the full operating system updates, or a crippled version".

[1] There's enough resources out there that no single one tells the whole story, but there's plenty at https://www.google.me/search?q=ios+update+made+phone+unusabl... and at least one previous class action lawsuit over iOS updates rendering phones "inoperably slow".

No, Apple updates include the full operating system update. The only time features are disabled is when they require hardware that doesn't exist (e.g. you have no finger print reader so you can't use your finger print reader) or they are too intensive for the phones CPU/GPU. That's it. Apple's propensity for hardware accelerators may make this seem like it's crippling (Eg: there is a voice recognition hardware accelerator on Apple CPUs, IIRC) and people may not know why, but Apple does not use crippling software as a strategy to force upgrades-- as you seem to be implying.

I think they do. The original iPhone never got MMS support for alleged hardware reasons that were bunk. Siri was originally on the AppStore but once bought by Apple suddenly couldn't run on anything less than an iPhone 4S. There are probably other examples but those are the two I remember.

I’m fine with receiving years and years of security updates. I paid for the features I got. Anything new is a bonus. But an up to date secure OS is non-negotiable.

If it's non-negotiable for you, you have a choice: Google phones or Apple phones. Everything else is out, unless you want to try your luck with stuff like LineageOS and hope that they support your device for whatever timeframe you consider reasonable.

Well I don't consider Google's collection of my data to be a secure practice from the standpoint of my privacy. So the one remaining option is Apple.

There's also Copperhead OS. (You pay quite a bit for the privilege of security though.)

> For Apple, updates often mean some subset of the full operating system updates, or a crippled version.

A bit harsh, no? If new software requires hardware, why should that be considered "crippled"?

I find amazing that my 2013 iPhone5 can play games (Hearthstone) that some 2015/2016 Androids can't.

> If new software requires hardware, why should that be considered "crippled"?

Because I do not own that hardware, so for me uses the software is effectively crippled. I don't care why, only the outcome matters.

I wouldnt even mind not getting new features so much, but this also effectively means that my security updates are tied to new hardware; how is that acceptable?

What iOS update only included security updates based on hardware features?

Yeah... I didn't realize how annoyed I'd be on this when I bought my Nexus 6.

Not getting the latest just seems lazy and makes me want a flip phone that has good audible support. All of the crap that is getting added is just obnoxious and does little to help me use my phone.

Bonus points if anyone can tell me why enabling bluetooth will make it so my phone can't charge to 100% anymore.

What can it charge to instead?

It seems to change. For a couple of days, it couldn't charge and all. Even turned off, it would stay at 6% when plugged in. Cycled all of the radio devices on/off and it got to 25% but wouldn't go higher. Did one more cycle on/off of Bluetooth, and it went to full.

I'm blaming Bluetooth because it has been going to full charge fine for a few weeks and I turned Bluetooth back on to connect some headphones and the pattern repeated.

It's 3 years from the device's release. You get the next two major OS updates (which occur at ~1 and ~2 years after release), and then another full year of security updates, up to but not including the third major OS version.

The catch is that you can buy an Apple phone everywhere, but for instance Google decided simply to not offer the Pixel in my country.

Also, they stopped updating my Nexus 4 long time ago, something that Apple does not with their devices.

Hence, I am not "succumbing to Google marketing" again. I have now updated to a Moto, which used to be a Google company. Let's see how long it takes to update...

Yes, the limited availability of Google Store and Google hardware in general is a huge failing of the company.

I really don't understand why they so commonly fail to bring best Android devices to markets with most Android penetration - they're practically giving the market share away to Apple's aggressive price cuts lately.

The reason is they simply cannot do it. It's very different shipping a high end phone in units of 100 million vs shipping a high end phone in units of 500,000.

This is why most android high end devices are really tiny market share.

They can't compete with Apple-- AT VOLUME. Apple's supply chain is where they are hugely competitive. This goes for Samsung etc.

So on android, genuinely high end phones are prestige items to make android look good, but the mass of android phones are low end cheap phones that can easily be mass produced.

Apple has been known to buy 10,000 prototype modeling machines and put them into production because they were the only ones on the market that could do a particularly manufacturing step that was needed for that model... google is never going to do that.

In fact, I don't think google has ever made any phones (excluding Motorola) themselves-- all the Pixels are rebrands of other makers devices.

The Nexus line are the phones that are manufactured by various other device makers. I think the Pixel is actually made directly by Google.

The Pixel is made by HTC.

But we still don't know (do we?) who made that pixel: https://en.wikipedia.org/wiki/Chromebook_Pixel

Google made that one.

My understanding is that it is not enough to ship the device to a country, you also need an very large ad push and deals with local operators in order to actually sell it.

However, it should be mentioned that the pixel was sold in even less countries than the previous generation ..

Google really need to step up its game.

Not having an ad campaign is an extremely poor reason to refuse to ship EU-wide when they ship to Germany. The operator excuse is not valid in the EU. The EU is supposed to be a single market.

I would really like to see Google take Oreo as an opportunity to set an example and push the pixel 2 with something like 10 years of support.

I am not holding my breath though

That's a pretty unreasonable desire. Technology changes so much in 10 years that it wouldn't be feasible to support a generation of phones for that long.

10 years ago was the original iPhone. How much of a money sink would it have been for Apple to support the original iPhone until now?

10 is almost certainly high. However, the rate of innovation does seem to have slowed down. To the point that all of my other devices from 5 years ago still act like new. My phone? Meh.

What will really kill this is lack of user servicable batteries.

I agree. I am very happy with my Nexus 5 and I intend using it until the hardware gives up.

For context, 5 years ago people were still using the iPhone 4S, as the iPhone 5 wouldn't be announced for another 2 months.

And yet, most PCs built 10 years ago can still run most modern software that is written for modern PCs.

Demonstrating how much Microsoft bends over to maintain backwards compatibility. Something that for all their other flaws they should be applauded for.

You mean the APIs. But I wasn't talking about those, but rather the hardware - the only thing that you need there is ABI (or at least API) stability for drivers. So you can pull the same thing off with Linux, as well. Basically, modern desktop OSes can run on decade-old hardware, although they will have reduced functionality due to some missing features.

Which is why the sales have dropped more than 30% over the last couple of years.

Obviously, OEMs don't want this trend to continue.

Okay, let's say 5 years. I'm still using my first generation Nexus 7, and it's still working fine.

There's no rocket science in maintenance support (eg security patches) for 10 years. That's the only thing that is necessary to keep the device usable.

All the apps on the app store will be written assuming more powerful devices with newer API versions.

That's not really comparable.. the ecosystem is mature now.

But sure I am going far with 10 years.. and phones would need serviceable batteries to last that long.

What ecosystem becomes mature after just 10 years? A hard drive 10 years after the first one was invented in 1956 looked like this[0]. Is that mature? Phones are mature compared to 10 years ago, but whatever they evolve to in the next 10 will dwarf them.

[0]: http://images.computerhistory.org/storageengine/1966_Ferrite...

The smartphone was invented long before the iPhone. This is 10 years after it went mainstream.

And in ten years that iPhone has not changed much, except that the CPU/GPU rapidly caught up to current standards. The only other dealbreaker toward using it today is 3G support, and that's a 9 year old feature. If the iPhone 3G had the same relative performance to 2008 desktops as the current iPhone has to 2017 desktops, it would probably still be viable.

Maybe 10 years is a bit too high, but we're talking about high end phones here. I'd be surprised if the actual hardware wasn't acceptable 7 years down the line.

or atleast ~4 years like iOS devices get.

iPhones now seem to be supported for 5 years now:

- iPhone 4s was supported from iOS 5 to 9.

- iPhone 5 receives iOS 10 updates, but will be out for 11, so iOS 6 to iOS 10.

- iPhone 5s will receive iOS 11. That makes iOS 7 to 11.

My Moto G3 (2015) came with Android 5.1.1, and got an Android 6.0 upgrade. That's it. It has had two or three security updates since then, but it's still Android 6.0.

Despite that, it's been overwhelmingly the best phone I've had: cheap even unlocked, stable, no bloatware, waterproof.

My Moto G1.5 came with KitKat and was starting to suck on Lollipop after an update caused incurable excessive battery drain and constant app crashes. LineageOS Nougat restored the old hardware to its former glory. You would do well to do the same. Lollipop/Marshmallow is a liability.

Reflect for a moment; what was the 'new' price of the Nexus 4 vs the 'new' price of the iPhone at the time?

A Nexus 4 was a 2012 phone with 2GB ram, and 8GB storage (entry model) https://en.wikipedia.org/wiki/Nexus_4

An iPhone 5 is the comparable year device. https://en.wikipedia.org/wiki/IPhone_5 It had entry specs of only 1GB of RAM, but 16GB of storage. The apps would also be native binaries instead of 'java' apps, meaning less storage was needed.

IMO what killed support on the older Nexus phones was /mostly/ the insufficient entry level storage.

IMO what killed support on the older Nexus phones was /mostly/ the insufficient entry level storage.

This is provably false. The Nexus 6 plenty of storage space (32GB or 64GB) and does not get Oreo. Google's Nexus policy is to provide security updates for 3 years (or 18 months after the device stops selling, whichever is longer):


Also, the average Android app size is smaller:


I thought the reason is Qualcomm not giving what it takes to support a newer firmware on their soc. I have a Nexus 5 on lineage and I'm on Linux kernel 3.4.0.

Yes but Lineage OS can indefinitely support a fair chunk of Android 7.x on an old kernel without official help from Qualcomm.

Google chooses not to with AOSP past a timeframe.

The iPhone 5C with 8GB storage is still supported by Apple. Although not for much longer as it won't support iOS 11, and the OS takes up almost half the space on the phone.

not to diminish the rest of your argument, but my understanding is that java apps should be smaller than native apps (not significantly, since a huge part of apps' storage requirement is for assets, not code)

My experience around this time was that Android apps where much much smaller than similar iOS apps. Somewhere on the order of a 10x difference for apps without a lot of assets.

I'm sure 1GB for iOS is comparable to 2GB of RAM for Android.

This round of updates for Moto will be interesting, as it has a light skin. Completely dependent on Lenovo ownership, and they haven't been making the best choices lately.

My Moto X Pure (2015) has no carrier relationship and a very lightweight Android skin. It's still running Android 6.0.

I can't imagine them putting in development resources when they could just sell you a new phone.

FWIW, I still get security bugfix system updates on my 2015 Moto 3G, as recently as two months ago. Here's hoping they keep up this level of support.

Supposedly Lenovo has mentioned that future devices will drop even that skin.

To be fair, Samsung phones do sometimes get software features years before the Google and Apple phones (e.g. split screen multitasking).

> Everybody else will be probably 4-6 months late.

I am on OnePlus2 and still using version 6 because maintainers do not give a crap about 2 year old phone and it will never get updated at this point.

Flagship my ass.

I don't have to buy a new Apple Phone for immediate updates to the OS .... my 6, 6+, SE, and 7 will all be able to update on day one.

Am I missing something about your comment?

That's the common thinking that if you don't have latest Android it's a problem. But some manufacturers like Samsung push security updates monthly even for old devices such as Note 4. They do have many features years before the stock Android gets them (e.g. aptX, multiwindow or even Android O "tooltips" were in Note 4 when it was announced). So what exactly is the benefit of having everyone use the same exact, latest version? I most certainly would not switch to stock if that meant degarding my "experience" w.r.t. other features.

"Be together. Not the same."

This is spot on. In fact, for most users Lollipop brought lag and excessive battery drain for little user benefit.

Vertical integration has its advantages. Also, due to people buying new phones every 6 months those seem to be the two things that disincentivze Android phone makers to not do those things.

You can change that: don't buy a new phone every six months, and buy from a maker that supports your phone longer. Maybe you cannot get the latest, but when you support the companies that support their phones for more than a few months you support that business model which in turn ensures that someone who updates their phones exists.

You might have to leave the major names behind, and might have to skip a few features. Do you need the latest and greatest anymore though? When Android was new (2008) CPUs were much slower and upgrades did help your experience. (I remember missing calls because my phone couldn't switch to the phone app quick enough).

> You can change that: don't buy a new phone every six months, and buy from a maker that supports your phone longer.

I cannot change that. The ~5,000 I have spent on smartphones and laptops in the past 10 years is hardly enough. My buying choice, yours, and the GP's are just not strong and valuable enough to cause a manufacturer to pander to our desires.

The economies of scale and the greater money available from the opposite are so bad that no one even makes an expensive phone to capture our tiny segment of the market. They all chase the thinner, glued-up, bloatware-filled, non-repairable, closed-source, 2-year-or-less buyers. Same story on laptops.

In fact, my purchases seem to have the opposite effect: the Nexus is now as expensive as any other flagship. Motorola's cheap stock Android phone line shut down. LG stopped installing removable batteries. MacBook Pros still have nice hardware, but they are completely glued up. Thinkpads still have crappy stock screens.

That's not really true on Laptops. Apple, Lenovo, and Dell all make sturdy high-end upgradable repairable laptops. Not the kinds of products you'll see at your local West Fry though.

I'm a huge fan of Apple products in general - and firmly believe their laptops are the best on the market.

But there's incredibly little ground to call any of their current laptop lineup upgradable or repairable. I'm not sure there's a single upgradeable component left on any laptop they currently offer. The Macbook and the Macbook Pro have both moved to soldered CPU, RAM, and flash memory. The Macbook Air I believe still has a replaceable SSD but it has the proprietary connectory. To further complicate things - the batteries in the Macbook and Macbook Pro are both heavily glued in, so even that's difficult to replace.

I've worked with a Lenovo T60, a W520, a T430, and checked out the T560. They are steadily getting less repairable.

> and buy from a maker that supports your phone longer.

Who would those be? And who of those is not on the high end phablet side of the phone market?

When I used to have iPhones, every software update degraded performance, until eventually, an update would make the phone so unbearable to use you had to buy a new one.

Another point of view is you don't need an update if you bought a galaxy S8. It already has everything important and many more features. In fact, S7 actually regressed by updating to N. The multi window feature was perfectly stable and feature rich and most apps supported it. Google forced Samsung to replace it with their rudimentary implementation. Now it lacks features, is much slower, full of glitches and even after one year there are fewer apps that support it. At this point I'd rather Samsung keep sending monthly security updates and forgo on Google's OS update altogether.

Running Nexus 6P with Android Beta Program enabled. Got the stable Android Oreo in a couple of hours of the release.

Typically it's somewhere between 12 and Infinity months


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact