Hacker News new | past | comments | ask | show | jobs | submit login
Android 5.0 Lollipop reviewed (arstechnica.com)
159 points by jonathansizz on Nov 13, 2014 | hide | past | web | favorite | 84 comments



Received the calendar app this morning, it is a major step-backwards.

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.


  > Received the calendar app this morning, it is a major step-backwards
It's crushing when this happens. There's this thing that's part of your life, and then forces beyond your control sweep in and destroy it. I think this is the root of the reason that gadgets and new things have lost interest for me. In the past whenever I've invested in them I've been setting myself up for unhappiness down the line when it's dropped. Unix console tools are pretty messy but free of this. Tweak them once, you have them for life. We don't yet have a web or phone equivalent of that tradition.


Once again, Stallman was right.

What you describe is not Unix console tools vs. mobile/web apps, but free vs. privative software. The infamous walled gardens.


Well, it happens with free software as well. See the Gnome 3 uproar. Yes, you can keep using the old version until bit rot takes it. And yes, you can fork it -- good luck with that.


Please forgive me, but I'm about to focus on your example, rather than addressing your larger point.

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!


Have you tried Today Calendar? There are plenty of alternatives. I do agree that the new calendar is pretty crappy on a phone.


Thanks, I have just purchased it.

I'll purchase it for most of my organisation members too if it works out well.


you should also check out aCalendar.

imo aCalendar is better for phones <5" and sunday calendar for tablets >7".


This one is working out even better.


Wow, that is a pretty drastic change, did they not consider this use-case or something?!


Drowned under the trumpet of flat design


The screenshot of the old calendar looks pretty flat to me.


"Received the calendar app this morning, it is a major step-backwards for me." FTFY.


I think this is what people overlook most of the time. I did not use the calendar app because it was overloaded with things that were completely unnecessary for ME. Now, it is much simpler, might start using it.

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.


I did not use the calendar app because it was overloaded with things that were completely unnecessary for ME. Now, it is much simpler, might start using it.

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!


Sure, but I'm a business customer... I pay.

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?


Pure conjecture, but at some point, Android is basically just going to be the Kernel and a distribution medium. Everything else will come from the Play store, the GUI, device drivers, the fonts, the apps, the clock, core APIs, the runtime, everything and the OS will simply move to rolling partial updates. Version x simply won't be meaningful anymore and the kernel can stay static for years and years.

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.


How is it great? You'll be stuck with all decisions Google make for their average user, weather you want or not. In fact, once they lock down the user-land, what's to stop them from moving to a FreeBSD derived kernel, and we'll be left with only Mozilla (and maybe Canonical) trying to provide a viable open platform?

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've been giving this lots of thought recently, with all the changes to Android. I frankly don't really care all that much about the politics behind open/closed software. It's almost never been a deciding factor for me and I've been bit and blessed about as many times by stuff from either camp. I also know that right now and in the near future, if Google completely closed source Android today, it wouldn't impact me in the slightest because there's really only two viable mobile OSs at the moment, neither of which I spend any time mucking around with the source on -- and neither of them are built by Mozilla.

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.


IOS 7 and 8 are all but flat. Translucency instead of shadows, but still. The iOS design needs to be perfected in many ways, but I think that the not-complete-flatness was nailed from the get go.


In my opinion Material > iOS8 > Metro.

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.


Unfortunately you can't really control the way third party devs will adhere to your design Guidelines. Under iOS, at least, it's easier to notice a general common sense, especially for the most used and popular apps.

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.


Yes, of course, but Google could at least advise them as best as they can - do that UI/UX research so the developers don't have to, and so on.

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.


Just a quick skim through, lots of neat features but it doesn't look like there's a lot of privacy-oriented ones, which is rather disappointing.

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.


AppOps is still alive, though you'll need root in order to access it.

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 CyanogenMod OS has this built in. Very similar to what you describe (provides empty contact list, empty folder etc to apps you specify). Don't know if there's a standalone app to do the same.


> 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.

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.


AppOps is hardly a solution. It's a very complicated interface for what should be a "Do you want to allow ..." yes/no question.


Unfortunately not. Making this available is a lose-lose for Google: It will prevent collection of personal data which their business model relies on, and break apps which will diminish the user experience and reflect badly on Android.


IMO they should take some cues from IOS and allow users to allow/disallow such things when apps make the requests, not dump all permissions as allow all or none when users install the apps.


IMO this all-or-nothing mentality when it comes to installing apps is the single biggest problem with Android right now, trumping even the perceived fragmentation problem.


Doesn't look like it, and they actually promised a more advanced permission control at I/O this year.


As an iOS user since the 3GS, I have to say this is the first time I find Android to look significantly better and more usable than iOS, which IMO has regressed since iOS 7.

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.


As a recent convert from 3GS (yes iOS6) to Sony Xperia Z3 Compact I strongly disagree. There is so much weirdness in Android that I don't even know where to begin. A big chunk of it is the ecosystem though but Google is to blame here as well. Mainly for the lack of privacy (seems like 70% of apps I try to install wants access to my contacts at install-time. And the design. Oh god how many ugly things in the Play Store). The openness is Android isn't an openness in practice. You would assume CalDAV and CardDAV would be a native feature like in iOS. Nope. You would assume you could uninstall non-critical apps. Nope. You would think 1Password could integrate itself to Chrome like on iOS? Nope. The back button is a story in itself. Go back? Exit app? Go to another app? The russian roulette back button got you covered. The way of selecting text in various places is also implemented in a similar mysterious way. And then you have whoever made the phone (Sony in my case) adding shit. Not only apps but core behaviours. When I long press on the home button Sony decided that Google Now could be easily available. Which is useful. But also they have Sony Whats New which is some weird little app that showcases some various content for sale from Sony. On the main button on the screen.

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.


Thanks for your feedback. The thing about permissions being an install time decision is also what makes me weary about Android - I imagine it would happen quite often that I have to make a decision between using an App that would be really useful or even required right now and giving it my addresses, which I really don't want. That's something iOS does much better and I wonder how much of a downside it would be in real life usage.


> seems like 70% of apps I try to install wants access to my contacts at install-time

How does iOS handle this?


Not parent, but: it asks for every permission separately at runtime (on first time usage). That might seem a hassle, but IMO it's much better this way. Apps tend to be much more conservative in order to not disturb their users too much with permission questions, and they also have fallback modes for every permission that's not critical - a Maps app will still work without location data for example.


To give an example, consider a document scanning app that has a feature where you can sign up for a DocuScans account and use it to share scanned documents with other people who use the same app.

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.


Issues a permission confirmation the moment the app tries to access contacts (once).


Just in time pop-up to authorize when the app ask for it.


I recently upgraded my Note 2 to a Note 4. One of the first things it asks when you first switch on the phone, is to log into your Google Account. After that it asked a couple more questions. By the time the install wizard was done, most of my phone had been restored: Apps Contacts (including favourites) Emails (they live in the cloud) Photos Music Even things like WiFi passwords, preferred hotspots, etc.

I don't even think about backing up and restoring my Android device. It all just works.


>> "As an iOS user since the 3GS, I have to say this is the first time I find Android to look significantly better and more usable than iOS, which IMO has regressed since iOS 7."

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 saw an article on migrating android phones earlier today: http://lifehacker.com/5843206/how-to-upgrade-to-a-new-androi...


Oh, also, are there any good Nexus phones with dual simcards?

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.


Thanks. A shame, I've never had a dual sim phone, but people told me about older Nokias being quite good at that. Now we've finally caught up to the old SMS-from-desktop connectivity from back then (with iMessages), I wonder how long it's going to take until we have all the features back from the pre iPhone era. In mobile just like in desktop computing, the history seems to repeat itself every 15 or so years.


Dual SIM is working fine with 2G, but not well with always on data. What's important to understand is that those dual SIM devices only have a single radio, that must be shared between both SIMs. And that's not part of the standard, so one has to play some tricks.

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.


I actually don't need it for data on both SIMs. I would be fine if the device would just let me choose which SIM to use for the data connection. My usecase would be one SIM used for roaming to be reachable under my usual number when I'm abroad, the other SIM could be a rental in my host country, used for data and outgoing calls.


"For existing Android users, the next step after signing in is to restore your Android settings and apps"


This is the first version of android where I thought they totally outdid apple, at least superficially. I'm just disappointed that I no longer have any decent android phone to use so I can form an actual opinion on Lollipop.


The latest Moto G has dual-sim versions. I've never used it, but it's what I'd buy if my Nexus 4 got lost or broken.


"Android 5.0 Lollipop is at least the biggest update since Android 4.0"

Isn't that how versioning works generally?


I took it to mean that 4.x to 5.0 has been the biggest major-to-major update.


Yeah it's obvious what they meant, but they probably could have worded it better.


This paragraph made me smile:

> 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).


This is an extremely thorough review. Tough to say anything negative. Huge fan of Google Material design and have been using a lot of it for my native app designs, and my users have frigging loved it. Also transferring a lot of this into desktop (web) design as well and getting lots of great feedback.


I like Material design a lot too, but I don't like how branding is mostly done through colors now with no icon in the action bar. Since everything is flat now, it makes all apps look too similar to each other.


One of the most significant changes in 5.0 is the new Camera API, which will introduce two major benefitting photographers:

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.


"Devices that ship with Android 5.0 are encrypted out of the box. If you set a lock screen, you're given the option to require a security challenge before the device turns on. Enable this and a PIN, pattern, or password prompt will come up even before the boot animation. After you pass authentication, the device decrypts the data partition and mounts it, allowing the device to fully boot."

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.


In 4.x, the decryption password is the same as the unlock PIN. I'm hoping it's possible in 5.x to separate the two, so that the password can be stronger than the PIN.


It actually never had to be; if you're rooted you can set it fr the command line.

http://niki.hammler.net/wiki/Android_Device_Encryption

However, please note that I have not yet reviewed Android 5.x's FDE.


Thank you for that. Right now I'm running stock Samsung rom on my Note 3 (thought I'd wait for cyanogen to mix it up with 5.0 before flashing). But at least then there is another option than what I do now, basically a compromise that combines the worst of both worlds: a password/phrase that is too long to be convenient to type in to unlock, and probably too weak to offer real security, assuming the encryption key is generated via a straightforward derivation (not sure if there is any decent stretching involved?).

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...).


The most important feature: Full access to the SD card has been reenabled for apps after the public outcry[0].

  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.
We heard loud and clear that developers wanted richer access beyond these directories, so in Lollipop we added the new ACTION_OPEN_DOCUMENT_TREE intent. Apps can launch this intent to pick and return a directory from any supported DocumentProvider, including any of the shared storage supported by the device. Apps can then create, update, and delete files and directories anywhere under the picked tree without any additional user interaction. Just like the other document intents, apps can persist this access across reboots.

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


I still feel that offering desktop style access to the file system is a mistake. The file system is way too complex for a normal user and since developers can put files almost anywhere it is usually a total mess. I would much largely prefer a personal sandbox for each app : their own folder in Android/packageName like they can optionally use right now. On top of that, add an API to grant access to shared folders for music/photos/documents/misc files.


Good review. I really love Material, and would place it above iOS 8's design guidelines after using and developing apps for both.

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 have tried to port my IMAP email accounts into the new GMail. As far as I can tell, there's still no support for IDLE and the phone constantly suggests a "sync time" for my accounts. I guess my phone checking for mail every 1/5/15/30 minutes shouldn't bother me with the new job scheduling upgrades etc. but it does feel half baked.

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.


just my 2 cents, but my biggest grips are still no universal search, ala spotlight; and privacy controls for each app, for each function. If they fixed those i'd switch.

(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)


Universal search (once a part of Android) has long been stripped out due to patent issues with Apple.

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.


Oh, is that why it's gone? I just recently realized that the search (which I never used, much anyway) didn't actually work any more.

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?]


Was it definitely a patent issue? The change [0] was originally claimed to be the result of performance issues.

[0] https://android.googlesource.com/platform/packages/apps/Quic...


Rather ironic that someone has an advantage over Google for universal search.


Unlike Apple, Google isn't so keen on enforcing its patents. Do you really think Google doesn't have hundreds of search related patents that they could use against anything Apple does with search, including Siri?

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.


Isn't always on voice search (which is always listening on suitable hardware such as Nexus) and regular search from the Google search bar including results from the supporting apps a universal search?


I've never seen an app result in those listings. Maybe no apps support it, or it is very hard to see the app results.


You definitely get app results in the listings for apps that are installed, a la Spotlight. This is an example of what I get when I use the Google search bar on my phone with a query of 'ch': http://i.imgur.com/UdqXvNm.jpg


What are you expecting to see in the search results?

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.


all of your favorite settings here are never going to be standard, unfortunately.


I am one of those people who always felt that Android didn't look nearly as good as it was feature-loaded. Feeling that I could always do pretty much anything with a powerful Android phone, I'm happy to see Google taking a serious big swing at design.


In my opinion, the level of stretching and radially-wiping animations in material design is completely at odds with Google's claim that the central metaphor is paper/cards. While I like most of their redesigned applications rather a lot, even if I try to force myself to see them as sheets of paper, I cannot, as the widgets actually behave almost nothing like paper.


That's why it's a metaphor, not a strict skeumorphism.

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).


Good review, I agree on all points! But no mention of the new keyboard design where the borders surround the letters have been removed. On my Nexus 5 I am making significantly more typos than usual. Anyone else notice this?


How is the lag? Still a lot of stuttering everywhere?


Better. Flawless almost everywhere, couple of places which can still drop a frame or two in specific situations - but iPhones do that too.


Thanks. Sounds great!


Maybe not the place to ask, but why is Calculator part of the core OS?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: