71–80 of 115 posts
Earlier quoted context omitted.
Option 1: DRM concerns (exploiting the "analog hole" on digital level, or HDCP restrictions - how deep is HDCP actually enforced in Android?) Option 2: Privacy (call recorders come to mind - unrelated: does anyone know of a working call recorder?)
I can record calls on iOS
Another opportunity wasted to create a unified Android driver model that would allow easy upgrades.
The Android driver model is not what holds back updates. Time and monetary cost of OEM customizations, subsequent carrier bloat, and testing (all performed in series) are what hold back upgrades.
Take Android Wear. It took the DAL approach. As a result, O/S upgrades are immediately available to all devices (awesome!). But there is very little differentiation - all Wear devices use the same small set of SoC's and peripherals, and are functionally the same. Google decides on HW innovations.
(This was true of Wear 1.0, not sure if changed with Wear 2.0)
Earlier quoted context omitted.
I look at these previews as an example of things to come 3 years from now. I keep hoping that Google will figure out a solution to that (restrict access to Play Services, say). Until then, I guess I'll continue targeting API 16.
Until then, I guess I'll continue targeting API 16. I started targeting API 19 (4.4, KitKat) over a year ago and have never looked back. That encompasses the vast bulk of Android users (>85%) and encompasses almost all of the significant developer improvements. Even using the absolute latest fun such as multiple windows is an absolute breeze from the development side, regardless of many users not supporting it yet. A…
"App crashes on open when using my 1989 car phone, 1 star"
Earlier quoted context omitted.
I look at these previews as an example of things to come 3 years from now. I keep hoping that Google will figure out a solution to that (restrict access to Play Services, say). Until then, I guess I'll continue targeting API 16.
Until then, I guess I'll continue targeting API 16. I started targeting API 19 (4.4, KitKat) over a year ago and have never looked back. That encompasses the vast bulk of Android users (>85%) and encompasses almost all of the significant developer improvements. Even using the absolute latest fun such as multiple windows is an absolute breeze from the development side, regardless of many users not supporting it yet. A…
you are ignoring your own effect on that.
The fact that every developer moved to API 19+ is why most users gave up and spent another $400~600 on a new unneeded phone.
And thanks to that, no manufacturer will ever support the latest release on a month old phone, because they now know people will just buy a new one.
Earlier quoted context omitted.
5x, too, I think.
The 5x and 6p should get it (Unless Qualcomm decides to screw everyone over ... which sadly won't surprise me). The general Google Android life cycle is 2 major OS versions and 1 year of security patches so the 5x which is on N now should get O, and then spend 2018 getting security patches until it is EOL'd. The Nexus 6 is done now though for no other reason that Qualcomm doesn't care and Google only acts like they o…
[1] https://developer.android.com/preview/download.html#flashabl...
Earlier quoted context omitted.
Option 1: DRM concerns (exploiting the "analog hole" on digital level, or HDCP restrictions - how deep is HDCP actually enforced in Android?) Option 2: Privacy (call recorders come to mind - unrelated: does anyone know of a working call recorder?)
Option 2 seems weird since I'm pretty sure Google Voice lets you record calls.
Only inbound calls, not outbound, and that's by design - it's to ensure both parties consent (since there's no way for Google to know whether the call falls under one-party or two-party consent laws).
> AAudio API for Pro Audio Android has gone all the way from A to O (15 versions) but still can't do what the first gen iPod touch could do.
And the NDK developer experience is still pretty awful compared with what C and C++ developers have at their disposal on iOS and UWP SDKs. https://code.google.com/p/android/issues/list?can=2&q=NDK&so...
I'm most excited about the new APIs for autofilling. Using a password manager on the phone today is a pain. Password filling on webpages and native apps is wonky (to say the least), and most of the time I end up manually coping passwords to clipboard, which is both cumbersome and insecure. I really hope the major password managers are quick to adopt this, and it improves the current user experience. "Autofill APIs: A…
> Using a password manager on the phone today is a pain. 1Password for Android offers a keyboard replacement. Change to 1P keyboard, use fingerprint to unlock, and it fills automatically user/pass. Very easy and convenient, and more secure than the alternative of copying to clipboard, etc. ps: no connection to AgileBits, other than being a long time user.
Earlier quoted context omitted.
And the NDK developer experience is still pretty awful compared with what C and C++ developers have at their disposal on iOS and UWP SDKs. https://code.google.com/p/android/issues/list?can=2&q=NDK&so...
That's actually one reason (well, among many, many others) I don't develop anything for Android except some toy apps I made for my kids (using a third-party C++ development kit). There's something about the entire Java ecosystem that just grates on me in a way that no other language does, and years ago when I first dipped my foot into mobile development on Android it seems like that OS amplified it all. I can't even…
Earlier quoted context omitted.
> Using a password manager on the phone today is a pain. 1Password for Android offers a keyboard replacement. Change to 1P keyboard, use fingerprint to unlock, and it fills automatically user/pass. Very easy and convenient, and more secure than the alternative of copying to clipboard, etc. ps: no connection to AgileBits, other than being a long time user.
But then I have to use their crappy keyboard, which doesn't have all the features of the Google one.