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.
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 .
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.
: 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.
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..)
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 . 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.
: 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.
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.
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.
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.
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.
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...
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.
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.
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.
... they have gotten better at this.
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.
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?
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.
With the difference that younger (newer) animals are better built. :-)
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.
If vendors choose to not use this feature it is on them.
If they say "install it this way or no Play Store for you", every manufacturer will follow.
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.
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.
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.
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.
and it's not rolled into the base OS either, it's part of "google connectivity services" which is distributed separately.
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.
Java/Kotlin/C++ vs Dart for user space, Linux vs Magenta for the kernel and drivers.
>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.
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.
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.
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.
Yes, but only if you declare the business models of everyone involved a non-goal.
An open core business model was always what Android was like, but now the opem core is shrinking with every further commit.
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.
Also, open sourcing the apps takes away any leverage Google has to recoup the costs of developing Android.
This all worked in the past.
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.
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.
It's a game I wish they'd get out of entirely. There's no such thing as a useful carrier overlay.
Six months and counting, waiting for Verizon to approve the Nougat update on my HTC One M9. It has literally hit everyone else:
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.
P.S. also, was Cingular a joke about AT&T? I think I missed what the joke is...
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.
Honestly, what are they doing, and why does it take them multiple months to do it?
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.
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.
Also, plenty ISPs actually do sell branded wireless routers with branded firmware, so it's not uncommon practice in other neighboring industries.
I imagine carrier responses would look a lot different then.
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).
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.
What's in it for them?
I buy my phone. It's mine. I can put it on any network I like.
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.)
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.
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.
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.
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?
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.
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.
Belle already had lots of features that took Android and iPhone years to catch up with.
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...
In particular when Nokia tried to introduce SIP support.
I'm pretty sure I got an actual update at least once.
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.
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.
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.
>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?
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.
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 carrier can still, of course, test the new firmware all they like - they just shouldn't be able to interfere with its release.
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.
Verizon especially makes it miserable. Ah, but who am I kidding, I'm sure Verizon will still find a way to ruin it.
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.
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.
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.
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.
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.
But no one want to get computer with Windows 95 (or 98) anymore. Just Android 4.4 is "OK".
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?
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."
The only viable alternative was Windows Phone, but that is gone now.
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.
This is why software/hardware needs best before dates.
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.
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.
Honestly though, I think all of the company use the same strategy. Only the flagship line is the one getting extended support for update
They literally didn't update note tablets once!
(note that I wasn't able to actually replicate broadpwn on Nexus 5, if anyone was, some info would be appreciated)
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.
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?
> 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).
I really wonder what's going on here.
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".
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.
Measuring glyphs, dealing with reflow, kerning, whitespace breaking rules, etc is no fun
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.
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.
Really wish i could find an android tablet with a full size A port these days that didn't run a ancient version...
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.
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.
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.
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).
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.
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.
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?
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.
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.
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.
Swiping it away instantly kills the app unless it has a foreground service with an associated notification.
Even comparing WebGL 2.0 to OpenGL ES 3.0, which it is based on, there are nice features like geometry shaders missing.
In WebGL 2 you can still do geometry processing, and store results in buffers for subsequent draw calls, using transform feedback.
Like that idea for WebGL 2.0, will have a look into it.
> 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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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)...
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.
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), 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".
 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".
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.
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?
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.
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.
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...
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.
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.
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.
I am not holding my breath though
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?
What will really kill this is lack of user servicable batteries.
Obviously, OEMs don't want this trend to continue.
But sure I am going far with 10 years.. and phones would need serviceable batteries to last that long.
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.
- 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.
Despite that, it's been overwhelmingly the best phone I've had: cheap even unlocked, stable, no bloatware, waterproof.
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.
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:
Google chooses not to with AOSP past a timeframe.
I can't imagine them putting in development resources when they could just sell you a new phone.
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.
Am I missing something about your comment?
"Be together. Not the same."
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).
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.
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.
Who would those be? And who of those is not on the high end phablet side of the phone market?