Android 5.0 Lollipop
googleblog.blogspot.com
googleblog.blogspot.com
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!
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.
http://motorola-blog.blogspot.com/2014/10/its-official-andro...
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).
[1] - http://www.grokkingandroid.com/first-glance-androids-recyclerview/
[2] - https://developer.android.com/preview/material/ui-widgets.htmlCompared 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.
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".
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.
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.
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.
http://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.
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.
Catching up to Apple but I'd love to see this across laptops as an app or through Chrome.
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.