Linked by Thom Holwerda on Tue 21st Mar 2017 23:27 UTC
Android

Google has released the first Developer Preview for Android O, which is probably going to be released somewhere in the Fall. There's a lot changes in this one, but the biggest one is probably the limits Android O is going to place on applications running in the background.

Building on the work we began in Nougat, Android O puts a big priority on improving a user's battery life and the device's interactive performance. To make this possible, we've put additional automatic limits on what apps can do in the background, in three main areas: implicit broadcasts, background services, and location updates. These changes will make it easier to create apps that have minimal impact on a user's device and battery. Background limits represent a significant change in Android, so we want every developer to get familiar with them. Check out the documentation on background execution limits and background location limits for details.

There's more - improvements in keyboard navigation, Navigation Channels for managing notifications, picture-in-picture on smartphones, wide-gamut colour support for applications, several new Java 8 features, and more. A big one for audio people: Sony has contributed a lot of work to audio in Android O, adding the LDAC wireless audio codec.

It's available on the usual Nexus devices.

Order by: Score:
Comment by stormcrow
by stormcrow on Wed 22nd Mar 2017 00:11 UTC
stormcrow
Member since:
2015-03-10

"Sony has contributed a lot of work to audio in Android O, adding the LDAC wireless audio codec."

Great, just what Android needs, yet more proprietary closed standards and blobs of code no one else can use without a license and NDA - assuming Sony would even license it should someone else want to use it.

Edited 2017-03-22 00:18 UTC

Reply Score: 2

RE: Comment by stormcrow
by javispedro on Wed 22nd Mar 2017 00:35 UTC in reply to "Comment by stormcrow"
javispedro Member since:
2014-06-04

Not to mention completely useless for headphones, since almost any codec is transparent at half the bandwidth allowed by A2DP in Bluetooth 2.1... absolutely no need for anything propietary.

Edited 2017-03-22 00:36 UTC

Reply Score: 1

RE[2]: Comment by stormcrow
by WorknMan on Wed 22nd Mar 2017 02:38 UTC in reply to "RE: Comment by stormcrow"
WorknMan Member since:
2005-11-13

absolutely no need for anything propietary.


Except that it sounds a lot better than normal bluetooth. I think it's nice for people who want the option.

Reply Score: 2

RE[3]: Comment by stormcrow
by stormcrow on Wed 22nd Mar 2017 03:23 UTC in reply to "RE[2]: Comment by stormcrow"
stormcrow Member since:
2015-03-10

Actually it's not. Bluetooth is perfectly capable of handling 16bit/44.1KHz playback (roughly 175kB/s) which is considered the optimal digital playback format based on empirical analysis. People like to say higher sample rates and bit sizes are better for playback as well as production, but the scientific evidence doesn't support that conclusion at all.

https://people.xiph.org/~xiphmont/demo/neil-young.html

The takeaway: "Empirical evidence from listening tests backs up the assertion that 44.1kHz/16 bit provides highest-possible fidelity playback."

Look under the subtitle "Listening Tests" where it gives links to scholarly research along with links discussions on the topic, if you don't want to read through all the signal theory and human auditory anatomy.

16/44.1 doesn't require any proprietary codecs beyond what Bluetooth already carries to meet such a target.

Reply Score: 3

RE[4]: Comment by stormcrow
by kurkosdr on Wed 22nd Mar 2017 13:01 UTC in reply to "RE[3]: Comment by stormcrow"
kurkosdr Member since:
2011-04-11

It's good to have the choice.

BTW, restrictions on background tasks are very welcome. I hate it when app vendors think they have dominion over my device because I gave their app permission to be installed.

Edited 2017-03-22 13:03 UTC

Reply Score: 3

RE[4]: Comment by stormcrow
by No it isnt on Wed 22nd Mar 2017 16:45 UTC in reply to "RE[3]: Comment by stormcrow"
No it isnt Member since:
2005-11-14

The codecs aren't for higher than needed bitrates, but for better compression. I don't think any speaker or headphone uses uncompressed PCM audio over bluetooth.

Reply Score: 3

RE[4]: Comment by stormcrow
by phoenix on Wed 22nd Mar 2017 21:23 UTC in reply to "RE[3]: Comment by stormcrow"
phoenix Member since:
2005-07-11

Actually it's not. Bluetooth is perfectly capable of handling 16bit/44.1KHz playback (roughly 175kB/s)


And which Bluetooth profile are you using that provides 1.75 Mbps of bandwidth? And what audio devices are you connecting to that support that?

A2DP provides less than 330 kbps (kilobits) of bandwidth for audio. And has pretty bad codecs running over that.

Apt-X provides better audio quality using the existing A2DP bandwidth.

LDAC provides 3x the bandwidth of A2DP (up to 990 kbps), along with better codecs, for overall better sound quality.

Reply Score: 4

RE[5]: Comment by stormcrow
by stormcrow on Thu 23rd Mar 2017 00:25 UTC in reply to "RE[4]: Comment by stormcrow"
stormcrow Member since:
2015-03-10

Bluetooth itself easily provides considerably more bandwidth when it's utilized. And I wrote 175 KILObytes, not megabytes. In fact Bluetooth 4 & 5 can handle that easily and there's no reason vendors can't implement a royalty free codec over Bluetooth via the data channels. As I keep saying LDAC is over engineered and proprietary. Android doesn't need this IN THE UPSTREAM. If you want LDAC then buy a Sony device, but it shouldn't be in the upstream system with code that can't be used by anyone else.

Reply Score: 2

RE[6]: Comment by stormcrow
by phoenix on Thu 23rd Mar 2017 03:05 UTC in reply to "RE[5]: Comment by stormcrow"
phoenix Member since:
2005-07-11

175 kiloBYTES/sec is 1.75 megaBITS/sec.

Reply Score: 2

RE[7]: Comment by stormcrow
by chuzwuzza on Thu 23rd Mar 2017 04:20 UTC in reply to "RE[6]: Comment by stormcrow"
chuzwuzza Member since:
2005-07-06

175 kiloBYTES/sec is 1.75 megaBITS/sec.


What? No it isn't. It's 1.4mbps

https://www.wolframalpha.com/input/?i=175+kilobytes+per+second+in+me...

Reply Score: 1

RE[7]: Comment by stormcrow
by Alfman on Thu 23rd Mar 2017 04:44 UTC in reply to "RE[6]: Comment by stormcrow"
Alfman Member since:
2011-01-28

phoenix,

175 kiloBYTES/sec is 1.75 megaBITS/sec.



You mean 1.4mbps, right?

Anyways, I cringe every time the xiph audio link comes up because of some of their inaccurate claims. They put forward the science behind the Nyquist frequency in explaining why 44khz is enough to represent our 22khz audio hearing, and if they had stopped there I'd be ok with it, but then they misrepresent higher frequencies as being worse than 44khz, which is a falsehood.

They claimed that anything over 44khz is not perceivable, however to the extent that it were audible, then it directly contradicts their earlier claim and technically the higher fidelity signal that best matches nature is the "better" audio, assuming the intention is to reproduce actual sounds as they happened. After all, there's no 44khz limit to be found in nature, so unless they want to criticize nature for producing >44khz audio, then they have no business suggesting higher fidelity is worse.

I believe what they might have meant was that some ADC implementations that advertise 192khz fail to achieve that level of response due to poor circuitry or inadequate calibration or whatever. I could accept criticism on that basis, but then they should at least retract their blanket statement that 192khz is considered worse and instead emphasize that some implementations of it fail to achieve the claimed fidelity (hopefully with evidence to back their claim). Ironically I agree with them that I can't hear above 22khz, but without evidence for their claims about the inferiority of 192khz sampling, they are just as guilty as those they're trying to debunk, which bothers me.

Edited 2017-03-23 04:48 UTC

Reply Score: 2

RE[2]: Comment by stormcrow
by darknexus on Wed 22nd Mar 2017 11:28 UTC in reply to "RE: Comment by stormcrow"
darknexus Member since:
2008-07-15

And that's why we have Bluetooth higher than 2.1, no?

Reply Score: 2

RE[2]: Comment by stormcrow
by sultanqasim on Wed 22nd Mar 2017 16:25 UTC in reply to "RE: Comment by stormcrow"
sultanqasim Member since:
2006-10-28

While adequate bandwidth is available, using it consumes power. The more data you transmit or receive, the more power is consumed by the radio. If you could maintain the same quality while reducing power consumption, that would be useful.

Reply Score: 2

Comment by p13.
by p13. on Wed 22nd Mar 2017 10:39 UTC
p13.
Member since:
2005-07-10

Meanwhile my s7 is stuck at 6.0 for some reason.

Reply Score: 2

RE: Comment by p13.
by Thom_Holwerda on Wed 22nd Mar 2017 11:02 UTC in reply to "Comment by p13."
Thom_Holwerda Member since:
2005-06-29

Weird. My brand new Galaxy S7 Edge got the Nougat update right as I booted it up for the first time. Then again - carriers don't fuck with phones in The Netherlands, and mine is bought off-contract anyway.

Reply Score: 1

RE[2]: Comment by p13.
by p13. on Wed 22nd Mar 2017 16:36 UTC in reply to "RE: Comment by p13."
p13. Member since:
2005-07-10

I live in Belgium.
Bought mine off contract too.
The edge seems to have gotten the update sooner.

Reply Score: 2

RE: Comment by p13.
by darknexus on Wed 22nd Mar 2017 11:31 UTC in reply to "Comment by p13."
darknexus Member since:
2008-07-15

Meanwhile my s7 is stuck at 6.0 for some reason.

As the Android people on here are so fond of saying: you bought it. You knew what you were getting into, going with Samsung.
Sucks from the other side...

Reply Score: 3

O RLY?
by birdie on Wed 22nd Mar 2017 17:02 UTC
birdie
Member since:
2014-07-15

Nothing from this list has been addressed: http://itvision.altervista.org/why-android-sucks.html

This is truly appalling.

Reply Score: 2

RE: O RLY?
by franksands on Wed 22nd Mar 2017 20:46 UTC in reply to "O RLY?"
franksands Member since:
2009-08-18

Have you read the article you linked, he said that although these problems are not yet fixed, Android is still the best mobile OS.

Reply Score: 2

RE[2]: O RLY?
by birdie on Wed 22nd Mar 2017 21:36 UTC in reply to "RE: O RLY?"
birdie Member since:
2014-07-15

The best mobile OS doesn't make it perfect or resolves long standing issues.

Reply Score: 3

Color management?
by CaptainN- on Wed 22nd Mar 2017 18:07 UTC
CaptainN-
Member since:
2005-07-07

In the release notes they mention support for wider gamut displays - but I'm curious if this means they've added true color management to the system (it doesn't have it in the current release) or if they are just using some kind of flatter hack.

Anyone have more info on that?

Reply Score: 2

Comment by Drumhellar
by Drumhellar on Wed 22nd Mar 2017 20:08 UTC
Drumhellar
Member since:
2005-07-12

Meanwhile, rumor has it I might get my Nougat update this month..... But, probably not.

Reply Score: 2

RE: Comment by Drumhellar
by cmost on Wed 22nd Mar 2017 20:37 UTC in reply to "Comment by Drumhellar"
cmost Member since:
2006-07-16

Meanwhile, rumor has it I might get my Nougat update this month..... But, probably not.


Be careful what you wish for. I have a Nexus 6P and Nougat has been fraught with issues from fast battery drain to Bluetooth connectivity to missing features compared to the cheaper Nexus 5X. And this is a Google phone for the love of Pete! I would leave the house in the morning with 90+% battery and with my phone in my coat pocket all day at work (we can't have them in the labs) power would be in the 20% range at the end of the day. Bluetooth wouldn't connect with my car at all for many months whereas all of my previous Nexus phones worked perfectly. The battery and bluetooth issues appear to have finally been addressed with version 7.1.2 (which is technically a beta) but it looks like you'd have a very long wait to get that high if you haven't yet received version 7.0. With all that being said, this is my last Google phone and I've been exclusively a Google phone customer since I owned the Nexus One. I'm eyeing the Samsung S8 when it comes time to upgrade. Good luck!

Edited 2017-03-22 20:39 UTC

Reply Score: 2

RE[2]: Comment by Drumhellar
by Alfman on Wed 22nd Mar 2017 22:07 UTC in reply to "RE: Comment by Drumhellar"
Alfman Member since:
2011-01-28

cmost,

Be careful what you wish for. I have a Nexus 6P and Nougat has been fraught with issues from fast battery drain to Bluetooth connectivity to missing features compared to the cheaper Nexus 5X. And this is a Google phone for the love of Pete! I would leave the house in the morning with 90+% battery and with my phone in my coat pocket all day at work (we can't have them in the labs) power would be in the 20% range at the end of the day.


I have a BLU phone running 5.1, and every once in a while it gets into a state where the battery looses almost the entire charge in a day. It comes and goes and I wasn't able to figure out why. GSAM battery monitor (root mode) pointed to "Kernel (Android OS)" as the guilty culprit, not a userspace app, yet almost all websites tend to blame applications, so out of desperation I tried background application blockers, of course those did nothing to fix the kernel bug. Because of the severity of the drain, I had to keep it plugged in anytime I was at my desk. I tried powering off and on my phone, but all to no avail.

Then I came across a post for an unrelated 4.x phone, but with the same symptoms. It said to unplug it and then power it off and back on, that's it. I was resetting the phone but I didn't register the significance of unplugging it first. While I was at my desk I would reset the phone while it was plugged in. When I followed the unplug/poweroff/poweron sequence consistently, it actually worked. The Android kernel would finally let the CPU sleep and the battery usage graph showed a sudden and dramatic improvement! It's still a major android bug, but it's a big relief now that I know how to work around it consistently. Since my last charge it has been running for 5 days and indicates 50% remaining.

I can't say if your Nexus has the same bug, if so shame on google, but it's worth a shot. Let me know if that does anything.

Edited 2017-03-22 22:12 UTC

Reply Score: 2

Why not Opus?
by Lobotomik on Thu 23rd Mar 2017 09:02 UTC
Lobotomik
Member since:
2006-01-03

Why is Opus not used as an official BT codec? It is freely available, patent-free, as high quality as any, and offers a wide gamut of bandwidths and latencies.

Not only that, but heavy investors in Bluetooth like Broadcom have invested in developing that codec, so it is not something they are forced to adopt from a competitor. And I believe Google uses it for their web video format, so there are probably hundreds of millions of devices that secretly support it.

I thought the BT codec list was set in stone (to SBC, AptX and nothing else), but that is clearly not the case, if Apple and Sony can use their own.

Anybody knows why Opus seemingly stopped in its tracks the moment it was finalized?

Reply Score: 2

RE: Why not Opus?
by darknexus on Fri 24th Mar 2017 15:36 UTC in reply to "Why not Opus?"
darknexus Member since:
2008-07-15

Because, for representing data other than spoken word, the reference Opus encoder is horrible. In particular, no matter how I adjust the parameters, it does a horrible job at the extreme low and extreme high end of wide-ranging music. The best way I can describe it is that it sounds like there are grains of sand in the audio.
If they want Opus to be taken seriously, they need a better reference encoder. The codec itself is capable, but it is not currently demonstrated well just how capable it really could be. I have a suspician that, if Opus were used, they'd simply stick the reference encoder in place and that would be terrible both for the users and for Opus' future.

Reply Score: 2