11 ms·

Developer Preview of Android O

164 points by skiman10 10y ago

dang 10y ago
Also https://news.ycombinator.com/item?id=13924269 https://news.ycombinator.com/item?id=13924269.
modeless 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        FlyWeb? https://flyweb.github.io/ https://flyweb.github.io/
        digi_owl 10y ago
        Thanks!
- jrullman 10y ago
  Similar to MultipeerConnectivity on iOS — https://developer.apple.com/reference/multipeerconnectivity https://developer.apple.com/reference/multipeerconnectivity.
- ulkram 10y ago
  There are no supported devices yet. supposedly next pixel will support
- fudged71 10y ago
  Oh yes! Lots of IOT device setups could be improved with this
Razengan 10y ago
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_working_so_hard_to_deliberately/ https://www.reddit.com/r/apple/comments/5lxm6c/why_is_google...
- deleted 10y ago
  [deleted]
- tacomonstrous 10y ago
  YouTube hardly takes advantage of already existing features on Android, so I very much doubt this is what's holding them back.
  - digi_owl 10y ago
    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.
    - endorphone 10y ago
      >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.
italophil 10y ago
Too bad the OEMs don't keep up. Only 2% of devices have Android 7 (N). http://www.digitaltrends.com/mobile/android-distribution-news/ http://www.digitaltrends.com/mobile/android-distribution-new...
- hehheh 10y ago
  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.
  - digi_owl 10y ago
    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.
    - deleted 10y ago
      [deleted]
    - threeseed 10y ago
      > 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.
nileshtrivedi 10y ago
> 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.
- vetinari 10y ago
  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.
- pjmlp 10y ago
  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&sort=-opened&colspec=ID%20Status%20Priority%20Owner%20Summary%20Stars%20Reporter%20Opened https://code.google.com/p/android/issues/list?can=2&q=NDK&so...
  - sidlls 10y ago
    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 10y ago
      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 10y ago
        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_of_java_8_language_feature_support_on/deyyp0n/ https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o...
whatever_dude 10y ago
> 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.
jepler 10y ago
hm is this the one that won't make it to my phone, a nexus 6 (2014)? sigh.
- e40 10y ago
  5x, too, I think.
  - Infinitesimus 10y ago
    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 10y ago
      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#flashable-images https://developer.android.com/preview/download.html#flashabl...
  - deleted 10y ago
    [deleted]
theandrewbailey 10y ago
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.
- freedrock87 10y ago
  https://fossbytes.com/android-o-name-predictions-best-sweet-nicknames/ https://fossbytes.com/android-o-name-predictions-best-sweet-...
- patrickaljord 10y ago
  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-of-provences-thirteen-desserts/ https://gherkinstomatoes.com/2010/12/13/oreillettes-a-part-o...
  - theandrewbailey 10y ago
    I'm aware of KitKat, but I'm skeptical of such a deal happening again.
    - faitswulff 10y ago
      Why is that? It seems like a beneficial arrangement for both parties.
- nobrains 10y ago
  Kitkat was trademarked...
- deleted 10y ago
  [deleted]
- metrognome 10y ago
  Orange Marmalade.
- tesseract 10y ago
dep_b 10y ago
Another opportunity wasted to create a unified Android driver model that would allow easy upgrades.
- sigmar 10y ago
  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 10y ago
    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)
- EddieRingle 10y ago
  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 https://r.android.com) that supports this. For example, libhwbinder (https://android.googlesource.com/platform/system/libhwbinder/+/master 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/+/master https://android.googlesource.com/platform/system/libhidl/+/m... (along with a separate hidl tool in another repo).
digi_owl 10y ago
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 10y ago
  > 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.
jshmrsn 10y ago
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)
Sephr 10y ago
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 10y ago
  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 10y ago
    I can record calls on iOS
    - rahimnathwani 10y ago
      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?
      - deleted 10y ago
        [deleted]
    - conradev 10y ago
      That's hard to do using the built-in Phone app even on jailbroken devices (the default repos won't list call recorders).
    - tunocina 10y ago
      How?
  - eli 10y ago
    Option 2 seems weird since I'm pretty sure Google Voice lets you record calls.
joshumax 10y ago
> 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.
YZF 10y ago
Would be awesome if it worked on my Nexus 4.
sqren 10y ago
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 10y ago
  > 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 10y ago
    But then I have to use their crappy keyboard, which doesn't have all the features of the Google one.
    - eropple 10y ago
      You can just switch keyboards when you need to use 1Password. Not optimal, but not a terrible experience either.
      - archon810 10y ago
        Which is undoubtedly going to be much better with an official Autofill API.
therealmarv 10y ago
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.
thewhitetulip 10y ago
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.
hyperpallium 10y ago
> 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 10y ago
  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
- emsy 10y ago
  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.
- bahndoos 10y ago
  > > 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. > 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. > 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. "iPhone is better than android" Are you comparing iPhone to the totality of Android-running devices available, or iOS to the Android OS?

164 points by skiman10 10y ago

dang 10y ago

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

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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      FlyWeb? https://flyweb.github.io/ https://flyweb.github.io/
      - digi_owl 10y ago
        Thanks!
jrullman 10y ago
Similar to MultipeerConnectivity on iOS — https://developer.apple.com/reference/multipeerconnectivity https://developer.apple.com/reference/multipeerconnectivity.
ulkram 10y ago
There are no supported devices yet. supposedly next pixel will support
fudged71 10y ago
Oh yes! Lots of IOT device setups could be improved with this

Razengan 10y ago

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_working_so_hard_to_deliberately/ https://www.reddit.com/r/apple/comments/5lxm6c/why_is_google...

deleted 10y ago
[deleted]
tacomonstrous 10y ago
YouTube hardly takes advantage of already existing features on Android, so I very much doubt this is what's holding them back.
- digi_owl 10y ago
  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.
  - endorphone 10y ago
    >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.

italophil 10y ago

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

hehheh 10y ago
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.
- digi_owl 10y ago
  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.
  - deleted 10y ago
    [deleted]
  - threeseed 10y ago
    > 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.

nileshtrivedi 10y ago

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

vetinari 10y ago
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.
pjmlp 10y ago
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&sort=-opened&colspec=ID%20Status%20Priority%20Owner%20Summary%20Stars%20Reporter%20Opened https://code.google.com/p/android/issues/list?can=2&q=NDK&so...
- sidlls 10y ago
  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 10y ago
    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 10y ago
      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_of_java_8_language_feature_support_on/deyyp0n/ https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o...

whatever_dude 10y ago

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

jepler 10y ago

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

e40 10y ago
5x, too, I think.
- Infinitesimus 10y ago
  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 10y ago
    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#flashable-images https://developer.android.com/preview/download.html#flashabl...
- deleted 10y ago
  [deleted]

theandrewbailey 10y ago

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.

freedrock87 10y ago
https://fossbytes.com/android-o-name-predictions-best-sweet-nicknames/ https://fossbytes.com/android-o-name-predictions-best-sweet-...
patrickaljord 10y ago
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-of-provences-thirteen-desserts/ https://gherkinstomatoes.com/2010/12/13/oreillettes-a-part-o...
- theandrewbailey 10y ago
  I'm aware of KitKat, but I'm skeptical of such a deal happening again.
  - faitswulff 10y ago
    Why is that? It seems like a beneficial arrangement for both parties.
nobrains 10y ago
Kitkat was trademarked...
deleted 10y ago
[deleted]
metrognome 10y ago
Orange Marmalade.
tesseract 10y ago

dep_b 10y ago

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

sigmar 10y ago
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 10y ago
  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)
EddieRingle 10y ago
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 https://r.android.com) that supports this. For example, libhwbinder (https://android.googlesource.com/platform/system/libhwbinder/+/master 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/+/master https://android.googlesource.com/platform/system/libhidl/+/m... (along with a separate hidl tool in another repo).

digi_owl 10y ago

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 10y ago
> 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.

jshmrsn 10y ago

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)

Sephr 10y ago

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 10y ago
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 10y ago
  I can record calls on iOS
  - rahimnathwani 10y ago
    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?
    - deleted 10y ago
      [deleted]
  - conradev 10y ago
    That's hard to do using the built-in Phone app even on jailbroken devices (the default repos won't list call recorders).
  - tunocina 10y ago
    How?
- eli 10y ago
  Option 2 seems weird since I'm pretty sure Google Voice lets you record calls.

joshumax 10y ago

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

YZF 10y ago

Would be awesome if it worked on my Nexus 4.

sqren 10y ago

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 10y ago
> 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 10y ago
  But then I have to use their crappy keyboard, which doesn't have all the features of the Google one.
  - eropple 10y ago
    You can just switch keyboards when you need to use 1Password. Not optimal, but not a terrible experience either.
    - archon810 10y ago
      Which is undoubtedly going to be much better with an official Autofill API.

therealmarv 10y ago

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.

thewhitetulip 10y ago

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.

hyperpallium 10y ago

> 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 10y ago
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
emsy 10y ago
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.
bahndoos 10y ago
> > 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. > 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. > 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. "iPhone is better than android" Are you comparing iPhone to the totality of Android-running devices available, or iOS to the Android OS?