> To better ensure privacy, Android P restricts access to mic, camera, and all SensorManager sensors from apps that are idle.
Good. Now, if only permissions could be granted temporarily (e.g. "allow for this session", which auto-revokes after 5-60 minutes of not using the application), it'll be perfect.
> We will also enable encryption of Android backups with a client-side secret.
Is this about BackupManager? Awesome if so. (BTW, have anyone ever heard of any alternative BackupTransports, besides Google Drive?)
> Android P also gives the user control over access to the platform's build.serial identifier by putting it behind the READ_PHONE_STATE permission.
IMHO, they should've really split that in two different permissions and deprecate READ_PHONE_STATE. Device identifiers (including SIM card identities) and phone state ("someone's calling") are two different things.
FYI, what you're calling phone state (someone's calling) is actually call state (https://developer.android.com/reference/android/telephony/Te...) which does not require READ_PHONE_STATE. That permission seems mostly used for things like protecting SIM card identities.
"Good. Now, if only permissions could be granted temporarily (e.g. "allow for this session", which auto-revokes after 5-60 minutes of not using the application), it'll be perfect."
Yes. There's so many apps that want to manage my SMSes just so they can authorise. It's a nice and convenient feature, but they only need to authorise once. Why should they have permission to manage my SMSes for days and weeks and years afterwards? Short-term permission would be nice, and should be the default. If the app needs the permission for a second session, then it should potentially receive it permanently.
Does restricting access to the mic from idle programs also conveniently prevent any competition to Google Assistant?
That's kind of unsettling because it seems Google is doing a lot of data collection through their home speakers.
An anecdote:
I got a little creeped out at assistant / home and disabled all the tracking. Almost immediately my Android phone started harassing me to turn permissions back on through my phone. And Google Home refused to do anything with tracking off. It responded to all wake prompts with "you need to change settings".
Hotword detection has been a private API since it was introduced. You can't use it unless your app is signed by Google. Android P doesn't seem to change this at all.
Not really, you will just need a foreground service, which you would have needed anyway.
Google has been pretty fair as far as Android APIs go, even the API analyzing your current view hierarchy is open to anybody to implement (IIRC there is of course a big permission dialog to show before allowing an app to use it)
I know. This is what I do every time there's an app that needs accidental one-time camera or GPS access, but not a trustworthy enough to be granted those permanently. Like a banking app that can show me nearby ATMs when I need one (but then I don't want to even theoretically permit my bank to obtain my location outside of this scenario).
Not convenient, as it requires a) not forgetting to revoke when done and b) a series of taps.
> Like a banking app that can show me nearby ATMs when I need one
Android needs an intent for "get current location" rather than "always have access to location". Apps don't need camera permission to let the user capture one image from the camera, only to autonomously control the camera themselves. Similarly, an Android app should have the ability to request one current location fix, for this kind of purpose, and have that trigger an interactive request with a map. (That also makes it easy to do "look for ATMs near where I'm going to be this afternoon".)
Better yet, the app could expose a "points of interest" interface, and then Google Maps or another maps app could make those points of interest available.
1. Apps that track sensor data to determine sleep quality or other nonstandard movement calculation (and thus can't use alternative step counting API's)
2. I'm working on an app that constantly records audio in the background and later allows me to search for things I might have said throughout the day
3. Apps that track location long-term, like the defunct Moves app. Sure it kills the battery and is a major privacy concern so it should be opt-in, but I personally love this functionality and I'm sad there doesn't seem to be a modern equivalent (Google Maps location history is less accurate and there's no good API). Apps that record location short-term like MapMyRun do not solve the same problem.
... I'm sure there's other use cases. I kind of feel like the only developers allowed to really innovate on mobile anymore are Google (and Apple) themselves. Bad developers abusing privacy/battery/data have made it so Google/Apple have to lock down anything interesting. It's frustrating, because the current state of affairs is definitely better than the free-for-all it used to be, but I wish I had more control to override what my own device is able to do.
For #2, how do you avoid recording all the things people around you are saying throughout the day? Custom microphone to minimise picking up surrounding sounds? Some kind of speaker recognition to identify and isolate your own voice (does that work when you have a cold)?
And if you're not avoiding recording other people, how do you succinctly notify everyone in capture range that you are recording them?
This seems problematic from a standpoint of social norms and etiquette. In public/shared space contexts people know they can be heard by bystanders, but that is very different from being recorded and having your utterances indexed for later retrieval.
Sounds like all these apps can use a foreground service to do that.
Am I missing something ?
The only case I see this change not covering is apps like Cerberus. They would need to ask their users to go to settings and hide their notification.
Not the nicest UX, but that's a pretty rare use case.
A foreground service needs to display a notification.
Not really an issue for Spotify since media apps want to display the media notification anyway.
For other apps, the idea is that foreground services should be visible to the user.
One of the reasons would be this very capability to access sensors.
Another difference between foreground and background is that a background service is eligible to be killed on low memory events.
We are developing an app that does #3 (Smarter Time) and manage it with a foreground service. The constant notification is slightly annoying for some users, but overall it works well and does not use too much battery (after tons of tweaks and optimizations)
Well it's also my first foray into Android development since Google Glass years ago, so not much good source to share. Maybe someday if I get it in a state where it works and isn't too embarrassing, I may open source it.
Regardless it's encouraging to hear that other people find this interesting, most of the feedback has been along the lines of "that's so creepy/illegal"
I was hoping we could use old phones as IP cameras with the screen turned off. I hope apps that are last in the foreground can continue to access camera and microphone and sensors with the screen turned off -- at least when connected to power.
One thing I'd really like to see Google try and fix is upstream kernel support for the phone platforms. Right now there's no chance for an open-source project like LineageOS to be able to support all devices properly when each and every single device is stuck on an old kernel often with a bunch of important CVEs unpatched. It's as if Ubuntu needed to do independent development for each and every laptop. Without something like that buying an Android phone is a mine field of various states of broken software provided by phone manufacturers. It's like trying to buy a consumer wifi router without the knowledge that if it's supported by OpenWRT you can just ignore whatever broken software the particular manufacturer put into it and will never support going forward. The first rule of hardware is that hardware makers can't do software and Google seems to have mostly given up.
This is Google's attempt to do this, in a sense, but as the sibling post points out, vendors are so resistant to adoption that it's just slowing Oreo uptake. And yes, Treble just abstracts the framework from the kernel - but it requires a much more modern baseline and the common HAL interface should make kernel front-porting much easier and therefore allow manufacturers to ship less broken kernels.
I work at a hw vendor that builds android for our SoC and we're still on N, but it's not because we're resistant to adoption of treble.
Treble has been more like the straw or boulder to break the camels back. Not only is it a lot of work on its own, it has also triggered a bunch of refactoring.
People are actually excited about Treble and how it should make kernel and android updates easier in the future. It's just a lot of work in the short term.
Not really, it would a real attempt if it was actually enforced, but given that Nougat updates to Oreo don't require Treble certification, and the OEMs are the ones expected to deliver any kind of updates, it is pretty useless to change the current state of affairs.
I mean, Google are requiring it for all Oreo launch devices, which they all must be after the P release (you can't get certification for Nougat after P releases).
Eh, that might be true today, but I doubt we'll see flagships shipping with Nougat still by the end of the year. I certainly won't be buying any like that primarily for this reason. OEMs will catch up sooner or later. It's a slow process, but don't write off the long game for the short one.
Once P is released they won't even certify Nougat devices anymore.
Aren't they contractually obligated to comply with CTS / VTS in order to get the Google Play stuff? The Chinese OEMs and Amazon Fire line opt-out, but pretty much the rest of the Android ecosystem opts in.
That's only a way to get shiny new Google stuff over the supplier's extremely crappy base that will be even less likely to ever get upgraded. The fact that people point it out every time I mention the mess we're really in shows how it's a step back because it takes weight off the issue.
I see what you're saying - that having a common HAL interface will allow Google to ship newer Android over the same broken kernels. However, the base requirements for the Treble kernel and certification require a level of quality beyond what most manufacturer kernels currently offer, so I think it's at least a step forward before it's a step back.
My point is that if it's indeed a small step forward, which is highly debatable, it's a huge step back from actually solving the underlying issue. Lenovo doesn't ship a half broken Linux kernel every time they release a new model. New stuff just gets rolled into upstream and then hardware gets support for close to forever. I bought an Android phone 4 months ago, selected specifically to be supported by LineageOS and in the top 20 in terms of usage. As it turns out support will not be added to the next Android version because specific kernel support would be needed and there's just no reasonable way of achieving it.
It's a fairly big step forward for the common user. There are two parts to it. The kernel used by OEMs is now mandated to be an eLTS version, which is 4.4 now, and the kernel will get backports for another 3 years I think. Treble makes porting new AOSP versions easier. It doesn't affect the kernel version too much directly, AFAIK. However, with 4.4 and treble, every device should get updates for another 3 years. And 3 years is better than 0. So there's that. About your phone purchase, there is no other manufacturer that has done a better job than Google so far. So if you care about these sorts of things, just buy whatever Google sells.
>The kernel used by OEMs is now mandated to be an eLTS version, which is 4.4 now, and the kernel will get backports for another 3 years I think.
That's only true if someone is willing to actually apply the changes over the hacked up kernel the manufacturer shipped. Even well organized projects like LineageOS don't manage to do that:
Not upstreaming changes is the issue. That's what makes you stuck on an insecure kernel, not the particular kernel version. Having an LTS kernel will help but it doesn't solve anything.
>However, with 4.4 and treble, every device should get updates for another 3 years. And 3 years is better than 0.
Maybe most devices will get an update of the Google shipped stuff for 3 years. Most will not get things like Spectre mitigations in their kernels. And because Treble will be an argument for why this issue is fixed the long term outcome keeps getting worse and this will never get fixed.
>About your phone purchase, there is no other manufacturer that has done a better job than Google so far. So if you care about these sorts of things, just buy whatever Google sells.
For what I want, a proper upstream kernel that has a chance of being supported going forward, Google phones are no better as far as I've seen. They're just subcontracted phones to one of the manufacturers anyway.
Just rhetorically, if it's the response to your concern every time you write a post, then you need to incorporate why it's not a solution in your original post. I assumed you hadn't heard of Treble and was just about to point it out to you.
1.) Android kernel patches are pretty extensive and Linux folks (understandably) don't want to integrate several of them. Some powersaving things, binder and a few others are pretty Android specific and very intrusive, so the mainline kernel folks don't want to accept them in the current form. I doubt there's a business payback of rearchitecting the core of the OS just to mainline those patches.
2.) SoC manufacturers refuse to opensource drivers and refuse to support their chips for longer than a year or two. Treble should help a bit with OS updates/LineageOS but at the end of the day, you're at the mercy of the guy building your sillicon. And currently they have all the leverage since there's practically no market competition.
Actually the baseline patches are perfectly fine and most of them are integrated (in staging) already. Only cpu governor is not and it is not really required.
What is not is obtuse patches of chipset manufacturers. These are really low quality...
> "when each and every single device is stuck on an old kernel often with a bunch of important CVEs unpatched"
As an iPhone user, I've heard about how one of the benefits of Android is that it's built on OSS, so that if you wanted to have a fully secure phone, you could just download the latest kernel and patches and software and install it yourself. Is this actually possible for Android users?
Phone manufacturers always buy the drivers from chip manufacturers, and under closed licenses. The source is rarely ever published, you can't download the kernel patches and do anything. Often you'll wait months or years to get the kernel the manufacturer used, and it will have been so old that none of the drivers will work on a recent linux kernel anymore at all.
The situation isn't exactly great. And torvalds believes it to be more important to talk nice to these companies than to enforce the GPL, so nothing's been moving in the past decade at all.
Yeah, the only hope we've got is to move to a more Windows-style driver model, which is what Treble attempts to do, abstracting the HAL from the kernel and application software. This is already shipping in Android O and new devices on O or P must be Treble certified to ship Play Store, so we should see this improved greatly in upcoming devices.
If they are fully compatible it means community updates can work better too - not needing to worry about the HAL as much.
Yes, Google might need to take one more step of saying "and we ship the security updates" before the average user benefits - but that can be done down the line if the situation merits it. Developers and power users will be able to take advantage of it even sooner. A single codebase for LineageOS? Yes please!
To an extent. You'd have to be pretty tech savvy and fairly involved in both ecosystems to actually run your own android builds and stay on top of security.
I know of one example of an Android OS which is focused on security and privacy. Check out CopperheadOS [0]. Their technical overview [1] details some of the improvements.
* Possible disclaimer? I run CopperheadOS on my old Nexus 5X.
Are you sure it isn't iOS security that's the real joke? I mean, just do a search on YouTube for all of the lock screen bypasses. And then there's Cellebrite and their ability to unlock any iOS device for the relatively paltry sum of $1500 or you could just wait for a 2 for 1 special and do 2 for $750. The Pixel phones are virtually unhackable and not one has ever fallen at a PwnToOwn event. iOS devices, on the other hand, always fall at these events.
There's a predefined window for when a device can be certified for release with a particular Android OS version. I don't know what the current window is, but devices that are shipping now (Q1) likely got certified some time last year in Q3 or Q4, well within the window for N.
It's significantly harder to enforce things like update requirements after a phone ships - for one thing, it's not entirely up to the OEM in many cases, it also depends on getting carriers to certify the upgrade.
Once a device is certified, a manufacturer can keep selling it indefinitely, I believe... and/or those may not be actually Google certified devices. (Especially with very low end / no-name handsets.) When I referred to "shipping" devices, I meant new devices coming to market.
Hasn't this been a thing since forever on Android? People are always lamenting that uptake of the newest version (or newest 2 versions) is slow.
Do you actually have evidence that the uptake of this specific version is slow? Otherwise I don't see any reason to believe this is out of the ordinary for Android.
I remember when it took forever to go from Donut to Eclair on my T-mobile MyTouch device... when the newest version was already Froyo.
Are you able to see something I can't? I get a few pie charts showing current use in the last seven days, but I can't see any evolution (e.g. I might expect some kind of line graph with time along the x axis, proportion on the y axis and separate lines for each version; or maybe a 2D table with again time as an axis).
Or perhaps you're just accustomed to monitoring this? With respect, I don't think that constitutes (neutral, inspectable) evidence, but rather witness testimony.
They'll have to move at some point. If the transition is painful/long, so be it. The affected companies is why we're in this mess in the first place. Now Google enforces the new rules about the platform compatibility, so let's see how it plays out.
We're at the point where not much matters anyway. The phones we have are amazing. Sure, it doesn't make much difference, but it's a selling point.
Other advertised features which don't matter to most users: the notch, AR, full size display, active display on edges, assistant updates, AMOLED, app privilege restrictions, curved displays, ... They're all good for advertisement and gimmicks. They may improve the phone a little bit. They're not needed and almost everybody cares only because they were advertised. (If they care at all)
I'm not sure how that is related to my point? I don't use expensive Samsung devices either and won't be updated to Oreo any time soon.
But Samsung does have a large market share and them moving to Oreo right now will make the numbers start to shift pretty quickly.
Basically, Android adoption tends to be glacially slow for quite a few months (~2% total), fast for the next few (up into the 20% range), and then the growth slows again for the next year or so with no single version ever quite hitting 50%.
> Right now there's no chance for an open-source project like LineageOS to be able to support all devices properly when each and every single device is stuck on an old kernel often with a bunch of important CVEs unpatched.
No even if this was fixed it still wouldn't be possible.
For those outside of this US a fix would helpful, but a fix really wouldn't be that simple. For those in the US most phones bought by major carriers have both locked boot loaders and are locked to a specific network. The Pixel being sold by Verizon has a locked bootloader despite it being Google's own branded phone.
It would be simpler just to tell OEMS that they can't distribute computers where the user is locked out of the machine. Safety oriented exemptions may be reasonable but it needs to directly speak to consumer devices first and foremost.
Kotlin is a first-class language on Android, and if you haven't tried it yet, you should! We've made an enduring commitment to Kotlin in Android and continue to expand support including optimizing the performance of Kotlin code. In P you'll see the first results of this work -- we've improved several compiler optimizations, especially those that target loops, to extract better performance. We're also continuing to work in partnership with JetBrains to optimize Kotlin's generated code. You can get all of the latest Kotlin performance improvements just by keeping Android Studio's Kotlin plugin up-to-date.
How is Google looking at Java vs Kotlin vs Dart. If Flutter is indeed a long term strategic investment by Google, then why not Kotlin ?
Flutter guys explained why Dart: at the time they were making decision they looked at bunch of languages and Dart came at the top. At the time Kotlin either didn't exist or was at extremely early stages.
Regardless of history, Kotlin is, in the end, a JVM language. If you want to ship a Kotlin app, you need to ship JVM. Getting JVM to a reasonable size is a great technical challenge not to mention Oracle made it clear what they think about other companies reimplementing "their" APIs.
(I do know about Kotlin Native but that's far, far future).
Also, Google is not a Borg or centrally planned economy with 5 year plan.
Flutter happened because a bunch of Chrome devs wanted to experiment with a better way to write mobile apps, not because Larry dictated that "Flutter is now long term strategic investment, so go and do it".
Flutter happened to be a promising technology so it's getting increased attention and funding. But it could just as well fail, like AtScript did.
Do note that this is without the weight of Google's support behind it. I'm not quite sure why you say its far-far in the future. Given Flutter's own maturity, I dont see them being very differently placed in terms of production readiness - https://flutter.io/faq/#should-i-build-my-next-production-ap...
Kotlin is a perfect bridge - works brilliantly on the JVM, works brilliantly natively, everyone loves it, simple migration path from Android -> Fuchsia
I wish they'd consider moving away from Java, Kotlin and really any JVM-basis for the platform entirely. I just can't stand development on that platform. It's got all the worst elements of "enterprisey Java" style development.
> "It's got all the worst elements of "enterprisey Java" style development."
What are your complaints about "enterprisey Java" development? Is this just a repackaged "text editor vs. IDE" complaint, or do you have other points you'd raise against Android development?
One of the largest issues of Android P is that the Nexus devices will never get it.
So if you as developer want to get the developer preview, the cost for that just went from 270€ (Nexus 5X) to over 759€ (Pixel 1), and the Pixel 1 isn't even available in major markets such as France.
So now a huge number of developers has no ability to test their apps on the latest version of Android.
For me, personally, this means I won't be able to support Android P, I won't be able to replicate bugs, and in worse case (as happened before once) I'll have significant bugs in my app, no way to replicate them, and no way to fix them, because the bug doesn't show in the emulator, and I have no device to test on.
Google's really shooting themselves in the foot by offering no way for developers to get an affordable testing device anymore.
I imagine you never had the "pleasure" of using Google developed emulators.
Why do you think 3rd party emulators like Genymotion exist?
Even Microsoft created one from scratch before Google bothered to reboot their own implementation.
In any case, thanks to OEM customizations, even if it runs perfectly well on the emulator there are zero guarantees that it will work on the actual devices.
> As part of a larger effort to move all network traffic away from cleartext (unencrypted HTTP) to TLS, we're also changing the defaults for Network Security Configuration to block all cleartext traffic.
Finally! I know Apple originally promised this for iOS9, but I believe it eventually went back on its word? Is HTTPS mandatory for all iOS apps now?
> We will also enable encryption of Android backups with a client-side secret.
Did they just one-up iOS11 here? This one almost seems like a shot at Apple's recent security degradation for iOS.
> In Android P we continue to refine Doze, App Standby, and Background Limits to further improve battery life; please be sure to try your apps with these and send feedback.
How about you start showing me the apps that are actually draining my phone's battery, and stop allowing them to hide behind Android OS and System. Battery stats are virtually useless these days because they don't even tell you half the story.
> How about you start showing me the apps that are actually draining my phone's battery, and stop allowing them to hide behind Android OS and System.
Nobody is "allowed" to hide. It's simply an estimate based on a crude model. Power tracking is not an exact thing, it's guesses by the system on observed patterns with attempts to weight the blame for certain actions.
One of those categories is also the "we have no idea where the power went, there's just this big gap between our estimate and what the battery says is left, so... put it there"
To expand on this a bit, look at location services on a phone.
A "fine" location access event is a "high power" event, it takes a lot of battery and should be done as infrequently as possible.
Apps on android have the ability to say "i want to get location at least once every 30 minutes". A naive implementation would give every app that asks for this a timer, and when that timer ticks off, that app gets location information. For 5 apps, that could mean 5 times every 30 minutes!
But android is a bit "smarter", it will do it once in the 30 minute period, then give that same info to all 5 apps.
But then the question is, who caused that battery usage? None of them? All of them? Should adding a 6th app into the mix cause all of the battery usage of the other 5 to go down proportionally? Technically that 6th app is pretty much "free" in terms of actual power usage...
What about if an app says "I want location whenever you get it, but I never want to trigger it on my own", where do you allocate it's usage?
And that's just one API. Now imagine that with wakelocks, radio usage, accelerometer/gyroscope usage, etc...
Or even CPUs & GPUs also power-gate chunks of their internal features. A CPU's power draw at a given voltage & frequency is not fixed. It depends on the actual instructions being executed. Taken to the extreme you end up with things like Intel's AVX512. So how do you calculate the app's CPU power draw? If they are using highly optimized SIMD power draw is going to be much higher than that of a CPU that's constantly stalled out waiting on dependent memory loads (aka, typical Java code)
Are you sure about this? AFAIK, iOS will not do client-side encryption for iTunes backups (which is the equivalent to what's being talked about here) since iTunes still asks for a password to encrypt your backups. Although, I'm pretty sure it does for iCloud ones.
> How about you start showing me the apps that are actually draining my phone's battery, and stop allowing them to hide behind Android OS and System. Battery stats are virtually useless these days because they don't even tell you half the story.
Android 8.0 introduced a notification that deliberately shows you when an app is draining battery in the background.
"Indoor positioning with Wi-Fi RTT" a hacker group I've worked with was working on this same problem! Glad to hear there will be an official api for it all, their work was some fascinating albeit somewhat jank stuff with building maps and marker beacons.
I've also been working on this for a couple of years. I am just about to release a new version too! [1] Glad to see Android is putting their own out there, I am excited to try it.
Enterprise Wifi access points have nanosecond resolution timestamps (necessary for RTT based positioning) since several years. Consumer class wifi radios are only precise to the microsecond. So 802.11mc capable devices will apparently gain nanosecond resolution?
If I remember correctly from the research I did for my Wifi positioning project in university RTT shouldn't be much better than RSSI in real environments. Could improve fancy fingerprinting based machine learning though. An API to set the wifi radio to monitor mode and collect all MAC addresses and corresponding RSSIs on the ether would be more advantageous for precise positioning.
My Senior Design Project, for getting my BS in Computer Engineering, was around indoor positioning. Granted we did it with Bluetooth and not Wi-Fi, but it's awesome that there'll be an API for it.
A client asked me to create an indoor positioning system. I ended up with using WiFi signals and classification algorithms to decide where among the pretrained coordinates the device is.
"On select Android devices, the Interpreter will use the Android Neural Networks API for hardware acceleration, or default to CPU execution if none are available."
> As we announced recently, Google Play will require all app updates to target Android Oreo (targetSdkVersion 26 or higher) by November 2018
Android Oreo is only running on 1.1% of devices [1]. Will targeting the newest API prevent the app from being available for in the market for devices running Nougat or earlier or does it just limit the functionality?
There are two API levels for Android Apps: The minimal API level and the target API level. Perhaps it makes sense to see the target API level as the "maximum" API level the App fully understands.
For instance, Android can't enforce dynamic permissions on older Apps not designed for this, and people have been exploiting this by keeping the target API level low.
Android apps declare two versions. Basically, the oldest version they can run on, and the newest version whose quirks and new behaviors they're aware of.
A good concrete example is the switch from making users agree to permissions when they install an app to runtime permissions. In the new style, the app is responsible for bringing up dialogs to ask for permissions. In the old style, the system does it when you install. So how does the system know whether your app knows how to ask? By setting targetSdkVersion to 23, you tell the system, "It's safe to assume I know about this new API I'm required to implement." But that doesn't preclude your app from running on older systems, where things behave just like they always did.
Just so we're clear on scope - 1.1% of global Android devices is still 20+ million customers. That's 2/3 of all iPhone X devices sold by the end of 2017 (quoted at 30 million).
Also that dashboard can be misleading - if you check any english app you'll probably have more like 40% of 7.0 and 10-20% of Oreo deployed.
As for targeting - targetSdk determines against which version of Android APIs are you linking against (the stub .jar) and by extension which compatibility shims will new Android versions use. If you listen to a linter and properly guard usage of APIs added in newest Androids then the app will run well on old Android versions as well.
The main benefit of this change is security - if your app doesn't target Android 6.0 or newer, it's exempt from the new permissions system introduced in 6.0.A lot of companies, including large ones like Facebook and Snap, deliberately refused to support new Android features so they could access hardware and collect data without explicitly asking for permission.
This change forces them to start using those new APIs.
We introduced the Neural Networks API in Android 8.1 to accelerate on-device machine learning on Android. In Android P we're expanding and improving this API, adding support for nine new ops -- Pad, BatchToSpaceND, SpaceToBatchND, Transpose, Strided Slice, Mean, Div, Sub, and Squeeze. If you have a Pixel 2 device, the DP1 build now includes an Qualcomm Hexagon HVX driver with acceleration for quantized models.
Can someone tell me what this will most likely be used for? I'm not familiar with the field.
Very briefly: operations like Transpose, Strided Slice, Padding, and batching are standard operations used to build Convolutional Neural Networks, which is in turn is a standard building block for a vast array of machine learning applications (eg, image recognition)
Ah, cool. So is the goal with having this tech on the phone that the phone won't need to communicate with servers to do this sort of processing? I'm struggling to think of a use case for this.
> the goal with having this tech on the phone that the phone won't need to communicate with servers to do this sort of processing?
Yeah, that's basically it. In short, the operations listed are pretty computationally intensive on a CPU, but pretty easy to parallelize for the data structures that are commonly used in machine learning (matrices and tensors). I presume that, by creating an API, Google can abstract out these common ML operations to work on the most efficient hardware on the device, whether a GPU or custom ML hardware such as Apple's Neural Engine. In theory, this should make on-device machine learning and inference more power-efficient, and could reduce reliance on server communication, improving privacy and probably making lightweight ML applications feel faster.
Any chance the original Pixel's kernel version (3.18) got updated ? All android devices get frozen in time with the kernel they ship with due to blobs. Nothing new. Just checking if that is ever going to change.
2 years and 5-6 Months to be fair and it will probably be exactly three years old when Android P gets released. In my opinion this is ok because they have been very upfront about the updates from the beginning (two years system updates and three years full security updates). Also backward compatibility for new apps will be there for a really long time. I would also add that it s preferable to the slow iOS situation: "No update" is better than "broken update".
If they said that in advance, the only thing that it bought them is no legal action. (Though no-one would bother getting a lwyer over something this small...)
Such a period is quite short, and maybe too short for a resourceful company like Google. They should be able to do better; I'm sure the "old" hardware can manage. (Else you've got a problem with your software.)
> 2 years and 5-6 Months to be fair and it will probably be exactly three years old when Android P gets released.
If you bought it just after release, I bought it in March 16. It already had the battery replaced because of crappy hardware. I thought Nexus would last longer than this.
The iOS slowness was a deliberate design decision. We can criticise Apple for making the phones deliberately slow
You shouldn't be using a phone that doesn't have security updates, consequently, if an Apple phone becomes unusably slow after three years due to updates (including security fixes) and an Google phone becomes dangerously insecure after three years because it doesn't have updates, actually, the more responsible company is Apple. At least they're making it the choice of the user whether to continue safely and slowly or get a new phone. Google just lets their users become malware vectors.
(NB. I had an iOS phone and recently switched to an Android phone that now runs Treble-less Oreo. From a perspective of user experience, I feel like I made the right decision; but from a security perspective, I feel less confident.)
Wow.. before I switched to iPhone I had a Nexus 5, released in October 2013. The iPhone 5S was released a month earlier in September 2013, and got iOS 11. (Though maybe this is what the other commenter means by a slow broken update?)
Depends on the storage/battery degradation. I have a lightly used 5S and iOS 11 works just fine (no major lag or stutter). But I'm sure people that have a heavily used 5S will have a different experience.
Does Google release bugs that were fixed in each release? Im still waiting to hear if they fixed the MS Exchange syncing using Gmail that was broken in Android O. It's near impossible to tell what is working or broken between releases.
> [W]ith Android P we're starting a gradual process to restrict access to selected non-SDK interfaces, asking developers -- including app teams inside Google -- to use the public equivalents instead. In cases where there is no public equivalent for your use-case, please let us know -- we want to make sure that this process is as smooth as possible for developers, so we'll use your feedback to ensure the initial rollout only affects APIs where developers can easily migrate to public alternatives.
What's the situation with private API use on Android? What can you do with private API? Will you be rejected from the Play Store if you use it?
> Starting in the next release of Android, some non-SDK methods and fields will be restricted so that you cannot access them -- either directly, via reflection, or JNI. If you try, you can see errors such as NoSuchFieldException or NoSuchMethodException.
Yes, how is this done? Using SecurityManager or something similar?
Not a joke / easter-egg. RELU6 is an activation function commonly used in deep convolutional neural networks. It comes up fairly often in mobile machine learning cases because it's used in Google's optimized MobileNet architecture and would cause errors when trying to convert to run on device.
The original paper detailing the function is here (PDF warning):
"Our ReLU units differ from those of [8] in two respects. First, we cap the units at 6, so our ReLU activation
function is:
y = min(max(x, 0), 6).
In our tests, this encourages the model to learn sparse features earlier. In the formulation of [8], this is
equivalent to imagining that each ReLU unit consists of only 6 replicated bias-shifted Bernoulli units, rather
than an infi nite amount. We will refer to ReLU units capped at n as ReLU-n units."
What I want to know is what they plan to call this version of Android. Android Pez, Android Peeps, Android Peppermint, Android Pudding, Android Pie, Android ummm im out.
Android has two ways of PWAs currently, either as a more complicated bookmark (with the icon) or with Chrome generating an APK on the fly, Google signing it on the fly, and it then being installed.
Obviously, this is only available to Chrome, and not to any third-party browser (the EU antitrust commission is gonna love this).
Seems that with every release, Android falls further and further behind iOS. Every iOS release is jam-packed with huge new features. One of the "top" features of this release is... a notch?
Do we still have to deal with 4+ messaging apps?
And to throw salt in the wound, 90% of users won't see this until 2020. :/
Yup. Notifications in Android - actually useful. Notifications in iPhone - good luck. You'd better not be using your phone, and you better not have two notifications you want to receive. Otherwise they just disappear. But iPhone's notification dots >>> Oreo's.
The Android keyboard (Gboard) is generally better, and emoji specifically. I never have problems finding the emoji I want on Android (because I can search for it), but on my iPhone I would sometimes if I'm lucky get a suggestion that if I'm lucky I would be able to see (or else it might just be ...). Otherwise it's just search through a giant list and hope my idea of where it belongs is the same as the developers'.
There is just not enough incentive for Google to implement features that will prevent them from tracking you, so you get the least privacy protecting feature: the notch...
I think the writing is on the wall for Google's Android. There is some analysis that Android, from a business perspective, did not work out all that well for Google. My best guess as to the future state of things:
1) Pixels move to Fuchsia, native apps are in Dart/Flutter, compatibility layer for Android. Fuchsia becomes a distinguishing feature of Googles hardware, and allows Google to differentiate vs Android competitors.
2) Google continues to support Android, but only as it affects their business interests (as a funnel for search).
3) Google migrates some service level functionality away from Android and Pixels become a first-class citizen in Google's ecosystem.
If you look at Google's moves over the past 5 or so years, you can seem them try to mitigate the fact that Samsung was basically the biggest winner of Google opening up Android (Motorola Mobility acquisition, Pixels, Project Fi).
Google sees that voice is unable to be monetized (from an advertising perspective), and is attempting to replicate Apple's strategy by creating a new revenue stream from hardware. This has the added benefit of capturing the most profitable users from Apple. It is a very big bet, and I would not want to be going up against Apple in a mature market. It will be interesting to see how it plays out!
Ben Thompson has a pretty great take on these large shifts within Google [0].
Android isn't just about making revenue, it's a hedge against other companies having too much control over a major channel. The same goes for Chrome.
Android and Chrome may not make money, or may even cost money, but they're probably better than giving up that control to a third-party like Apple or Microsoft...
> There is some analysis that Android, from a business perspective, did not work out all that well for Google.
Google is the default service provider and owner of the world's largest OS and that somehow is something that "didn't work out all that well for Google"?
I read the Ben Thompson link, and honestly I have to disagree that it offers any insight as to the future of Google or Android. It reads like a just so story, and seems to be crafted according to the following recipe:
1) Talk about a company's previous initiative that was a big deal at the time and which failed, and talk about why it was so obvious to you that it was going to fail. Describe the events surrounding it's failure and why no one but you was able to put the pieces together about why it was doomed from the start. This makes you appear very smart indeed, and makes the author intrigued to read your thoughts. Thompson does this when talking about Android and the turn by turn navigation feature, and in fact, Android itself.
2) Talk about the company's current initiative and why it is a brilliant idea, that avoids the obvious pitfalls that the previous initiative fell into, and why you are optimistic that it will be a great success. This allows you to ingratiate yourself as part of the "move forward" culture of the valley, instead of being some sort of negative nancy who is always being pessimistic. No one likes that guy after all! We're too busy moving fast and breaking things!
If you follow the link at the bottom of the article you'll see that the adjacent article has the author writing a large number of words talking about what a great idea Snapchat Spectacles are, why google glass was obviously a terrible idea that only they were smart enough to see beforehand, and why this new wearable is obviously way better. Thompson is optimistic about it succeeding!
Obviously we know how that turned out, and comparing the two articles should give one a lot of pause about investing too much faith in his analysis going forward, especially when you look at the structural similarities between the two essays.
For one thing, Google's inability to monetize Android better is it's own bad execution. There's nothing inherently bad about the Android platform, from a monetization standpoint.
Google's pixel & nexus phones have never dominated the market - and for good reason - they're not the best. If Google can get their hardware act together, they can see a windfall in revenues/profit.
I think with the Pixels, Google is at least making an effort at having the best hardware. They still have some things to figure out regarding marketing, logistics, keeping design language consistent, etc, but at least for now, they seem to be working on it.
Good. Now, if only permissions could be granted temporarily (e.g. "allow for this session", which auto-revokes after 5-60 minutes of not using the application), it'll be perfect.
> We will also enable encryption of Android backups with a client-side secret.
Is this about BackupManager? Awesome if so. (BTW, have anyone ever heard of any alternative BackupTransports, besides Google Drive?)
> Android P also gives the user control over access to the platform's build.serial identifier by putting it behind the READ_PHONE_STATE permission.
IMHO, they should've really split that in two different permissions and deprecate READ_PHONE_STATE. Device identifiers (including SIM card identities) and phone state ("someone's calling") are two different things.