> We will begin rolling out updates to the HTC One (M8) and HTC One (M7) worldwide within 90 days of receiving final software from Google, followed shortly thereafter by other One family members and select devices.
So the Nexus 4, which is just under 2 years old, won't support Lollipop? Considering the device is from Google and not through a carrier I would expect better. No pricing on the Nexus 6 but I would expect it will cost a lot more than Nexus devices have in the past. And at only 1 inch less than their Nexus 7 tablet it seems ridiculously large. At what point is it a tablet that makes calls and not a phone?
Nexus Player is very interesting though - but again it all depends on the price which they haven't mentioned.
Edit:
As people below have pointed out they changed the page to include the Nexus 4 after my post.
Yes, but before you couldn't simply get a good mid to high-range phone for $400. That's not true anymore nowadays, the Moto X 2014 will probably go down to ~350USD/Euro off-contract like last year's generation. Heck, even the Moto G is a great phone for most people and is $179 off-contract for the LTE model.
Quite affordable compared to iphone 6+, which has an off-contract price of $750/$850/$950 for 16GB/64GB/128GB - on a 5.5" display. The 4.7" 16GB iphone - lowest end model available - is $650 off-contract.
In contrast, the $650 Nexus 6 has a 5.96" display and is presumably 32GB.
I agree that $650 seems like a lot of money for a phone - but that doesn't mean it's not a good value.
It's all kind of absurd. I skipped the Nexus 5, but was surprised when they didn't release L Preview for the Nexus 4. If that trend holds, then whatever OS update they pre-release at Google I/O 2015 will only be available on the Nexus 6. Does that mean I have to buy a Nexus 6 as an Android developer even though I don't like the size?
That's the thing - we buy our devices in line with what our customers use. So I have about a dozen devices, but I don't think the Nexus 6 will crack into the top 10. Is it worth buying solely for whatever new developer release comes out next Google I/O?
The Nexus 4 has been nerfed since shortly after the Nexus 5 came out - just like the Galaxy Nexus was nerfed just after the Nexus 4 came out. Based on their history, a Nexus device needs to be replaced once its successor comes out, so it's not a big surprise (but still a shame) that the Nexus 4 won't support L.
As an aside, I don't think you are using the word "nerf" correctly here. "nerf" is a gaming term that means turning a powerful weapon into basically a nerf gun. It means to make something cause less damage or make something less dangerous. I'm not sure how the Nexus phones were ever causing damage to anyone. I think the terms you want are "made obsolete" or "planned obsolescence".
It's also come to mean, in general, to make something less useful. You can "nerf" an alchemy or farming skill in an MMO, even if that doesn't have any combat ability.
Still, I don't think it's super appropriate, because there's nothing making the older phones worse, they just aren't getting better in the ways they obviously could.
> Still, I don't think it's super appropriate, because there's nothing making the older phones worse, they just aren't getting better in the ways they obviously could.
They released an update to the Galaxy Nexus that literally halved performance across the board and never addressed it. The Nexus 4 has had similar woes.
I don't think it's necessarily planned obsolecence so much as allocating less resources to testing and fixing issues on older devices, but to an end-user the result is similar.
If something's effectiveness is destroyed, it has been nerfed. I think being made obsolete is an appropriate time to use the word nerf, though I don't think the phones were in fact made particularly obsolete.
To "nerf" means to weaken or make less dangerous. Google's forced obsolescence of Nexus devices is clearly making the devices weaker and less capable than they can be. I think the use of the word "nerf" was accurate and justified in this case.
Galaxy Nexus was going to be supported by Android 4.2 (I was really annoyed that it wasn't!) but the fact that it's not has to do with TI refusing to update their closed-source drivers for their OMAP 4 chip to be compatible with the Linux kernel used in 4.2. By the time people figured out how to update them, Google had given up on providing support. I'm still pissed about that.
They might have changed the page since your comment but this is on the page :
"Android 5.0 Lollipop, which comes on Nexus 6, Nexus 9 and Nexus Player, will also be available on Nexus 4, 5, 7, 10 and Google Play edition devices in the coming weeks."
Am I missing something? The Nexus 4 certainly does appear to be supported.
Android 5.0 Lollipop, which comes on Nexus 6, Nexus 9 and Nexus Player, will also be available on Nexus 4, 5, 7, 10 and Google Play edition devices in the coming weeks.
Regardless of being officially supported (which it is) it's still a popular phone still in use by a lot of developers.
You might have to wait another month for it to hit AOSP and some of the ROM developers to merge it in, but I generally count on a Cyanogenmod release within a month.
This has happened for every single Nexus device, since the Nexus One. I don't know why people keep talking about the Nexus as somehow having fresh OS upgrades; they do not.
"Android 5.0 Lollipop, which comes on Nexus 6, Nexus 9 and Nexus Player, will also be available on Nexus 4, 5, 7, 10 and Google Play edition devices in the coming weeks."
I don't understand why people keep saying that it won't come on Nexus 4.
I don't have personal experience with this, but my anecdotal observations of friends with iPhones is that installing the new version of iOS on devices ~2 years old just makes people want to ditch those old phones and get the new ones, because performance isn't good any more.
The conspiracy theorist voice in my head says this isn't a coincidence.
I don't game on my phone... and have been using a Nexus 4 since release... the only time I notice any performance issue, is when I'm using Chromecast... I was really hoping to see the base price closer to the just under $400 I payed for my n4 (with shipping)... now, I'm not sure. May go for a Moto X once Android 5 is on it.
The conspiracy theorist voice in my head says this isn't a coincidence.
hahaha. Let's say that optimizing the new OS to an old hardware might not be one of Apple's priorities.
This being said, the OS gets more complex over time and more graphical features are added so I can not run just as smoothly as it does on a new terminal.
Android is a particular case.
It has been designed to run on any hardware and recent iterations of the OS are focusing on making it run on low end devices, so there are good chances that it will run relatively well on a Nexus 4.
Testing was conducted by Google using pre-production Nexus 6 devices and software. Talk time tests used default settings with Wi-Fi off and LTE on. Standby time tests used default settings with LTE on and Wi-Fi on. Wi-Fi internet tests had Airplane Mode on with Wi-Fi connected to a test access point, while loading three popular websites cached on a local server. The Nexus 6 loaded a page, waited 40 seconds, and then loaded a page from the next site. LTE internet tests had Wi-Fi off and LTE on, and used the same testing method as the Wi-Fi internet tests.
Edit: If you're going to downvote, please explain why.
The one company that seems to be honest about battery life is Apple imo. I find that when you use any of their devices the battery life works out to be about what they said.
They're referring to that turbo charger (or whatever the name is) that can give you 6 hours worth of your battery charged in 15 minutes. The real battery life is reported as 24 hours, so it's saying that you can get your battery from 1% to 26% in fifteen minutes.
Both battery claims come with interesting footnote:
Mixed use battery life claims are approximate and based on an average user profile developed and tested by Motorola that includes both usage and standby [1]
It means that there is a chance that your phone will be alive for 6 hours after just 15 minutes of charging (Battery must be substantially depleted [1]), if your usage/standby pattern is same as Motorola's.
I am really curious to see if there will be noticeable "real world" battery life improvements. On paper they have done things which SHOULD give us improvements (ART, and "Project Volta" scheduling), however it remains to be seen just how well those theoreticals will translate into improvements on the ground.
I have read reports from people who have tried the developer preview, however their anecdotes vary so wildly (e.g. 10-60% improvements) it is hard to believe any of them. Need something more scientific than people's vague "I got more hours today than yesterday."
It is very hard to measure battery life.
Testing it on a buggy developer preview is entirely irrelevant.
Volta and ART will improve battery life but they can't do anything for a shitty app that requests your location every second ..
Speaking just as a developer updating code for L-devices, the new scheduling interface almost guarantees an improvement depending on how many apps that sync in the background you have installed.
The paradigm went from "wake up every 10 minutes, turn on the CPU, check for network, try to do stuff, if you fail, try again in 10 minutes, keep waking up the device" to "tell the device to do my stuff when next there is network and sufficient battery and the CPU is already on for the sake of running other tasks".
Terrific, both my wife and I have a Moto X. Previous upgrades to the Moto X (not carrier-bound) were also very quick. Not Nexus-quick, but still very timely.
Just got a 2013 Moto G, and really curious to see if the 4x speed improvement ART can bring are frequent enough to matter. Also hope for stability, you know, like the battery bug.
Wondering if Google will clarify the upgrade path for those of us with Android L side loaded onto our phones.
My guess is it will require a re-flash back to KitKat so that Lollipop can be auto-upgrade over the air. In which case I might as well get that going now...
I doubt there will be an OTA, you'll just have to flash the full "clean install" factory image as it becomes available. Probably factory reset the phone as well.
They probably aren't going to try to upgrade safely. All the latest Google apps that have updates, like Photos and Newsstand and Google+ have actually been broken and crash on the L Preview.
They are just treating it like a true dev preview, not treating it as a daily driver.
"Improved network selection logic so that your device connects only if there is a verified internet connection on Wi-Fi"
jfc, I can't believe this is just now being fixed. This has to be the most infuriatingly stupid thing about android.
I don't have hopes of them adding the ability to intelligently switch from a weak wifi signal to a strong cell signal, but this is a step in the right direction.
No more assuming I have no new emails/texts when I'm in an airport because my phone quietly joined a wifi network and is waiting for me to open a browser and log in.
> adding the ability to intelligently switch from a weak wifi signal to a strong cell signal
Yeah, it hangs on that tiny, unusable WiFi signal for dear life, even when it cannot move a single bit of data through it. Meanwhile, the GSM data channel lies there unused. :(
Sometimes I will purposely log in to an airport's wifi network to use their connection.
The next time I'm back in that airport, my phone remembers the network and automatically connects.
I guess I need to manually remove these one-off networks, but I don't think I should have to micromanage my phone like that.
there's probably some app to auto-forget or a setting to "never remember" specific networks (especially ones that require an intermediate EULA agreement, which i assume the airport has)
I don't know about L, but KitKat instantly "saves" every network you tap on, even if it's broken. I didn't find option to disable that (but then I'd worry whether it'd save passwords at all).
It's a ridiculous hack, but here is what I do on Android:
Wi-Fi Matic saves the cell tower info when I successfully connect to an accesspoint, and turns on my Wi-Fi when I enter that area again. When I'm there, Wi-Fi Web Login replays a script that logs in to the captive portal webpage.
+1 for Wi-Fi Web Login. It's a great app I used to log into the guest network at my work to bypass filters. It even detects when a portal expires your connection after X time and reconnects again.
Samsung did their own enhancements to Android just for this problem. They have some sort of feature called "Smart network switch". The description says: "Automatically switch between wifi and mobile networks to maintain a stable internet connection.
This! I made the mistake of ONE TIME using the xfinity wifi hot spot and suddenly my phone became severely crippled as it would randomly try to be on some hotspot (configured or not) with that SSID.
> I don't have hopes of them adding the ability to intelligently switch from a weak wifi signal to a strong cell signal, but this is a step in the right direction
Android (supposedly) already has that feature. From the about page for Jellybean 4.2[1]:
> A new setting lets you stay on mobile data and avoid nearby Wi-Fi networks with poor connections.
Weirdly this seems to be off by default. In Wifi settings go to the more options drop-down and tap Advanced, and it's in that list. Give it a try!
I had no idea this option existed, and like you I'm surprised this isn't the default.
Thanks for posting this, you may have just improved my Android experience by quite a lot (just enabled this, need time to see how well it really works) since this is something I've been constantly annoyed by and didn't realize this existed as an option despite being a heavy Android user since Eclair.
I only noticed it because I got bored and looked through all the settings. There's also an obscure option to tell Android that a particular wifi point is a mobile hotspot (i.e. should be subject to the same data restrictions as the 3G/4G connection). I have no idea how many apps pay attention to the setting though. Bizarrely it's under data usage > more options > mobile hotspots, rather than being an advanced option on wifi networks.
after my initial bitch-post, I noticed this setting as well. I turned it on, and will be really happy if this resolves my problem.
weird that it's off by default.
It's a good feature, but I wish there was a way to disable it for certain WiFi networks. My Nikon camera can act as a WiFi access point so I can download images to my phone. But if I turn on that Android feature it continuously drops the camera WiFi connection because obviously there's no Internet connection available.
ok, I turned this on. unfortunately it's overzealous.
I work in a pretty cavernous studio where I never have trouble getting wifi, but there's no cell signal.
With 'avoid poor connections' turned on, it drops my 2/3 bar wifi signal in favor of a nonexistent cell signal. I have to disable this feature to get any service.
Based on over a month on Android L Preview, it's not working as well as advertised. Often I just drive by my home and my LTE connection drops although the connection is really not operational. I hope the final version fixes this as it's been years of frustration already!
I always cringe when I read a complaint like this. Every larger project has a long issue list, and it is perfectly normal that an issue that is super important to some ends up further down on the priority list of the team.
The Android team implemented a lot of issues and features over the last decade. Just because there is an issue that deserves fixing doesn't mean it is the most important task at hand.
iOS 8 included over 4,000. It's not really a big deal. There's stuff that's deprecated an replaced but won't be removed for several releases (and you'll get compiler warnings so you're aware), there's a tonne of stuff you'll never use, there are lots of API's for new features (iOS example: HealthKit), and then there are things which you'll come across from time to time that make your life a little easier.
As an Android dev, Lollipop is indeed a big release but not a 'throw everything you have and start over' style change.
Some things have been completely rewritten :
Notifications have been using the same expanding API since version 1, it has been strongly revamped. The RemoteControlClient (which manages the lockscreen and is used for some other things like communication with Chromecast) was one of my least favorite parts of the Notification code, it is being phased out and replaced by a new, simpler (and hopefully more reliable) one.
The ActionBar API (the bar of controls at the top of every android app) was initially based on the old menu API (from the time when we had menu buttons on Android). It was a very nice move to soften the menu button > actionbar transition but it is now adding unnecessary friction. Since the ActionBar has been redesigned, it was a very good opportunity to deprecate its API and replace it by a completely new one.
ListView (the widget that handles lists) is one of the oldest Android widgets. It has been conceived in an era where displaying a static list was all you wanted. It is a central piece of almost every app UI and it is comically inadequate. It is going to be replaced by RecyclerView, which take into account modern requirements on lists (adding, removing items, handling gestures, ...).
Many other changes are just additions. A better animation system, a tinting system for on screen elements, some new widgets, ...
There are also some completely new APIs but many of these will only be used by a handful of developers (it is not every day that you need to convert the content of your screen to a PDF and print it).
Are they providing first-party horizontal lists (i.e. something to compete with UICollectionViews)? Still waiting for an official Gallery replacement...
EDIT: Did the reasonable thing and actually looked it up myself [1,2]. Turns out they provide RecyclerView paired with a LinearlayoutManager to achieve arbitrary UI on top of a dataset. This is nearly identical to the iOS setup of UICollectionView with a UICollectionViewLayout (and LinearLayoutManager is == to UICollectionViewFlowLayout as far as I can tell).
RecyclerView in fact only knows how to manage a pool of views that get recycled.. hence the name.
Recycling is a very common approach to that problem on mobile, nothing new here, RecyclerView just specializes in recycling as best as possible.
In order to use it, you need to specify a LayoutManager that will handle how elements are displayed on the screen.
Google provides a linear one, and the community has already been working on Grid and staggered grid.
Compared to ListView, RecyclerView does not make counterproductive assumptions on what it is going to do. ListView has been written in the Blackberry era. Its only goal was to display a static list of item. No animations, no operations on the items, no gestures. It is possible to implement some of these, but for all advanced operations you hit the assumptions that ListView made on how its items are displayed. In the end, you spend more time fighting the widget than building on top of it.
RecyclerView shows a good separation of concerns. You want to implement gestures ? here you go, implement the RecyclerView.OnItemTouchListener interface and you are good to go.
You want custom animations on addition/removal/replacement of an item ? No problem, just implement your own ItemAnimator.
Many parts of the widget have been thought out in order to be customizable and get out of your way and let you build on top of it.
Also, it is part of the support library. Google can update it as many times as necessary and make the changes available on all terminals since it is no longer a part of the platform.
I am sure that RecyclerView has its own quirks and limitations. In fact in the dev preview while ListView only handle Headers and Footers very badly, RecyclerView does not handle them at all. However, it is a very strong foundation on top of which it will be possible to efficiently build an Android app without having to reinvent the wheel.
Looks like no fine-grained control of app permissions, either dynamic/on-demand or manual. This approach (all or nothing) is one major issue that cripples Android usability for me. :(
This feature is one of the reasons I run CyanogenMod. You can drill down and toggle particular permissions for each app if you want, and set default policies for new apps.
I just can't install apps anymore. They all want everything. There is no reason for a todo list app to need my location, sms, camera, etc, etc... This needs to be fixed.
Google does not want people taking over permissions and privacy. This is demonstrated by the deliberate design of the phone state permission. Any app should be able to query "is the user on a voice call", but Google wrapped that up in a "get my device serial, as well as phone numbers I call or call me".
Download a flashlight app, then call your cancer or fertility clinic? Awesome, now some random developer has that information.
Chrome does other tricky stuff that's "evil". When you go to turn on "Do Not Track", they put up a very big warning. Much more than other privacy related features. But then!... They flip the OK and Cancel buttons around. Literally, for that one feature, they intentionally go out of their way to mess up the UI to trick people into keeping DNT disabled. Chrome doesn't do this for any other critical options.
The permissions on Android are further weakened, with apps able to add permissions without any indication via updates. (So long the permission is in the same group.) It's well-known that all-or-nothing, say-yes-or-it-dont-work is a busted model -- MS proved that with ActiveX and Vista's plethora of UAC prompts. So it's very unlikely that Android's permission model and UI is accidental.
And even then, consider the rampant abuse in the Google Play store. It's hard to find small apps, like a flashlight, that doesn't request all permissions. Yet Google does nothing, and takes no effort to inform users that such apps are likely to be doing things the users don't want.
I've realized, unfortunately, Google is not a force for good. They're happy to protect users against other threats (like code execution exploits or SSL attacks), but they are actively working against privacy, openly hostile. Do no evil indeed.
I really doubt that it was an intentional 'grab all your info' move, it is just a decision made at the time where engineers were reigning at Google and thought that 'give the user a list of all the permissions required by the app' was a great solution.
It kinda work ... except that generations of users have learned to always click yes when there is a warning ..
Also, you sometimes have to ask for a permission like SMS, only because you will use it in a very specific case (in this example for SMS payments in that country where it is a popular form of payment).
Now that we have been rolling with this system for quite a while, it is very hard to change it.
Apple had a couple of issues as well, but mostly got it right from the start.
I think we know that it's intentional, because after all these years they haven't improved. Take for example, Apple. They've adopted a bunch of Android first innovations. So, what is stopping Google from adopting Apple's security model? Either they are building it and we should see it soon, or Google doesn't want users to be mindful of their privacy because it puts their own business at risk, so the status quo will remain until a forcing function occurs (eg. user revolt due to malware).
117 comments
[ 5.0 ms ] story [ 177 ms ] threadhttp://www.phonearena.com/news/When-is-my-phone-getting-the-...
Wondering if my HTC One Google Edition will get the update sooner..
> We will begin rolling out updates to the HTC One (M8) and HTC One (M7) worldwide within 90 days of receiving final software from Google, followed shortly thereafter by other One family members and select devices.
Nexus Player is very interesting though - but again it all depends on the price which they haven't mentioned.
Edit:
As people below have pointed out they changed the page to include the Nexus 4 after my post.
http://motorola-blog.blogspot.com/2014/10/nexus-6-from-googl...
In contrast, the $650 Nexus 6 has a 5.96" display and is presumably 32GB.
I agree that $650 seems like a lot of money for a phone - but that doesn't mean it's not a good value.
That is - Nexuses actually work and run new OS, while people out there you're developing for are using Samsungs with their buggy and broken firmware.
Still, I don't think it's super appropriate, because there's nothing making the older phones worse, they just aren't getting better in the ways they obviously could.
They released an update to the Galaxy Nexus that literally halved performance across the board and never addressed it. The Nexus 4 has had similar woes.
I don't think it's necessarily planned obsolecence so much as allocating less resources to testing and fixing issues on older devices, but to an end-user the result is similar.
To "nerf" means to weaken or make less dangerous. Google's forced obsolescence of Nexus devices is clearly making the devices weaker and less capable than they can be. I think the use of the word "nerf" was accurate and justified in this case.
Galaxy Nexus was going to be supported by Android 4.2 (I was really annoyed that it wasn't!) but the fact that it's not has to do with TI refusing to update their closed-source drivers for their OMAP 4 chip to be compatible with the Linux kernel used in 4.2. By the time people figured out how to update them, Google had given up on providing support. I'm still pissed about that.
"Android 5.0 Lollipop, which comes on Nexus 6, Nexus 9 and Nexus Player, will also be available on Nexus 4, 5, 7, 10 and Google Play edition devices in the coming weeks."
Android 5.0 Lollipop, which comes on Nexus 6, Nexus 9 and Nexus Player, will also be available on Nexus 4, 5, 7, 10 and Google Play edition devices in the coming weeks.
You might have to wait another month for it to hit AOSP and some of the ROM developers to merge it in, but I generally count on a Cyanogenmod release within a month.
I don't understand why people keep saying that it won't come on Nexus 4.
The conspiracy theorist voice in my head says this isn't a coincidence.
On the iPhone 5, iOS 8 performance is brilliant, which it needs to be, because Apple are still selling the iPhone 5C.
When I see the Nexus 4 in public now, it's effectively a crippled phone.
With Apple you're getting 1-2 years extra, which probably makes it worth it over the lifetime of the device.
Android is a particular case. It has been designed to run on any hardware and recent iterations of the OS are focusing on making it run on low end devices, so there are good chances that it will run relatively well on a Nexus 4.
From http://www.google.com/nexus/6/
Testing was conducted by Google using pre-production Nexus 6 devices and software. Talk time tests used default settings with Wi-Fi off and LTE on. Standby time tests used default settings with LTE on and Wi-Fi on. Wi-Fi internet tests had Airplane Mode on with Wi-Fi connected to a test access point, while loading three popular websites cached on a local server. The Nexus 6 loaded a page, waited 40 seconds, and then loaded a page from the next site. LTE internet tests had Wi-Fi off and LTE on, and used the same testing method as the Wi-Fi internet tests.
Edit: If you're going to downvote, please explain why.
1 week battery life!*
*In airplane mode, no apps running and the screen was only turned on once a day
The one company that seems to be honest about battery life is Apple imo. I find that when you use any of their devices the battery life works out to be about what they said.
Mixed use battery life claims are approximate and based on an average user profile developed and tested by Motorola that includes both usage and standby [1]
It means that there is a chance that your phone will be alive for 6 hours after just 15 minutes of charging (Battery must be substantially depleted [1]), if your usage/standby pattern is same as Motorola's.
[1] http://www.google.com/nexus/6/
I have read reports from people who have tried the developer preview, however their anecdotes vary so wildly (e.g. 10-60% improvements) it is hard to believe any of them. Need something more scientific than people's vague "I got more hours today than yesterday."
The paradigm went from "wake up every 10 minutes, turn on the CPU, check for network, try to do stuff, if you fail, try again in 10 minutes, keep waking up the device" to "tell the device to do my stuff when next there is network and sufficient battery and the CPU is already on for the sake of running other tasks".
http://motorola-blog.blogspot.com/2014/10/its-official-andro...
My guess is it will require a re-flash back to KitKat so that Lollipop can be auto-upgrade over the air. In which case I might as well get that going now...
They are just treating it like a true dev preview, not treating it as a daily driver.
You will most likely have to flash from scratch.
https://android.com/versions/lollipop-5-0/
jfc, I can't believe this is just now being fixed. This has to be the most infuriatingly stupid thing about android. I don't have hopes of them adding the ability to intelligently switch from a weak wifi signal to a strong cell signal, but this is a step in the right direction. No more assuming I have no new emails/texts when I'm in an airport because my phone quietly joined a wifi network and is waiting for me to open a browser and log in.
Yeah, it hangs on that tiny, unusable WiFi signal for dear life, even when it cannot move a single bit of data through it. Meanwhile, the GSM data channel lies there unused. :(
i would suggest not having your phone auto-connect to just any open wifi network, but that's just me.
I guess I need to manually remove these one-off networks, but I don't think I should have to micromanage my phone like that.
Wi-Fi Matic saves the cell tower info when I successfully connect to an accesspoint, and turns on my Wi-Fi when I enter that area again. When I'm there, Wi-Fi Web Login replays a script that logs in to the captive portal webpage.
Great for travelling.
Android (supposedly) already has that feature. From the about page for Jellybean 4.2[1]:
> A new setting lets you stay on mobile data and avoid nearby Wi-Fi networks with poor connections.
Weirdly this seems to be off by default. In Wifi settings go to the more options drop-down and tap Advanced, and it's in that list. Give it a try!
[1] http://www.android.com/about/jelly-bean/
Thanks for posting this, you may have just improved my Android experience by quite a lot (just enabled this, need time to see how well it really works) since this is something I've been constantly annoyed by and didn't realize this existed as an option despite being a heavy Android user since Eclair.
I'm gonna give it a try, thanks.
I work in a pretty cavernous studio where I never have trouble getting wifi, but there's no cell signal. With 'avoid poor connections' turned on, it drops my 2/3 bar wifi signal in favor of a nonexistent cell signal. I have to disable this feature to get any service.
I always cringe when I read a complaint like this. Every larger project has a long issue list, and it is perfectly normal that an issue that is super important to some ends up further down on the priority list of the team.
The Android team implemented a lot of issues and features over the last decade. Just because there is an issue that deserves fixing doesn't mean it is the most important task at hand.
As a developer not initiated to the Android platform, the second half of this sentence is a very scary thing to read.
Some things have been completely rewritten :
Notifications have been using the same expanding API since version 1, it has been strongly revamped. The RemoteControlClient (which manages the lockscreen and is used for some other things like communication with Chromecast) was one of my least favorite parts of the Notification code, it is being phased out and replaced by a new, simpler (and hopefully more reliable) one.
The ActionBar API (the bar of controls at the top of every android app) was initially based on the old menu API (from the time when we had menu buttons on Android). It was a very nice move to soften the menu button > actionbar transition but it is now adding unnecessary friction. Since the ActionBar has been redesigned, it was a very good opportunity to deprecate its API and replace it by a completely new one.
ListView (the widget that handles lists) is one of the oldest Android widgets. It has been conceived in an era where displaying a static list was all you wanted. It is a central piece of almost every app UI and it is comically inadequate. It is going to be replaced by RecyclerView, which take into account modern requirements on lists (adding, removing items, handling gestures, ...).
Many other changes are just additions. A better animation system, a tinting system for on screen elements, some new widgets, ... There are also some completely new APIs but many of these will only be used by a handful of developers (it is not every day that you need to convert the content of your screen to a PDF and print it).
Are they providing first-party horizontal lists (i.e. something to compete with UICollectionViews)? Still waiting for an official Gallery replacement...
EDIT: Did the reasonable thing and actually looked it up myself [1,2]. Turns out they provide RecyclerView paired with a LinearlayoutManager to achieve arbitrary UI on top of a dataset. This is nearly identical to the iOS setup of UICollectionView with a UICollectionViewLayout (and LinearLayoutManager is == to UICollectionViewFlowLayout as far as I can tell).
Compared to ListView, RecyclerView does not make counterproductive assumptions on what it is going to do. ListView has been written in the Blackberry era. Its only goal was to display a static list of item. No animations, no operations on the items, no gestures. It is possible to implement some of these, but for all advanced operations you hit the assumptions that ListView made on how its items are displayed. In the end, you spend more time fighting the widget than building on top of it. RecyclerView shows a good separation of concerns. You want to implement gestures ? here you go, implement the RecyclerView.OnItemTouchListener interface and you are good to go.
You want custom animations on addition/removal/replacement of an item ? No problem, just implement your own ItemAnimator.
Many parts of the widget have been thought out in order to be customizable and get out of your way and let you build on top of it.
Also, it is part of the support library. Google can update it as many times as necessary and make the changes available on all terminals since it is no longer a part of the platform.
I am sure that RecyclerView has its own quirks and limitations. In fact in the dev preview while ListView only handle Headers and Footers very badly, RecyclerView does not handle them at all. However, it is a very strong foundation on top of which it will be possible to efficiently build an Android app without having to reinvent the wheel.
Catching up to Apple but I'd love to see this across laptops as an app or through Chrome.
https://android.com/versions/lollipop-5-0/
Download a flashlight app, then call your cancer or fertility clinic? Awesome, now some random developer has that information.
The permissions on Android are further weakened, with apps able to add permissions without any indication via updates. (So long the permission is in the same group.) It's well-known that all-or-nothing, say-yes-or-it-dont-work is a busted model -- MS proved that with ActiveX and Vista's plethora of UAC prompts. So it's very unlikely that Android's permission model and UI is accidental.
And even then, consider the rampant abuse in the Google Play store. It's hard to find small apps, like a flashlight, that doesn't request all permissions. Yet Google does nothing, and takes no effort to inform users that such apps are likely to be doing things the users don't want.
I've realized, unfortunately, Google is not a force for good. They're happy to protect users against other threats (like code execution exploits or SSL attacks), but they are actively working against privacy, openly hostile. Do no evil indeed.
[0] http://bit.ly/1u8avx3
Compare to when enabling "OK Google" where OK and Cancel are flipped.
I guess they couldn't fit it in on Android?
I am all for moving to Apple's model, but making this move while staying back-compatible is not trivial at all.