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
Google Fit
Google Fit was launched at Google IO, as an answer to other health systems put forth by Apple, Samsung, and other companies. Much like Healthkit and the Health app on iOS, Google Fit is a set of APIs and services which is accompanied by the Fit application on your Android device. With Lollipop on the Nexus 6, Google has included Fit by default as an application that cannot be uninstalled, which may be to the annoyance of users who don't really care for fitness applications.
That being said, there are obviously quite a number of users who do use fitness applications, as the list of fitness applications and initiatives from both first and third party developers is growing rapidly. The distinction between health and fitness applications should probably be made here, as while Apple's Health app can track and store things like medical information, applications like Fit are limited to tracking exercise. As you can see above, the application is organized as a list of dates, with information about your fitness activity on each day. You can specify a goal for the amount of time you want to spend exercising, and the application will send you a notification when you reach it. The tracking is done by monitoring the various sensors in your device, and you can also input information manually if you prefer to exercise without your phone. I'm not really big on exercise, but during my time using the app it seemed to work reasonably well. I did notice it can sometimes categorize time spent in a vehicle moving slowly as time biking, but that's really just a limitation of how the information is being tracked.
Updated Applications
Contacts
The People application has become Contacts in Android Lollipop, and the design is greatly improved from what was quite frankly an awfully designed interface. As you can see above, Google has given the interface a blue accent color and adopted the circular contact photo style that we've seen on other platforms. They've also cleaned up the interface significantly by consolidating the controls into the top part of the application, and by removing unnecessary parts of the interface like the lines that separated the contacts into sections based on their initials. These changes also improve usability significantly because the simplified interface is now made up of only two sections which are clearly labelled by their name, rather than by 3 icons that do not make it obvious what each section contains.
Calculator
The calculator application also receives a complete visual overhaul in Lollipop. Much like the keyboard, Google has done away with the separate visual keys for each button in the calculator, allowing them to simply float atop a solid colored background. This also allows them to not be constrained by the rules of a virtual grid, which has made it possible to move the delete key downward in the row with the basic math operators. This change means that there's no longer an empty rectangle above the keypad in portrait mode, and more space to enter numbers and operators in landscape. You can also see above how the edge of the overlay with trigonometric, exponential. and logarithmic operators is visible on the right side of the main part of the application, which lets the user know that there is something to the right that they can pull on.
Google has also greatly improved the landscape view. In the previous version, switching to landscape simply put two buttons for parentheses alongside the numerical keys, with the more advanced operators still in a section that you would have to swipe to. This layout didn't do a very good job of taking advantage of all the horizontal space available in landscape mode. With the calculator in Lollipop, the landscape view shows every button in the calculator on a single screen, separated into three separate colored sections. This is a good improvement, although I think it would be helpful if Google implemented some more features, like dedicated keys for the cubic and cube root functions.
Messenger
For a long time, I thought Google had just forgotten about the Android Messaging application. It seemed like users were being pushed toward using Hangouts as their SMS application. Lollipop brings an unexpected new application called Messenger, which is like a better version of the AOSP Messaging app. This is a good example of how what people think of as stock Android on a Nexus device is not really stock Android in the sense of using everything from AOSP. It should be noted that the Nexus 5, which never had the AOSP Messaging app, does not get the Messenger app when upgrading to Lollipop.
Messenger is also an interesting example of an application actually using more grey in Lollipop than in KitKat. The application uses a grey background, with white speech bubbles for messages you send, and colored ones for messages you receive. The color of the receiving ones can depend on if you have a contact photo assigned for the person you're texting or not. If you don't, it sets a random color for the speech bubbles. This makes for an interesting dynamic interface, but it can sometimes result in bright pink conversations that may be unwanted.
Google has also made some interesting changes to adding attachments for MMS messages. The paper clip icon has been moved beside the field for entering your message, and tapping it brings up an in-app camera interface that allows you to quickly take a photo of something and send it. Swiping upward expands the camera preview to the entire size of the display, and tapping the check mark takes a photo of whatever is in view. Google also also added an interface for the Photos app which behaves in the same manner beneath the text input field, and there's now a microphone button for recording and sending audio messages.
There are many more updated applications in addition to the ones I've discussed here, some of which appear in other parts of the review. Some applications which have been redesigned are very similar to their KitKat counterparts, but with new color schemes and small changes to header bars and buttons to fit in with the new Material Design style. Overall, I'm very happy with the updated applications in Android Lollipop. Truly redesigning an operating system requires a lot of work, and a lot of planning. For the most part, Google has avoided creating any inconsistencies by leaving in parts of the interface from older versions of Android, and it results in a new design that feels very thoughtfully created and implemented.
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.