Android 5.0 Lollipop reviewed
arstechnica.com
arstechnica.com
What was once a killer app, a core productivity tool, has given way to an almost unusable interface.
It is now really hard to perform some tasks.
For example, I am a heavy calendar user and I have something in the calendar almost every day. It is now extremely difficult to answer the question: When is a three hour window free in the next month or two?
That used to be a single glance at the month view which communicated to me full day events, part-of-day events, and for the latter which part of the day and how long the event took. A single glance at month view could answer it and I could move forward backwards to glance at the next/prev month.
Old: https://www.dropbox.com/s/kiic7fdrmu65172/2014-11-13%2006.56... (October 2014 in the old v4.4 Calendar app)
To achieve it now, I'd need to use the 5 day view, and for each 5 day segment to scroll up and down as even on my Moto X (2014) I cannot view more than half of the working day.
New: https://www.dropbox.com/s/pgqbhnc1ifp02a9/2014-11-13%2006.56... (October 2014 in the new v5 Calendar app)
Gone is the ability to use Calendar on the phone as the core way to organise your life, it is essentially now unusable on the phone for anything other than a near-term agenda/itinerary.
All of the new Gmail/Inbox to Calendar features? Dead to me, all of my accounts are Google Hosted accounts and none of the Google Now, Gmail, or Inbox integrations with Calendar work on Google Hosted accounts.
I'll purchase it for most of my organisation members too if it works out well.
imo aCalendar is better for phones <5" and sunday calendar for tablets >7".
Majority of their users probably are better off with the new calendar app, so they readjusted it for a better fit. If it turns out this is not the case, they will change it further, maybe bring some old functionalities back.
They focus on what will please majority of their users, as any other company would and should, not their power users.
What's wrong with just ignoring the features you don't need (yet)? All software has a learning curve. The more you use it, the more features you should discover and find useful. Trying to flatten the learning curve by removing features (or making it much harder to discover them) just keeps more users from ever advancing beyond the "novice" stage, because there isn't all that much more to discover.
Power users became power users because they explored and discovered more functionality, and this is because they were motivated to explore in the first place; extremely simplified UIs reduce much of this motivation, which results in less power users - and eventually developers. Maybe "we don't want power users and want them to disappear" is their goal (I hope not but wouldn't be surprised if it implicitly is), but this constant trend of lowest-common-denominator dumbing-down apps is, in the long term, not beneficial to anyone.
Software should have defaults that make it easy to use initially for the beginner, but it should also encourage growth of the user's knowledge. Instead we get software that's easy to use initially - and then effectively stunts their growth, and all the aesthetics they throw at it cannot compensate for functionality. I think it's really quite sad; although if you believe in the theory that Google is aiming to take away user's control over their devices and replace it with Google's, then it makes a lot of sense to keep users as blissfully ignorant as possible. ("You can't easily check your schedule anymore... but look, we gave you beautiful rounded buttons!")
From the parent:
is essentially now unusable on the phone for anything other than a near-term agenda/itinerary.
Looking at the way it doesn't even show the year anymore, "near-term" is right!
I have 5 Google Hosted accounts, and I'm a decision maker on 3 of them. For those 3, calendar to support business processes, resources, availability, scheduling... this is why we went for Google.
Google Calendar in the past few years finally surpassed Outlook. Not only that, but it did it on the web and mobile.
Perhaps I should rephrase, for business users the new calendar app is a significant regression that will harm productivity and will result in customer churn for Google Hosted products.
Perhaps they should offer a personal calendar app/mode in addition to a business calendar app/mode?
> Received the calendar app this morning, it is a major step-backwards
What you describe is not Unix console tools vs. mobile/web apps, but free vs. privative software. The infamous walled gardens.
I know that that's generally poor form, and admittedly a bit impolite, and I apologize..
I was just struck by your example - The Gnome 3 changes seem like a very good argument AGAINST your position!
Many people did not like the UI changes which were brought in Gnome 3, as you mention. After it was released, a group of users who were not fond of the change release MATE which is still very much in development, and (reasonably) widely used. It's included with many major distributions, and very straightforward.
Another group (Cinnamon) originally forked the Gnome2 shell, and then later forked the Gnome3 shell and window manager, in order to restore a more Gnome2 like UI.
In general, I agree that maintaining your own fork is a lot work, and likely not worth it in many cases..
But if it's something that you care about enough to throw hours at it, the option remains open.. And that option is taken more often than you might suspect!
This is a great future that honestly wouldn't have happened if it weren't for the fragmentation and slow update issue that carriers and device manufacturers created. It's like trying to grab toothpaste once it's out of the tube. The harder you squeeze, it simply finds another crack in your hand to go out of.
Material is also fantastic, almost joyful to use. It almost nails the flat-with-a-dash-of-skeu that Microsoft and Apple have both missed. There's still a few too flat bits here and there, but it's a great place to be.
All are an improvement over previous designs, but I don't think complete flatness is very practical.
Something I'd like them to "fix" in material for the next version of Android/style guide is how to combine colors. I think all 3 platforms have issues with this. In Android 5 there are some colors combined that don't make sense (I think the least favorite is the green icons in Settings). In iOS7/8 I've seen apps that basically use a dozen different colors in their apps, and for Metro I've noticed a lot of times that third-party developers but also Microsoft itself choose really ugly colors.
Material design really is great, and for that reason it's a shame that's gonna be inevitably wasted by:
- third party customization by the manufacturers - fragmentation of iOS version on android devices, especially in the entry level market - huge flocks of developers with no sense of design at all -internal fragmentation by the too many Google product team themselves
Looking at the design per-se, you may be right about its superiority to iOS design, but this stuff doesn't live in a vacuum.
At the end of the day, they can still only be "best practices". but developers can and sometimes should create their own unique designs. The other 90 percent of them can simply "copy" Google's style guide, and still have their apps look great.
At least for now, it's possible to access/install the play store even if you're running a cyanogen build -- I'm not convinced that'll last, but we'll see.
I think what I care more about is accessibility. How easy is it for me to build stuff on their platform? Google makes it really easy, Apple makes it really easy. There's a healthy debate as to who makes it easier, but in the end it's not about openness it's about accessibility. If Google replaced their kernel with the most locked down closed source kernel ever conceived tomorrow, but made no other changes, it wouldn't impact that in any way.
And that's what I, and to be honest most developers care about, getting stuff done, which is what accessibility is all about.
I was really hoping they would bring back whatever API made it possible for things like AppOps Launcher to allow you to prevent other apps from accessing things like your contacts, account listing, or location. I was hoping that when they took it away it was because it was intended for release in a future version, but we've yet to see it since.
The problem with coarse-grained control like AppOps is that it can cause apps to malfunction or even outright crash when they try to use permissions that you revoked. This is probably not the kind of behavior that Google would like to enable for the average user.
Personally, I'd prefer a subtler (but possibly more draconian) approach, such as exposing a fake or empty contact list to apps that want my contacts; exposing some random location in the middle of nowhere to apps that want my location; and exposing a fake or empty folder to apps that want my pictures. Grant access to my messages, but never actually notify them when a new message comes in. Grant access to my microphone, but only ever feed them silence. Poor apps will not even suspect that anything is amiss! Is there any way right now to do something like this on rooted phones?
The problem with Android, being a meta-distribution, is that Google has less control over when users (not just Nexus) get version X of Android.
I remember Andy Rubin said Android could evolve more quickly because it was open source. Without debating that, its clear that in practice we haven't seen that when taking into account what users are actually using.
This makes it very difficult for Google to make these breaking kinds of changes to make things better, so entropy keeps accumulating in the platform.
How is the situation with backups and restores nowadays? If I'd have to redo all my settings when switching from an Android to another Android phone in 2016, I'd be pretty sad. I'd even be willing to restrict myself to Nexus devices if that makes a difference.
Oh, also, are there any good Nexus phones with dual simcards? That would be a major reason for me to switch over.
I don't even think about backing up and restoring my Android device. It all just works.
I agree BUT how long will it be before developers implement material design on Android? I've got Android apps still using pre-holo design.
I can totally understand why people for various reasons would like not be in Apple's walled garden or don't like how Apple things work. But Android is a very poor alternative. It doesn't give us the truly open system that we as users deserve. It has a horrible broken ecosystem in regards to privacy, design and annoyance (ads, ads everywhere). Google enforces their own products beyond just "hey look at this cool youtube thing" in a way that is much beyond what Apple does.
Yes I do really like stuff Apple produces but was really looking forward to use an open mobile OS. But the whole experience with Android and Google has left me very negative to use anything from Google again.
How does iOS handle this?
A useless feature, as far as I'm concerned. But on Android, the app will demand access to all of my contacts at install time, just in case I ever wanted to use it. And then I have no idea what else they might be doing with it.
On iOS, the app doesn't have permission to get my contacts until it asks for it. Using Dropbox for your scanned documents instead of the DocuScans sharing system? Then the app will never request permission to access your contacts.
My experience with dual sim cards has led me to believe it's not worth the effort. I'm not sure if it is complexity in the hardware or in the software, but whatever phone I've seen that has this feature invariably has issues with reception and network connections randomly going down.
Maybe it's something like multi-threaded code - where the benefits of simultaneous lines of execution are often offset by the complexities in sharing data.
In the 2G era, the modem was mostly in idle mode. In this mode it sleep most of the time, and wakes up now and then (network configurable, around 1 sec. roughly) to listen for a paging opportunity. The network uses this time slot to send a paging signal to the device if it needs to wake up and reconnect because of a network initiated incoming call. Because the active paging time is very small compared to the sleep duration of the paging cycle, it's pretty easy to handle two SIMs: register serially, and then the paging opportunity are unlikely to clash (and if they do one can play tricks until they don't). Then if a call comes in on one SIM, connect for this SIM. You can't listen to the other SIM paging but it's unlikely you'll get two calls at the same time, and without answer another call will go to your voice mail, which is good. That was dual active dual SIM at the time of 2G, and it was good for the users.
With 3G without data, it's about the same. But with modern 3G with mostly always on, and for sure with LTE with always on data, it's much more tricky. The modem will still go to idle a good part of the time even with always on data, but it'll wake-up much more often and at unpredictable times. Also, there are other low-power modes that can remove the need to go to idle for arbitrarily long durations (like connected DRX in LTE for example). It's just not safe to mux two active SIMs in this environment.
So in short: forget about dual active SIMs with 4G. You can still have dual SIM slots, with a user controlled switch and only one active at a time. But it's not as convenient.
Isn't that how versioning works generally?
> Since Dalvik only compiled at runtime, the compiled code was never written to disk. [...] This would lead to a lot of disk thrashing [...] Since ART is already compiled, the compiled code can be paged out to disk
(emphasis mine)
It's funny that we still call disk any slower, non-volatile memory (and it's even funnier to imagine an Android phone with an actual disk).
1. Ability to change exposure settings without purging the imaging pipeline, making exposure bracketing and high-FPS shooting faster and better.
2. RAW capture; phone lenses are improving but will always be limited on account of their dimensions, so having the RAW is even more important in trying to improve images than in a compact camera. Every little helps...
Looking forward to camera apps that take advantage of these new features.
Good news. Not sure if I think it is good news that you can pair the (presumably ok) encryption with face-unlock... though. Seems like it's not possible to (easily) brute force a disk-image off-line any more at least:
http://blog.kaspersky.com/full-disk-encryption-android-5/
“In addition to enabling FDE out of the box, Android L is expected to include hardware protection for disk encryption keys, as well as hardware acceleration for encrypted disk access,” Elenkov concludes. “These two features should make FDE on Android both more secure and much faster.”
Now we'll just have to wait for the source code, to see if this will be usable by all "tenants" on Android hardware... I hope so -- I'd love to be able to drop to a simpler unlock key, knowing that it's eg: set to self-destruct/severely rate-limit after N tries.
http://niki.hammler.net/wiki/Android_Device_Encryption
However, please note that I have not yet reviewed Android 5.x's FDE.
Either way, for a device like a phone, I'm pretty sure TPM is the way to go. Alternatively a strong pass-phrase to unlock/boot, and a hard limit on attempts to unlock the lock screen before the device turns itself off (or at least "guarantees" that the disk is unmounted and the key wiped from ram...).
Updates:
Status: Released
Labels: Restrict-AddIssueComment-Commit
Comment #4444 on issue 67570 by jshar...@android.com: Android 4.4 Samsung Galaxy s4 external sd card is now read only, Remove or option to edit non app files.
https://code.google.com/p/android/issues/detail?id=67570
Hey all, in KitKat we introduced APIs that let apps read/write file in app-specific directories on secondarystorage devices, such as SD cards.
This gives apps broad, powerful access to manage files while still involving the user in the initial selection process. Users may choose to give your app access to a narrow directory like “My Vacation Photos,” or they could pick the top-level of an entire SD card; the choice is theirs.
To make it easy for developers to transition to these new APIs, there’s a new DocumentFile support library class. It looks and feels just like a traditional java.lang.File object, which makes it easy to adapt existing code:
http://developer.android.com/reference/android/support/v4/pr...
These new APIs aren’t just limited to shared storage; they can be used with any DocumentsProvider that adds support for Root.FLAG_SUPPORTS_IS_CHILD, such as the advanced Vault example:
https://android.googlesource.com/platform/development/+/andr...
If you're an end user, please reach out to app developers to ask them to start using these new APIs. With these new rich APIs in place, this issue is considered fixed.
[0] https://code.google.com/p/android/issues/detail?id=67570
However, there are some inconsistencies - besides the Calendar app heavily described here, the Contacts app on my Nexus 7 has some weird design choices.
Firstly, when viewing a contact, there is no back button in the top left - you need to use the system back button, or drag the card down. Secondly, when adding a new contact, the checkmark button is in the top left, and to discard you need to go to the top right overflow settings button, and choose discard changes (the only option in the overflow). Completely counterintuitive (top left for Create, top right for discard), and the opposite of the Gmail app's Compose window (which uses the standard layout).
I'm happy to go back to the K-9 Mail derived apps which I've always used...but I was hoping that the new GMail design would be easy on the eyes (since I spend much of my phone time reading e-mail). Then again, now that I think of it there's no real "archive" support for non-GMail accounts in the GMail app either, so maybe it's more of a hack.
(and no, i don't want to have to download other apps, tweak this and that to achieve the desired outcome. It should be standard)
It'll pop up links to apps if you search for their names, and it can just open them directly if you say something like "open app hacker news." There are also a few that integrate with other magic spells for voice search - mostly it's Google apps, but the Spotify app is registered as a provider of music, so I can say "play Radiohead" and the system will open Spotify and start playing.
The app permissions system on Android is all or nothing. Which I think would benefit from a more rigorous approval process. All the access is disclosed though before install.
Glad the world has options.
Personally I prefer them not doing anything like that, though, because I'd like them to stay out of this vicious patent war circle. But it's a shame that means the war has to be one-sided. Apple and others can fire at them, but they can't fire back.
Really scary if that's due to patenting though. Does that mean the patent covers all desktop style search as well? Or is "for a square device that fits in a pocket"-type thing?
[ed: Ok, it's not as gone as I thought, it's just slower than it should be (to get hit in eg: contacts). Still I seem to recall you could get hits in eg: emails from k9 before?]
[0] https://android.googlesource.com/platform/packages/apps/Quic...
The core ideas taken from the concept of "paper" are stacking, layering, print-design-style blocks of color, and the idea that things can be shuffled and moved but cannot instantly appear and disappear in/out of thin air. That doesn't mean it's literally trying to be a pile of looseleaf, just that it's mimicking those abstract concepts from the real world in an attempt to make the interface intuitive and less "magical" (in the negative sense).