The Android 5.0 Lollipop Review
by Brandon Chester on December 1, 2014 10:00 AM EST- Posted in
- Smartphones
- Android
- Tablets
- Android 5.0
Lock Screen
The Android lock screen has gone through a number iterations over the years. With Ice Cream Sandwich Google settled on a design that was a lock symbol surrounded by a circle, which could be dragged to the right to unlock the phone, and to the left to open the camera. This solution didn't really have any issues, although I feel like the move away from the previous method of sliding right to unlock had more to do with legal pressure than anything else. As Android evolved, Google maintained the same overall design, but relocated the camera to a button in the bottom left, and allowed the user to drag the ring anywhere to unlock the phone. Google Now was also integrated into an upward facing arrow at the bottom. At this point, I think Google was adding too much for that original lock screen design to handle. The upward arrow seemed to imply that you were to swipe the circle upward to unlock, and the camera button functioned not like a button, but like a slider. This meant that Google had to have the camera slide in from the left even when the user had only touched the camera icon so they would be aware of what they were actually supposed to do, and at that point you need to accept that your design is flawed.
With Android Lollipop, Google has redesigned the lock screen to be much simpler. Although it's not immediately obvious what action should be performed to unlock the phone, tapping anywhere except the camera and phone icons causes everything on screen to bounce upward, and text appears telling the user to swipe up to unlock. I would argue that text could just be there constantly to make it more obvious how to unlock the phone, but the current design doesn't really hinder usability. Not constantly displaying the text also allows Google to let the user know how to use the icons on the sides, which are activated by touching and dragging toward the middle of the display. Tapping these icons displays a message explaining what to do to use them, and an arrow is displayed which points in the right direction. As you drag, a circle begins to expand outward from the icon, eventually automatically expanding past the edges of the display and revealing either the phone or camera application. It's a much more elegant solution than the previous lock screen quick access button, and I'm really happy that Google has put work into making it functional but understandable.
Launcher
The Google Now launcher that ships with Nexus devices is functionally identical to its KitKat iteration in Android Lollipop. Visually, Google has made some tweaks to make it fit in with the rest of the Material Design applications. The most obvious is the change you see above, with the app drawer being given a white background that the icons now sit upon. The dots at the bottom that represent the current page you're on have also been made smaller, and the current page is now represented by a purely white circle rather than an enlarged one. Google has also made some more subtle changes with the animations. Attempting to swipe past the last home screen or page of apps in the launcher no longer has an animation where the icons appear to tilt to give it an appearance of depth. Similarly, the new animations in the app drawer are simple left and right transitions, without the depth of the original animation which showed one page sliding away and the next moving in from beneath. I'm not sure if I like the new launcher as much as the old one. While it definitely fits in better with the rest of the operating system, I liked the old transparent app drawer background more than the original black background or this new white one.
One other thing to note about the launcher is about Live Wallpapers. I'm including this here because it doesn't fit anywhere else but it's something I thought was worth mentioning. It feels like over time Google has been slowly removing stock Live Wallpapers from Android. I don't know if this is due to performance reasons, battery life issues, or some other problem. In any case, it should be noted that while the Nexus 5 maintains its Sun Beam wallpaper when upgrading to Lollipop, the Nexus 6 does not come with a single live wallpaper.
Keyboard and Navigation Buttons
Apart from the removal of the orange text highlighting in the suggestions bar, Google's Android keyboard has been essentially unchanged since Android Gingerbread. This was fine for quite some time, as it fit in well with the overall design of Android. But with Lollipop, that black and grey keyboard would look quite out of place. Thankfully, like the rest of the OS, the keyboard receives a visual update in Lollipop. Most obvious is the change from a black to a white background, and the removal of the separate key for each letter. It's a very interesting and minimalist take on a keyboard, and although I initially thought it might make it more difficult to hit the right keys, I've had no such issue in actual use. Google has also moved the voice dictation button up into the suggestions bar, which will be a welcome change for users who want it enabled but that ended up accidentally hitting it due to its position next to the space key. Users who prefer the darker colors of the old keyboard are able to switch to a Material Dark themed keyboard which is dark blue with white letters, but is otherwise the same as the Material Light version.
The last thing I'd like to comment on are the new navigation buttons. Like the keyboard, they're much simpler and more minimalist in Lollipop than they were in KitKat. Users who are familiar with Android will have no trouble with them, as they're in the same position and in the case of the back button and the button for recent apps they have a similar shape. The home button is a bit of an exception. Keeping in sync with the other two buttons which are simple shapes, the home button is now a circle. This is fine, and I'm glad it fits in well, but it's not quite as obvious as the old icon which looks sort of like a house with it's rectangular base and triangular top. The connection between house and home was fairly easy to make, and so it was obvious what it did. I suppose that Google believes that users are now familar enough with smartphones to be able to figure this sort of thing out relatively quickly.
Facebook
Twitter
RSS
126 Comments
View All Comments
kron123456789 - Saturday, December 6, 2014 - link
Are you sure about that? The SoC labled as Exynos 5433 was found in Galaxy Note 4, but later Samsung claimed that Galaxy Note 4 has Exynos 7 Octa.http://www.samsung.com/global/business/semiconduct...
Did they changed the SoC through OTA update? :)
OreoCookie - Monday, December 1, 2014 - link
Have a look at http://arstechnica.com/gadgets/2014/11/nexus-9-rev...">Arstechnica's review of the Nexus 9: you see that the Nexus 9 fares better in some benchmarks in 64 bit mode while in others, it's slower. The difference is always quite small (about 1~2.5 %), so small that it's barely above the threshold of the statistical error, I bet.That was surprising to some, because they expected the Denver-based K1 to get a 20~30 % boosts similar to iOS devices when comparing 32 and 64 bit modes. At this stage nobody knows whether the basically flat results are due to the unusual architecture of the Denver cores (maybe the result of the code morphing is microcodes which is optimized at about the same level) or whether it's that ART does not yet make good use of the architecture. Given the fact that in 64 bit mode ARM processor can address more registers etc. I would guess that it's the former, the unusual architecture of Denver. I really hope Anandtech subjects it to an architectural deep dive.
Solandri - Monday, December 1, 2014 - link
The 20%-30% speed boosts I've seen in iOS benchmarks from going 64-bit were grossly exaggerated by using the mean. You can't use the mean because it by definition weighs larger values more heavily. If there's a playground with a half dozen 8 year old kids romping around, a single 90-year old sitting on a bench will raise the mean age to 20. So a single large benchmark improvement can disproportionately skew the mean when the vast majority of benchmarks showed little to no improvement.You have to use the median in these cases. The median benchmark speedup I've seen has been about 5%-9%. If you remove the benchmarks which improved due to specialized hardware being added, the median improvement drops below 5%. Which is in line with the speedup Windows experienced when transitioning to 64-bit CPUs.
Really, the only places where going to 64-bit can speed things up is flat memory addressing, which isn't a factor because none of the iOS devices have more than 4 GB. With calculations using long long ints (64 bit ints), which almost nobody uses. And with double floats, which outside of certain benchmarks is mostly used in scientific programming. Even most 3d game engines still use 32-bit floats because it's "good enough" for most cases (doubles don't become necessary until you start dealing with extremely large distances, like space simulation games). Most of the speed increase from Apple's 64-bit SoC comes from increasing the number of registers and from new specialized hardware speeding up things like AES by over 200%, both of which have nothing to do with 64-bit-ness. (Memory bandwidth is a bigger issue due to light only being able to travel 12cm in a single 2.5 GHz clock cycle. I'm not sure what memory controller ARM uses, but most devices have long since adopted 128-bit or larger memory controllers to get around this physics-imposed limit.)
The Hardcard - Monday, December 1, 2014 - link
The added registers and other resource are tied to 64-bit-ness in the sense that ARM decided to make architectural boosts with the move to 64 bit. True they could have added those to 32-bit ARM but there wasn't a point in doing that.An possible explanation for the Denver results may not be in the code morphing in and of itself. It could just as well be that it uses the full register set and all the other resources for both 32-bit ARM and 64-bit ARM emulation. Because it is not that the 64-bit results are so bad, but that the 32-bit results are so good. You could just be seeing what it would be like if ARM had added the registers and instructions to 32-bit.
OreoCookie - Monday, December 1, 2014 - link
First of all, it's part of the interpretation of data on how you obtain an average from the raw data. You argue it's the median instead of the expectation value, but a more realistic average would rely on weighing according to the instruction mix -- which varies. If encryption algorithms are constantly used (and they are used a fair bit on smartphones with all the encrypted traffic), then 250~800 % speed advantage is not an outlier, but significant in applications. Moreover, many of the benchmarks such as these (http://www.anandtech.com/show/7335/the-iphone-5s-r... are not necessarily meant to tell you how much faster the device will be in typical use (where most mobile SoCs are idling anyway), but rather probe specific aspects of the architecture in order to understand how it has evolved. Certainly I won't be the one arguing that simulating SDEs such as the Black-Scholes equation is a common real-world application in SoCs ;-) And speaking of a 20~30 % speedup on average (even if you exclude outliers) seems quite sensible given the benchmarks. If you want to argue about how to properly weight these benchmarks (e. g. that FP benchmark results which show more of an improvement are less important), that's a different discussion.You're also wrong when you claim that flat memory addressing is the only place where going 64 bit can speed things up: ARMv8 has twice the number of registers compared to ARM v7 which (similar to going from x86 to x64) -- and while this has nothing to do with 64 bit, but it has everything to do with being part of the new ARM ISA which also happens to be 64 bit. There are also changes to the Objective C runtime in order to take advantage of the 64 bit-ness, e. g. creation and destruction of objects was sped up by a factor of 2 (https://mikeash.com/pyblog/friday-qa-2013-09-27-ar... which can cumulatively become significant in iOS apps where you constantly manipulate objects.
I don't think the attempt to separate improvements which have nothing to do with going 64 bit itself but are rather part of the 64 bit ARM v8 ISA is going to be practically useful because we cannot decouple the different components. Ditto for hardware encryption logic which replaces software routines: they are a real-world advantage, and the only question will be by how much.
name99 - Wednesday, December 3, 2014 - link
It's a little ridiculous to claim that speedups from AES are "unfair" on the same blog that has been complaining about how much dramatically Android's whole-disk encryption slows down the OS...tuxRoller - Monday, December 1, 2014 - link
Denver is a different enough arch (internally) that there may be other reasons why it isn't faster.jnemesh - Tuesday, December 2, 2014 - link
Did you see any performance benefits moving from Windows 32 bit to Windows 64 bit? Nope. Not one little bit. You wont see any here either. As with desktop PCs the main benefit to 64 bit is that it allows you to address more than 4GB of memory. As most phones are shipping with 3GB or less, you won't see any benefit to a 64 bit environment unless and until the apps start demanding more RAM.Maleficum - Friday, December 26, 2014 - link
You don't have to struggle to prove your ignorance.After the Itanium fiasco, Intel abandoned IA64 and licensed the half-baked x86_64 where larger addressing space is practically the only benefit.
Aarch64 is a full-fledged 64-bit architecture with a completely rewritten ISA similar to what Intel dreamed of with the Itanium. Larger addressing space is just one of the many side benefits on Aarch64.
kspirit - Monday, December 1, 2014 - link
I don't know why people refuse to accept that the Lollipop UI, with its metro-like appearance of flat tiles and bold colours isn't a blatant copy of Windows Phone. I'm not hating, I actually like Android a lot, but come on! It's wrong to be in denial like that.On my Nexus 4, the recent contacts in the dialler app are actually coloured squares arranged in a grid! I mean, seriously? Might as well have polished up Holo. At least it was unique to Android.