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?
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.
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.
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).
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
> 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.
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)
> 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).
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?
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'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.
> 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'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.
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.
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.
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.
> 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.
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.
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.
> 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?
114 comments
[ 8.1 ms ] story [ 241 ms ] threadSeems 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.
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.
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.
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.
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.
"App crashes on open when using my 1989 car phone, 1 star"
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.
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.
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).
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.
Targeting 16 is just incredibly stupid but I have seen some devs unable to read the documentation..
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.
Literally disappeared from all settings this week after a restart.
Have to restore or something equally tedious.
OnePlus 3T got my money instead.
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.
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.
Some people simply do not care about something, that might be a pet feature of someone else.
https://code.google.com/p/android/issues/list?can=2&q=NDK&so...
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...
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.
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...
[1] https://developer.android.com/preview/download.html#flashabl...
https://gherkinstomatoes.com/2010/12/13/oreillettes-a-part-o...
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)
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...
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.
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.
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/
The menu on the second click is Safari menu for the <video> HTML5 element.
Seems that slowly Google is coming round to where Android was heading back around 3.x-4.0.
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.
Why are only OEM-blessed apps allowed to capture system audio output, when any app can already request permission to screen capture?
Option 2: Privacy (call recorders come to mind - unrelated: does anyone know of a working call recorder?)
How?
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).
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.
Where would this meaningless feature-cripling make sense?
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.
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.
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.
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 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."
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.
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.
That would be pretty awesome (no more passwords ! )
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.
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
> 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?