android 5.0 | writing about tech

Tag: android 5.0

My increasing frustration with Android in a single screenshot

Let’s be clear – I like Android, a lot. The freedom it provides is still unparalleled, even with iOS8’s recent strides towards being more open.

Now, with that said…the last couple of weeks have tested my patience with misbehaving technology. It started with the way Lollipop handles notifications and has been further exacerbated by an issue with Lollipop on the Moto 360 that makes notifications unreliable. Yes, you read that right: somehow Google (or Motorola, or both) managed to release a smartwatch update that broke the core functionality of a smartwatch. Nailed it, guys.

These little glitches have been adding up, especially as I look toward getting a new phone in 2015. I’m not going to lie: I’ve been tempted to run out and buy an iPhone 6 Plus on more than one occasion, and it’s not out of love for iOS, but out of frustration for the maddeningly inconsistent experience on Android. Android is great! You know, usually. Until it isn’t.

Tonight was close to being the proverbial straw that broke the camel’s back. It wasn’t even anything new, but just something I’d seen happen before – an event that had its significance increased by other recent frustrations. A few hours ago, my phone’s battery randomly decided to eat itself, even though I wasn’t using it, and it was on WiFi the whole time:

2014-12-30_2006.13.57.0.png

The detailed usage stats are useless, as usual, only telling me that “Android OS” was responsible, without giving any further explanation as to the actual root cause.

This is simply unacceptable. Fortunately I was home and didn’t need my phone tonight, but what if I had? Why does Google think it’s okay for a rogue process or app to completely hijack my phone? Ideally the OS itself would detect and deal with this scenario, but it’s not even trying. The least it could do is warm me that hey dude your battery is draining really fucking fast you might want to do something about it.

Did a reboot fix this? Yes. Should I have to reboot my phone to fix this? No, of course I shouldn’t. That’s insane. There’s nothing I can do with a reboot that Android shouldn’t be able to do on its own. Either a third-party app is being allowed to run completely out of control, and that behavior is being reported as “Android OS” or the OS itself is doing something awful, which is even worse.

Where do we go from here? I honestly don’t know. I’d like to wait and see where Google takes Android 5.0 in the next couple of months. I love the freedom Android gives me, and I love that I can set up my phone to match my own ideal workflow.

But you know what? I’m also tired of having to micromanage my phone just for the benefits of that freedom. This process and battery management stuff is just one example of something Google should’ve worked out years ago; not something I’m still fighting as we reach the end of 2014.

PushBullet is the missing element of stock Android

December 18, 2014 / Jason Kallelis / 0 Comments

Although I’ve yet to experience it personally, I am a huge fan of Apple’s concept of Continuity – the core idea being that, while you’re using a computer, your phone becomes a glorified router for text messages and phone calls.

As an Android phone user, I am hoping Google will answer with a similar cross-platform solution – but while I wait, a third-party has stepped in to fill the gap with an app called PushBullet. Many of you probably already know what PushBullet is, but if you don’t: the short version is that it started as an Android app (and Chrome extension) that allowed you to send data between your devices. However, over the last year or so, it has evolved to become quite a bit more. My two most common uses are:

Notification mirroring between Android and Chrome. Any device running Chrome can view and, as of two days ago, interact with your phone or tablet’s notifications. Want to dismiss a notification? Done. Want to archive or delete an e-mail? Done. Any of Android’s built-in notification actions show up as options in the notification pop up.

Send and receive text messages from your computer. I personally use a combination of MightyText and PushBullet for this, as PushBullet doesn’t yet support MMS messaging, but it’s enough for basic messaging needs. You can quick-reply directly from a notification or send a new message from inside the extension.

There is also plenty more PushBullet does that I personally haven’t used, such as Universal Copy/Paste, Notification syncing between Android devices, and sending files between your computer and your Android device.

PushBullet’s existence really highlights the key difference between iOS and Android: iOS is rigid, so if you want this sort of functionality, it has to be baked in by Apple, the trade-off being that when it does come, it’s (usually) done very well. Android, on the other hand, gives third-party apps enough flexibility to fill in some of those functionality holes. An app like PushBullet or MightyText just can’t exist properly on iOS, at least not without jailbreaking – the APIs just aren’t there.

This is, perhaps, why I lean towards using a more open, flexible device as my global “router” – there continue to be areas where Android isn’t as polished as iOS, but even today, Android can just do more. It’s unfortunate that third-parties sometimes have to fill in the functionality gap, but the very fact that developers can is just as important to me, if not more so. In a world where my smartphone is less of a phone and more of a glorified mobile data router that I can leverage on any number of other devices, I find the functionality of that router is more important than how fluid the UI is.

As nice as that flexibility is, this is the sort of incredibly convenient functionality that Android – like iOS – should really just have built-in at this point. A logical step would be to expand the new multitasking view in Android 5.0 to include activities on all your devices, not just the one you’re currently using it. At this point, though, I’d settle for Google to simply purchase PushBullet and implement the same functionality at a native-level. I shouldn’t have to download an app or install a Chrome extension; it should just work between any instance of Chrome and Android that I’m logged in on. That’s the dream, at least.

Google needlessly fucked up Android Wear notifications in Lollipop

December 16, 2014 / Jason Kallelis / 9 Comments

Over the weekend, I decided to flash a shiny new Android 5.0.1 ROM on my HTC One, and it’s been mostly great, except for one thing – it’s changed the way I use my Moto 360 (also running Android 5.0) and not for the better.

The details on how things have been changed has been covered in greater detail by Android Central, but the tl;dr is my standard setup of “silence the phone only get notifications on my wrist” – something you’d think would be simple – is broken, for a couple of reasons.

The first reason is that Google arbitrarily decided that I want to have the same notification setting on my watch as I do on my phone. But…why? Aren’t there completely reasonable situations where I’d want my phone muted but still get notifications on my watch, or vice-versa? Apparently not in Google’s eyes.

The second reason is that Google also arbitrarily decided to replace “Silent” mode (a standard feature on phones for who-knows-how-long) with “Priority” mode, which is great in theory but frustrating in practice. This effectively silences all notifications except the ones I specifically allow through, which would be great if it wasn’t also putting my watch in priority mode.

The key to this seems to be the “Mute Connected Phone” feature option in the Android Wear, which unfortunately at this point seems to only work when it wants to, which, as far as I can tell, is entirely random.

Muted by Android Wear! You know, maybe. We’ll see. Honesty, probably not.

Nothing quite like seeing my phone claim it’s muted by Android Wear, only to then vibrate or make a sound. Nailed it, Google.

I realize my complaints are pretty specific, but I imagine the use-case I describe for Android Wear is actually a pretty common setup, if not the most common. Why would I ever need my phone to make a sound or vibrate if I have a connected watch? Sure, give me the option if I really want it, but muting the connected device should be the default, not something that, as of this writing, doesn’t even work.

Also, I’m not sure if it’s a related bug or not, but sometimes my watch decides it doesn’t want to buzz anymore, which, well, is a pretty frustrating flaw in a device whose primary purpose is to notify me of things.

I love many of the things that Google does, but find myself constantly baffled by why they feel the need to change things that aren’t broken. You know what worked fine? The Sound/Vibrate/Silent modes that have existed in Android for years, and separate notification settings for my watch and my phone. Sure, add a Do Not Disturb option if you want to, but that should be an additional feature, not something that replaces what everyone has already gotten used to.

In the past week, my phone and my watch have both been “updated”, yet I feel like my personal workflow has taken a step back, not a step forward. Get your shit together, Google.

Android 5.0 (Lollipop) Early Impressions

October 22, 2014 / Jason Kallelis / 9 Comments

A couple of days ago, I finally gave in and flashed the latest Developer Preview of Android 5.0 to my Nexus 5, as I’d read that it was pretty stable and close to final release, and I’m not a terribly patient person. So far, I haven’t regretted it – it’s pretty bug-free for a product that’s still technically a “preview”. Here are some bullet-point-based impressions thus far, though keep in mind some of this could change with the official release in November.

The overall UI feels even more consistent than KitKat, though some of that is hampered by the fact that even some official Google apps still haven’t been updated based on the Material Design guidelines. While this will almost certainly happen sooner rather than later, it doesn’t change the fact that Google has no control over when third-party developers update their apps, assuming they ever do.
The UI animations are, unsurprisingly, pretty fantastic. However, they also seem to impact performance slightly. There’s often a noticeable pause when I it the Home or Multitask button that simply wasn’t there under KitKat, and I think this may be due to the fact that the OS is delaying the actual action so that the animation can play smoothly. However, this could also simply be because it’s preview software. I’ve also noticed some animations, like changing homescreens, can occasionally hitch – but again, preview software. One of my favorite new animations is that opening Google Now from inside another app displays an overlay on top of that app:

A nice side effect of UI-wide animation changes are that certain interactions (tapping notifications, app controls, widgets like DashClock) inherit some Material Design styles without the developer having to do anything. It certainly goes a long way towards the overall goal of UI consistency.
I wasn’t sold on the new task switcher until I used it, but it’s growing on me. It’s fun to use, and perhaps more importantly, it persists between reboots and goes back way, way further in your execution history. There’s stuff currently in my task switcher that I opened early yesterday.

Some of the issues I’ve had with Bluetooth media controls seem to be resolved, though occasionally I’ll still hit play/pause or track forward/back on my Bluetooth headset and the phone will take awhile to respond. It’s a shame that Android still lags behind iOS when it comes to media playback integration at the OS-level.
It won’t connect to my work WiFi – both my co-worker and I are having this problem. Again, could be because it’s a preview build. It works fine with every other WiFi network I’ve tried.
Because I have an Android Wear watch, and had a Pebble before that, I generally keep my phone on “Silent”. Though this mode still exists in Android 5.0, it functions differently and took me a bit to figure out. Rather than going from Vibrate to Silent, you go from Vibrate to Priority Notification mode. At first, I thought this was like the Do Not Disturb mode available on other phones, but it’s a bit different. Despite the name change, this performs more-or-less the same way Silent mode does in previous versions of Android, with the exception that certain apps are still allowed to vibrate when notifications come in. In theory, if you disable all exceptions, it’ll perform identical to how Silent Mode used to.

Speaking of Android Wear, media controls do not currently appear on my watch. I assume this will be fixed prior to the official 5.0 release on November 3rd. Unfortunately, until then, I can no longer feel like a wizard by pausing my TV or changing party music from my wrist.
Smart Lock, “borrowed” from Motorola’s “Trusted Device” concept, is great, especially if you have a Bluetooth device that’s always with you, like a watch or headphones. It works exactly as advertised – if any of your trusted devices are connected, you can bypass your lock screen security. There were apps that handled this before, but they weren’t as elegant, and only worked with PIN locks – not pattern locks or face locks. In addition, whenever you connect a new Bluetooth device, it asks you if you want to add it as a trusted device – very cool.

The notification changes in Android 5.0 solidify Android’s place as King of Mobile Notifications, as least for my needs. The lock screen notifications, borrowed from iOS, perform perfectly, and it’s great to be able to interact with notifications directly from the lockscreen. Media controls now appear as the media control notification, rather than a dedicated screen, which I think works better, especially with the unfortunate removal of lockscreen widgets. That said, the presence of notifications on the lockscreen means that my main lockscreen widget – DashClock – isn’t really necessary. It still makes a great homescreen widget, though. I also prefer the drag-down-twice to reveal notification toggles, as compared to the previous method of tapping a small touch target, especially since the second drag down can be done from notification. I’m also grateful to finally have a Torch/Flashlight toggle, though it’s still a shame that you can’t tweak the list of toggles. Finally, tapping the toggle actually turns it on and off, as expected, rather than acting as a shortcut to that setting area. The setting area is now reached by tapping the name of the toggle.

Overall, I’m pretty happy with this update to the Android experience. It actually feels a bit like stock Android married to some concepts from HTC Sense – it’s almost the best of both worlds. A great example of this is in the new lockscreen, where you unlock the phone with a slide-up gesture rather than the classic lock ring we’ve seen since (I believe) Android 4.0.

The big question mark will be developer support – the stock Google apps that have been updated look fantastic, but it’s up to third-party developers to take the ball across the finish line and really make Material Design a thing beyond just the stock Google experience. I’m thrilled to see Google bringing their diverse product line under a single design banner, and while it’s an important part of the equation, it’s far from the only part.

Given the history of third-party developers on Android, I’m sadly not all that optimistic we’ll ever see a big Material Design push, especially from stubborn players like Facebook and Twitter, but hopefully the smaller apps I use on a daily basis – Wunderlist, MyFitnessPal, RunKeeper, and Pocketcasts, for example – will join the party sooner rather than later. Thanks largely to the differentiation between Android OEMs and the staggering of OS updates, you’re never going to open your phone and see two dozen updated apps from prominent developers, the way you often do for a few days after major iOS releases. It’s a shame, but it’s also the reality of Android.

Regardless of these hiccups, I’m more excited about the future of Android that I ever have been in the past, and it’s going to be interesting to see how Material Design evolves over the next couple of years as app developers and OEMs find ways to incorporate it into their own software.

writing about tech