
Developer Preview of Android O - skiman10
https://android-developers.googleblog.com/2017/03/first-preview-of-android-o.html
======
sqren
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: Android users already depend on a range of password managers
to autofill login details and repetitive information, which makes setting up
new apps or placing transactions easier. Now we are making this work more
easily across the ecosystem by adding platform support for autofill. Users can
select an autofill app, similar to the way they select a keyboard app. The
autofill app stores and secures user data, such as addresses, user names, and
even passwords. For apps that want to handle autofill, we're adding new APIs
to implement an Autofill service."

~~~
guiambros
> _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.

~~~
mikeevans
But then I have to use their crappy keyboard, which doesn't have all the
features of the Google one.

~~~
eropple
You can just switch keyboards when you need to use 1Password. Not optimal, but
not a terrible experience either.

~~~
archon810
Which is undoubtedly going to be much better with an official Autofill API.

------
italophil
Too bad the OEMs don't keep up. Only 2% of devices have Android 7 (N).
[http://www.digitaltrends.com/mobile/android-distribution-
new...](http://www.digitaltrends.com/mobile/android-distribution-news/)

~~~
epoch1970
It can't help that Google hasn't released a phone comparable in spirit to the
Galaxy Nexus, Nexus 4 and Nexus 5 phones.

We're talking about phones that have a practical size, reasonably good specs,
and a $300-$400 price tag.

The Nexus 6 and 6P were impractically sized for many users. Even the 5X was
too large.

The Pixel's sizing is perhaps more tolerable, but the price tag is much too
high.

People hanging on to a Nexus 5 are out of luck, since it isn't getting Android
7 and beyond. Those with a Nexus 4 are even worse off.

While I'd like to use a newer version of Android, I've yet to find a suitable
device on the market. Google filled this niche a few years ago, but their
recent offerings are no longer suitable.

~~~
ClassyJacket
Also the Pixel updates are still held back by phone companies. If they cared
about updates or security they would update their phones directly like Apple.

~~~
teddyfrozevelt
Updates are all pushed at the same time when Verizon okays it. They don't want
to be on the hook for any regulatory issues like E-911 problems so they test
it. They also don't test security updates, only major updates.

------
Sephr
Still no user-grantable audio capture permission…

Why are only OEM-blessed apps allowed to capture system audio output, when any
app can already request permission to screen capture?

~~~
mschuster91
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?)

~~~
arrty88
I can record calls on iOS

~~~
rahimnathwani
So if I call your regular phone number (the one attached to the SIM that's in
your iPhone) you can record both sides of the audio for that call?

How?

------
whatever_dude
> Fonts are now a fully supported resource type in Android O. Apps can now use
> fonts in XML layouts

On the one hand I'm happy they added this, so we don't have to do it
programmatically.

On the other hand it took them what, 9 years? It's bizarre that it shipped
without the ability to do that in layout.

------
joshumax
> Notification channels: Android O also introduces notification channels,
> which are new app-defined categories for notification content.

FINALLY. I talked to a Google dev about this idea >1 year ago to enthusiasm
but I never thought that it would actually be implemented (and I was too darn
lazy to work on implementing it myself)... I'm so glad that channels are
finally a thing in O! Hopefully they'll also add the ability to put different
channels in different named Swipe views so I can flip to different tabs to see
different notifications.

------
thewhitetulip
I want APIs to android apps, I use material notes app as a personal twitter
and to track my excercise, I want to schedule a backup of the app, which
surprisingly gives you the internal sqlite database, I'd then sync it to my
machine using syncthing and then perform analytics on it. I want to eventually
be able to sync up everything & make my phone into my personal assistant like
it'd suggest me to call up someone I hadn't called in a long time, remember
birthdays, and it'd be voice enabled which'd work offline.

------
modeless
Wi-Fi Aware looks cool. Something like this has been sorely needed for things
like Chromecast setup and local multiplayer games. Has anyone out there used
it, or are there no supported devices yet?

~~~
zigzigzag
How is it different to WiFi Direct? Aren't there quite a lot of these wifi-
without-base-station standards, but they never seem to work or take off?

~~~
choudanu4
WiFi Direct differs from WiFi Awareness in respect to the presence of the
access point. In WiFi direct, there is no access point, and the devices
connect directly to each other. With WiFi Awareness, an access point serves as
a middle-man, but it is not necessary to access the Internet.

~~~
digi_owl
And neither of the two seems to have a defined minimum list of services like
Bluetooth has via its profiles.

Seems Google is leaving it up to the app devs to come up with services, to
expect a whole lot of silos to sprout, balkanizing the system.

On that note, i seem to recall Mozilla tried to build something similar into
their Firefox for Android at some point. But i can't relocate it now because i
can't recall what "catchy" codename they had on the project.

~~~
BHSPitMonkey
FlyWeb? [https://flyweb.github.io/](https://flyweb.github.io/)

~~~
digi_owl
Thanks!

------
theandrewbailey
Any dibs on what it's going to be named? An obvious one is "Oreo", but that's
trademarked. "Oatmeal cookie" is the only O dessert I can think of that isn't.

~~~
patrickaljord
There's Oreillettes at least, a yummy donut from south of France. Also, Kitkat
is trademarked and there was an Android Kitkat.

[https://gherkinstomatoes.com/2010/12/13/oreillettes-a-
part-o...](https://gherkinstomatoes.com/2010/12/13/oreillettes-a-part-of-
provences-thirteen-desserts/)

~~~
theandrewbailey
I'm aware of KitKat, but I'm skeptical of such a deal happening again.

~~~
faitswulff
Why is that? It seems like a beneficial arrangement for both parties.

------
therealmarv
Finally color management. Everybody nowadays speaks about HDR etc. but Android
was still stuck on SRGB and could not even convert wide color images to SRGB.

------
dang
Also
[https://news.ycombinator.com/item?id=13924269](https://news.ycombinator.com/item?id=13924269).

------
dep_b
Another opportunity wasted to create a unified Android driver model that would
allow easy upgrades.

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

~~~
npelly
Agree. Driver abstraction layers are not a cure-all. First, OEMs want to
customize the O/S above the driver level. Second, a strict DAL with a
canonical O/S on top slows hardware innovation. All devices end up
functionally the same because they have to fit the same DAL, and they can't
customize the O/S to take advantage of new HW.

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)

------
digi_owl
the multi-display thing makes me ponder a RPi Android "desktop" or similar.

Seems that slowly Google is coming round to where Android was heading back
around 3.x-4.0.

~~~
kogepathic
_> the multi-display thing makes me ponder a RPi Android "desktop" or
similar._

I think this is Google's response to Continuum.

If Microsoft comes out with a really good implementation of a docked phone,
Google needs to have a response ready for their platform. Normal users
probably won't care, but anyone who is interested in productivity knows how
crucial a monitor and multi-window/tasking support is.

It usually takes 1 or 2 release cycles for Google to finalize a feature, so by
starting now they're signaling intent to have some kind of mature feature by
2018-19.

------
jepler
hm is this the one that won't make it to my phone, a nexus 6 (2014)? sigh.

~~~
e40
5x, too, I think.

~~~
Infinitesimus
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 only about you having Play Services and the
Play Store. Maybe a miracle will happen this year...

~~~
wyldfire
5x, 6P, Player, Pixel C, Pixel, Pixel XL are all listed on the downloads page
for this developer preview [1]. Seems like these would be likely to get the
final release.

[1]
[https://developer.android.com/preview/download.html#flashabl...](https://developer.android.com/preview/download.html#flashable-
images)

------
YZF
Would be awesome if it worked on my Nexus 4.

------
jshmrsn
I wonder if the Material Design yellow circles are intended to allude to a
sun, and that this will be called Android Orbit? (As in the candy Orbit Gum)

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

~~~
pjmlp
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...](https://code.google.com/p/android/issues/list?can=2&q=NDK&sort=-opened&colspec=ID%20Status%20Priority%20Owner%20Summary%20Stars%20Reporter%20Opened)

~~~
sidlls
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 explain it.

~~~
remir
What is your opinion on Dart? I could see Google encouraging devs to learn
Dart and make Flutter apps soon. Probably at I/O.

~~~
pjmlp
It is not Google encouraging devs, it is the Dart team looking for reasons to
keep going, besides Ad Words.

Just go watch any Android Fireside at Google IO or the responses of Android
team at Reddit.

Java is Android's language, with C and C++ just being there to the extent of
implementing Java _native_ methods, low latency code and code from other
platforms, not full blown access to the OS APIs.

As an example of an discussion regarding Scala, after their annoucement to
ditch Jack and start anew their cherry picked features from Java 8.

"Java is the language we officially support."

[https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o...](https://www.reddit.com/r/androiddev/comments/5zf1xo/future_of_java_8_language_feature_support_on/deyyp0n/)

~~~
remir
Yeah but what about Flutter? It's even part of Fuchsia, their new OS.

------
Razengan
So they will be introducing picture-in-picture support?

If they start allowing YouTube to work with the PiP feature on iPads (which it
always could with third-party workarounds, but not in the official app [1])
after this, then it'll be confirmed that they purposely disabled the feature
on iOS only to retain artificial parity with Android, which would be a very
scummy behavior.

[1]
[https://www.reddit.com/r/apple/comments/5lxm6c/why_is_google...](https://www.reddit.com/r/apple/comments/5lxm6c/why_is_google_working_so_hard_to_deliberately/)

~~~
mavendependency
High end samsung firmware has PIP support, can confirm that (samsung) PIP
works perfectly with youtube. Apple might need to communicate better with the
youtube folks.

~~~
threeseed
It's just an API to implement. But YouTube for iOS in general is a dreadful
piece of software so not surprised they haven't done it.

------
hyperpallium
> AAudio API for Pro Audio: AAudio is a new native API that's designed
> specifically for apps that require high-performance, low-latency audio.

It's always seemed so weird to me how terrible audio latency is... not just on
android, but also on consoles (guitar hero, rockband etc), where it makes them
utterly unplayable as instruments - I'm thinking mainly of the drumkits here.

Yes, iPhone is _better_ than android, but it's still not workable as an
instrument.

OTOH fully electronic digital instruments have been mainstream for decades. Is
it because we are somehow able to accept terrible _visual_ latency in games
(recently exacerbated by network latency)? And so our systems get optimized
for throughput performance (resolution, fps etc) at the cost of latency?
Though the latency problem rears its ugly head again in VR. Seems to need to
be sub 10-15ms, end-to-end (from human input to output), for both VR visual
and audio.

Anyway, I think better audio latency requires a redesign of the entire system,
and it's not clear than this new API has that support behind it.

~~~
pjmlp
I assume this API is based on the work of Samsung has done for their own
private APIs.

[http://developer.samsung.com/galaxy/professional-
audio](http://developer.samsung.com/galaxy/professional-audio)

Last Google IO they had a session about all workarounds for improving the
audio developers experience and they got Samsung on stage to talk about their
SDK.

[https://www.youtube.com/watch?v=F2ZDp-
eNrh4](https://www.youtube.com/watch?v=F2ZDp-eNrh4)

