Developer Preview of Android O | Hacker News Reader

Developer Preview of Android O

android-developers.googleblog.com

164 pointsskiman10108 comments

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

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

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

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

I really hope this works out well. Maybe then we can get it on the desktop!

It really shouldn't be this hard. I personally had to do a lot of hacking to get my password manager to work consistently. UX designers are really determined to make logging in as obtuse as possible.

With Dashlane I have 0 issues with auto fill across apps and chrome.

FWIW : Google is working with Dashlane in order to extend and generalize SmartLock into a standard lib : openYOLO (you only login once).

That would be pretty awesome (no more passwords ! )

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

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.

That is the solution, the contract for accessing Play Services already has quite a few clauses, requiring updates would just be yet another requirement for accessing Play Services.

That would just make them look for alternatives asap.

The basic problem is that updates are an expense once the SKU starts shipping, while spending the same money on a new SKU is an investment.

Apple get around this because they own the whole stack. Thus keeping a device going longer means more exposure to their stores.

Never mind that even though they release a new iOS in name, major new features are left out for the version pushed to the older devices.

Never mind that on Android APIs can be supplied by APKs, and thus we have Play Services.

Frankly the only thing Google can do is adopt something akin to what they have on ChromeOS.

Split the Android VM layer from the Linux layer, so that they can update the VM layer independently of the kernel and userland layer.

Another issue is unless you are looking at white box rebrands, each OEM tailor the Android UI/UX.

Unless Google makes it possible to isolate this tailoring from the core Android code, there will still be lag time between Google releasing a new version, and it hitting devices. And that is reliant on the tailored variant fits inside the storage space of the device.

> Never mind that even though they release a new iOS in name, major new features are left out for the version pushed to the older devices.

This is simplistic and largely wrong. Only when there is a lack of appropriate hardware e.g. noise cancellation in the A5 chip or inadequate RAM has Apple decided not to port to those older devices. It's not a deliberate policy especially since they have been selling older devices alongside the newer ones.

That said for developers it's been about 99% of features available on all devices.

Yes, Apple is much better about it; but there are instances where Apple has limited certain features to newer devices when there was no real reason for doing so. Most recently they blocked trivial features such as content blocking and Night Shift from 32 bit devices in their push for 64 bit adoption.

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.

As a side benefit, the devices that get excluded are often older, often abandoned devices. I previously tried desperately to support all of those older devices and the reward were a barrage of low ratings by people on poor performing old devices.

Android has a planned obsolescence thing. I've gotten use to it.

The issue with bad ratings from users with shitty phones where it's actually a miracle you got it to work on their phone at all is such a real pain...

"App crashes on open when using my 1989 car phone, 1 star"

> 85%

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.

The majority of users never spend $400~600 on a new phone.

Most of people are on pre-pay and not everyone can afford those prices.

Here in this side of the planet, you get KitKat devices around 50 €, then Lollipop start selling around 100 €.

For Marshmallow, usually the prices start at 200 € and most devices are only available on a few shops or online.

As for Nougat, I am yet to see any shop selling them.

So no, most people that just want a phone, any Android phone, will get one of those KitKat/Lollipop devices with their pre-paid card.

It's a virtuous circle for sure, however there are very decent sub-$200 devices now with Android 6.0+ (many set to receive 7 in the next couple of months). And on the contract side, many consumers are just accustomed to getting a new device every two years regardless, seeming "free", albeit baked into their service fee.

At some point the market will settle as the pad market did, however right now the lack of pressure on vendors to support upgrades is also a reflection of a user base that is accustomed to constantly upgrading (better cameras, processors, storage, etc).

you mean vicious cycle :)

do you have something to back this ?

I have seen the same kind of stats on apps supporting all APIs levels.

Turns out that people likely to install / use app are using more recent phones in general.

If you are still targeting 16, you should make sure that you are handling a bunch of pretty serious security changes made between 17-21. There are a lot of ways you can shoot yourself in the foot when using the old APIs.

I hope he means that he targets 25 but support 16 as a minimum.

Targeting 16 is just incredibly stupid but I have seen some devs unable to read the documentation..

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.

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.

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.

I don't know if they have the direct leverage they need. They'd have to force the manufacturers to fight for it if/when their contract negotiations with carriers occur again.

I've not seen any updates held back by my carrier (unless, I guess, they don't send them out to anyone until all of the phone companies agree on them). As far as I've seen, I get my ~monthly security patches over the air from Google when the rolling updates hit my phone or I get impatient for an important one and just download it from Google myself.

The OnePlus 3 is a worthy successor to the Nexus line in terms of quality and price (at $399), though I still wish it were a little smaller at times (like the Nexus 5 I used before it).

I also replaced my Nexus 5 with a OnePlus 3. The OnePlus 3 is so large that I develop finger pains reading on the subway. It's ridiculous.

I liked my 5x, until the fingerprint recognition suddenly disappeared.

Literally disappeared from all settings this week after a restart.

Have to restore or something equally tedious.

I liked my 5X until it died from the bootloop issue 1mo out of warranty. Happened to at least two other co-workers and burned me enough to swear off Google phones. I'm not going to drop $700 on something that might last less than a year.

OnePlus 3T got my money instead.

May be worth checking to see if you can get an out of warranty replacement. I bought the phone through my carrier (Google Fi) and they replaced it for free with a refurbished 5X. 6 months out of warranty.

A colleague of mine also got his 5X replaced out of warranty. It did take a couple of months before he got a replacement 5X, but he did get one. Might be worth a try.

I live in Japan. There is still no news about whether the Pixel is coming to Japan. How can I take the ecosystem seriously when Google is telling me "we don't care about your market"?

And although they said all along they'd do it, Google dropped new development for the Nexus 6. Which is too bad for those of us who want a phablet and would benefit from all the battery improvements.

Hopefully if Google releases another like-sized device it's better than the N6 which becomes unusable as soon as CPU throttling starts. As soon as battery gets below 70% it literally takes seconds for mundane tasks like opening a new browser or keyboard.

I don't expect Google to fix it on the N6 but I really hope they don't recreate that experience on their next offering because it's beyond frustrating.

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?

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

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?

That's hard to do using the built-in Phone app even on jailbroken devices (the default repos won't list call recorders).

How?

Option 2 seems weird since I'm pretty sure Google Voice lets you record calls.

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

What does inbound vs outbound have to do with consent?

When you start recording a call, it plays a brief message (e.g. "this call is now being recorded"). If it's an outbound call, you could start recording before the other person has actually picked up. If it's inbound, they "know" that the other person will hear the message.

It's not actually foolproof if you sit down and think about the edge cases, but that's the rationale behind it. It's a decision driven by the legal team, not the product or engineering ones.

Are there any major jurisdictions where this is actually a requirement? I was under the impression that a) it makes no sense, anyone could use an external recorder, and more importantly b) when you are talking with someone, you don't have an expectation of privacy from the person you are talking with?

Where would this meaningless feature-cripling make sense?

> Are there any major jurisdictions where this is actually a requirement?

For starters, twelve states in the US, including California: https://en.wikipedia.org/wiki/Telephone_recording_laws#Unite...

And telecom companies (Google acting in the role of a telecom company in this case) have certain responsibilities and liabilities if they facilitate illegal recordings.

I used CallRec. It wasn't easy to get it working. After rooting my phone, I had to spend hours making other tweaks.

And of course the software ecosystem is so fragmented, and if you do want to find anything out, you have to sift through mountains of misinformation.

I'm surprised this still hasn't been implemented, given there must be some industry pressure to do so. Under Android, all(?) the various consumer wireless audio implementations (Sonos, AirPlay, etc.) require users to either use a vendor-provided music app (which vendors don't want to deal with maintaining, nor do users want to be forced to use), or one of the few music apps that implement their standard.

It's a frustrating mess, all the more frustrating given that the limitation seems to exist only to prevent ripping of copyrighted audio, regardless of how beneficial the legitimate uses are.

I use CyanogenMod and I am able to capture audio and screen, my mother has a lenovo phone which allows you to capture calls directly.

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

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

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.

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?

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?

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.

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.

FlyWeb? https://flyweb.github.io/

Thanks!

Similar to MultipeerConnectivity on iOS — https://developer.apple.com/reference/multipeerconnectivity.

There are no supported devices yet. supposedly next pixel will support

Oh yes! Lots of IOT device setups could be improved with this

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.

https://fossbytes.com/android-o-name-predictions-best-sweet-...

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

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

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

Kitkat was trademarked...

Orange Marmalade.

Orangesicle? Opal Fruits, if the trademark has lapsed by now?

Ovaltine; obviously!

Orange? Perhaps they're becoming more health conscious? ;)

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.

Also https://news.ycombinator.com/item?id=13924269.

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.

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)

I was curious so I took a look: It seems they're implementing a new system; there are shared libraries in /vendor/lib/hw on my Pixel running O that aren't there on my Pixel XL running 7.1.

  sailfish:/ $ ls /vendor/lib/hw                                                                                                                   
  android.hardware.audio.effect@2.0-impl.so        android.hardware.graphics.composer@2.1-impl.so  android.hardware.vibrator@1.0-impl.so  
  android.hardware.audio@2.0-impl.so               android.hardware.graphics.mapper@2.0-impl.so    android.hardware.vr@1.0-impl.so        
  android.hardware.boot@1.0-impl.so                android.hardware.keymaster@3.0-impl.so          flp.default.so                         
  android.hardware.camera.provider@2.4-impl.so     android.hardware.light@2.0-impl.so              gatekeeper.msm8996.so                  
  android.hardware.configstore@1.0-impl.so         android.hardware.memtrack@1.0-impl.so           keystore.msm8996.so                    
  android.hardware.contexthub@1.0-impl.so          android.hardware.nfc@1.0-impl.so                sensors.vl530l0.tof.so                 
  android.hardware.drm@1.0-impl.so                 android.hardware.power@1.0-impl.so              sound_trigger.primary.msm8996.so       
  android.hardware.gatekeeper@1.0-impl.so          android.hardware.sensors@1.0-impl.so            vulkan.msm8996.so                      
  android.hardware.gnss@1.0-impl.so                android.hardware.soundtrigger@2.0-impl.so       
  android.hardware.graphics.allocator@2.0-impl.so  android.hardware.thermal@1.0-impl.so

You can see some development in the AOSP repos (follow https://r.android.com) that supports this. For example, libhwbinder (https://android.googlesource.com/platform/system/libhwbinder...) looks to be an interface for talking with a /dev/hwbinder device, and the kernel seems to have been updated recently to support multiple Binder device instances. HAL interfaces are defined in HIDL, which looks to be implemented here: https://android.googlesource.com/platform/system/libhidl/+/m... (along with a separate hidl tool in another repo).

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.

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

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

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

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

Would be awesome if it worked on my Nexus 4.

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)

> 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 vice versia, iOS today still cannot do few things, that the first Android could.

Some people simply do not care about something, that might be a pet feature of someone else.

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 explains all of the low latency audio apps on windows phone. Oh wait...

Just because a free OS with no strings attached is loved by OEMs, it doesn't mean its developer tools are a pleasure to use.

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.

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

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

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

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

YouTube hardly takes advantage of already existing features on Android, so I very much doubt this is what's holding them back.

I suspect that on the app side Google have much the same problem as Facebook struggled with until they demanded employees start carry and use Android devices.

Basically the apps are developed by much the same people that are doing the web dev. And those are very much Mac/iPhone users.

Thus they are barely aware of what is going on with Android.

Hell, the Allo boss basically made claims that made zero sense for why it didn't integrate SMS into the message timeline.

This while Android users have been screaming for a Google brand messenger that integrate SMS, and Android provides a SMS backend that any app can talk to.

>Thus they are barely aware of what is going on with Android.

This seems like quite a profound stretch. I'm not even sure what the parent is talking about regarding YouTube hardly taking advantage -- it takes great advantage. The Android platform is absolutely its benchmark implementation. And it's completely native, so this isn't a group of iPhone devs doing it on the side.

This notion of the forgotten Android implementation from a bunch of Apple fans seems almost quaint now. While it was true years ago, at this point any shop that does that sort of thing is guaranteeing themselves doom. It isn't an after thought.

> Basically the apps are developed by much the same people that are doing the web dev. And those are very much Mac/iPhone users.

So why cripple PiP on iOS and bury it on macOS?

• On macOS, you have to have to menu-click on the YouTube web player TWICE to bring up the PiP option [1]; why not include it in YouTube's own menu or control strip?

• on iOS, you could access PiP by visiting YouTube in a browser, or pasting a YouTube link into certain sites [2], but they seem to be actively locking down on this. There are third-party apps that let you view YouTube in PiP, so why is it not in the native player?

[1] http://imgur.com/a/n8b1l

[2] http://ctrlq.org/youtube/pip/

In macOS, it is Safari, that implements PIP. The sites know nothing about its existence and neither do browsers other than Safari.

The menu on the second click is Safari menu for the <video> HTML5 element.

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.

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.

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

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

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

Audio latency on ios devices is less than 10 ms (iirc about 6-7 ms). It's not ideal but saying it's "not workable" is an exaggeration. Also I don't believe the latency for computing devices is worse compared to digital instruments because we accept it, but because digital instruments have always had an advantage due to their specialization.

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

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

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

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

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

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

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

"iPhone is better than android"

Are you comparing iPhone to the totality of Android-running devices available, or iOS to the Android OS?

Reply on news.ycombinator.com