Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developer Preview of Android O

android-developers.googleblog.com

Post reply on HN
Print view View original

51–60 of 115 posts

Re: Developer Preview of Android O

#51

Post by BHSPitMonkey »

digi_owl wrote: post #21
choudanu4 wrote: post #15

Earlier quoted context omitted.

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…

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

Re: Developer Preview of Android O

#52

Post by fudged71 »

modeless wrote: post #3

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?

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

Re: Developer Preview of Android O

#53

Post by faitswulff »

theandrewbailey wrote: post #19
patrickaljord wrote: post #18

Earlier quoted context omitted.

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.

Re: Developer Preview of Android O

#54

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

Re: Developer Preview of Android O

#55

Post by arrty88 »

mschuster91 wrote: post #42
Sephr wrote: post #29

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

Re: Developer Preview of Android O

#56

Post by sigmar »

dep_b wrote: post #14

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.

Re: Developer Preview of Android O

#57

Post by vetinari »

Razengan wrote: post #36
digi_owl wrote: post #31

Earlier quoted context omitted.

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…

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

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

Re: Developer Preview of Android O

#58

Post by saagarjha »

threeseed wrote: post #39
digi_owl wrote: post #20

Earlier quoted context omitted.

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 th…

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

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.

Re: Developer Preview of Android O

#59

Post by jml7c5 »

Sephr wrote: post #29

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?

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.

Post reply on HN