This summer I got a new car, my first with Bluetooth. Since then I’ve been refining the in-car experience with my smart phone and it led me to a conclusion about the state of the market in cell phones.

I had a car mount with a nice mechanism for one-handed load and release. And before I had Bluetooth having to hook up power as well as audio wasn’t that big a deal. But now that my phone audio connects with my car wirelessly, having to connect the USB for power seems a chore. I have a wireless charging case that I use with chargers on my bedside table and desk so I found a car mount by iOttie with a wireless charger built in.

With that dock, I can get in my car, put my phone in the dock, and it starts charging. If I have a podcast or music player paused, the presence of Bluetooth usually causes it to resume. So far so good. My home screen includes Google Maps for navigation but I usually have GPS turned off to save battery so actually navigating means getting to settings, turning on GPS, and accepting — for the 1007th time! — the terms of the location services. I thought there has to be a better way.

I’ve had phones with matching car docks that could tell they were in the car dock and run a car mode app. My current phone does not. I needed some way to make my phone know it was in the car (ideally, knowing if it was still in my pocket or put in the dock) then change settings (e.g., GPS on) and run an app (a third-party “car mode” or “dashboard” program). Bluetooth presence was one option but that couldn’t distinguish between dock and pocket. Another option was NFC tags. I had a packet of WhizTags so I decided to see what I could do with them.

The WhizTags folks recommended NFC Tasks which I found kind of awkward. I’d heard good things about Automate and decided to give it a try. Automate seems like a fairly flexible graphical programming environment. The limitations I run into are in the Android OS.

I want to set up “when the NFC tag in my car dock is tapped, turn on GPS.” There are recipes (or “flows”) available on the Automate community site to do that but they require “superuser” privileges; that is, you need to have “rooted” your phone. At least one dashboard I tried has a setting to enable GPS when it starts up so you’d think I could have Automate start the app when the tag is seen and have the app turn on GPS. But when the app starts up, the OS intercepts the attempt to turn on GPS and prompts me to confirm. The whole point is to have this all be automatic so this confirmation is a show stopper. If the confirmation had a check box for “always do this” I could work around it, but it doesn’t so I can’t.

I’d also like to be able to set up “when my phone is undocked, turn off GPS” but here I run into multiple problems. NFC seems to have no way to detect leaving the proximity of a tag; it’s not designed for that. Looking for options, I realized that taking my phone out of the dock and turning off my car happen pretty much at the same time, and turning off my car turns off its Bluetooth. So if I could react to Bluetooth disconnect, I’d have a reasonable heuristic for “undocked.” While Automate has a “Bluetooth device disconnected” trigger, when I try to use it I’m told it “isn’t officially supported by Android.” And, of course, even if that was supported, turning GPS on or off is a privileged operation.

In some sense, some of these difficulties arise from the fractured nature of the Android market; a monolithic or tightly controlled system like iOS would have fewer of these problems in coordinating software from multiple sources. But the deep issue here is that Google, Motorola, Samsung, LG, etc. don’t treat smart phones as the computers they are. Computers have a way for competent users to perform privileged operations. Windows has User Access Control. In Linux we have sudo. In stock Android the closest we come is being allowed to install programs from locations other than the Google Play store.

To have full access to the computer you own — a computer that happens to make phone calls — you need to “root” it by a method fraught with difficulty; every device has a different method, it doesn’t always work, and it has the potential to make the device unusable. What we need is a setting in Applications or Security for “allow root access” which just works out of the box. Typical users would never check — perhaps never find — that check box and their phones would continue to work as they do now. But “power users” could make full use of their pocket computer without jumping through hoops and something as simple, natural, and obvious as turning GPS on and off wouldn’t be a challenge.

I really believe that the device maker or carrier that realizes this will have a loyal following; it will provide the device of choice to people who want to make full use of their phones. (Perhaps one has tried and no one noticed or there were other reasons the device was not welcomed.) In my wildest dreams, someone at Google makes it a core part of Android N and even goes so far as to not allow it to be disabled in OEM versions. I can dream. In the meantime, I’m just frustrated.