Android M Developer Preview and Tools(android-developers.blogspot.com) |
Android M Developer Preview and Tools(android-developers.blogspot.com) |
"We are giving users control of app permissions in the M release. Apps can trigger requests for permissions at runtime, in the right context, and users can choose whether to grant the permission. Making permission requests right when they’re needed means users can get up and running in your app faster. Also, users have easy access to manage all their app permissions in settings."
Great, finally Google got it. Hopefully with the old Android 2.3 style fine granular permissions and not the few permission groups of Android 4/5.
EDIT: The permission groups are
Location
Camera
Microphone
Contacts
Phone
SMS
Calendar
Sensor
- Read external storage
- Internet
Currently you can change app permissions once an app is installed, but they gain all the permissions they ask for when installed.
If each app has to be updated by the developer for the changes to take place, it might take a while for this to have any large effect on the ecosystem.
Google isn't releasing more details on it, but with it, Google would be able to understand what you do, when you do it, who your pals are, who you go out to movies with, who you chat with the most, are you looking to quit your job, are you about to break up, are you going through a depression and so on...
They haven't revealed anything about how exactly 'Now on tap' works...but the potential for data collection is enormous. With 'Now on tap' they promise to do 'searches' based on the context (which is derived from the contents in the app that's showing on-screen). So no matter what app you're using, Google will get its hand on the data. It sounds nightmarish and exciting at the same time.
Without any further clarification i have to expect Google now to send the displayed data of my mobile banking app to its servers everytime i hit that "Now on Tap" button, accidentally or not, while its open. I don't like that.
Sounds a lot like the NSA.
In other words, that's cool about Android M, but most people aren't even using L. (40% on K, 9% on L whose preview was the 2014 IO)
Can Google not poach one or two of Apple's negotiators to go to the right meetings at Motorola, Verizon, etc to talk about updates?
Will this improve wakelock performance that has been plaguing Android for years?
No, this won't magically fix bugs in apps that lead to poor battery life. If an app opens the camera and forgets to close it, yeah that's gonna murder your battery.
Whenever i have something odd going on with the battery life, some app is sitting right up there with Android system for CPU time (sometimes even above). And you don't hit those kinds of numbers even with heavily used apps like web browsers (and yes, the most frequent offenders are the Facebook slop that i only have because family).
"Unsurprisingly, there are three apps set to ignore battery optimization by default—Google Play Services, the Play Store, and Download Manager."[1]
So, nope. GPS will continue to do whatever they want and poll location every 60s.
[1] http://www.androidpolice.com/2015/05/28/android-m-feature-sp...
So ... they're taking a terrible problem and making it even worse ?
(I'm unemployed and don't really want to pay for a 64-bit system. Anybody want to hire me so I can afford a new computer?)
So at least we can make use of some C++ love, even if the frameworks access is limited.
Retrolambda is rather useful to get a subset of J8 features.
"The M Developer Preview includes an updated SDK with tools, system images for testing on the official Android emulator, and system images for testing on Nexus 5, Nexus 6, Nexus 9, and Nexus Player devices."
So, no.
Finally! I had to start developing for Android not too long ago, and I couldn't stand seeing "mandatory" material components for certain usages that weren't supported in the official SDK.
In general the UI components are moving out of the SDK into the support libs or the community at large. RecyclerView & Toolbar are examples of Google untangling the foundation from the look & feel, and letting the community come up with the final implementation of things.
And downloads page: https://developer.android.com/preview/download.html
Does this mean gdb integration with android studio? That would be fantastic! Working with the NDK has been a pretty painful at times, and this change will make a lot of people very happy.
That image... Seriously, when will Google stop doing things like these? Will they ever learn to be attentive?
I am the lead for an app with >250,000 installs. Over 45% of our usage is coming from Lollipop. The rest is JB & KK. We see <6% ICS for the last 30 days.
I know other major apps that have even better numbers.
Looking at my data, L usage was basically nil in January 2015. There was slow growth from there until April, when we saw an inflection point in the number of Lollipop users. This aligned with the release of several Samsung updates that pushed Lollipop to some of the most popular devices out there.
If you want publicly available numbers, I would rely on Mixpanel[1] not the Android dashboard. And even this understates it, as of writing this comment Mixpanel is not including 5.1 in the Lollipop numbers which is cutting 2-3% off that. [2]
[1] https://mixpanel.com/trends/#report/android_os_adoption [2] https://twitter.com/mixpanel/status/604025242529308672
The narrative about Android fragmentation is really out of touch with what I experience on a daily basis.
About 25% of our users are below ICS even. Yes, one quarter of our users are on Gingerbread.
And then the rest is shared equally between JB, KK and L.
https://developer.android.com/about/dashboards/index.html?ut...
I'm learning Android development by building a basic app that I've always wanted but couldn't find in the play store. I'm targeting SDK 21 and minSDK 19 and was afraid of having a small userbase (based on the dashboard numbers). That means that I can continue to focus on the latest SDK and leverage all the good SDK 21 features :)
So yes you'll have to wait ~2 years for the majority to be on M or higher. Oh well. Does that suck? Yeah. Is it a major, show stopping, "omg google why haven't you devoted 100% resources to fixing this?" issue? No, that's absurd.
And why do you think Apple has negotiators for this? Apple doesn't license iOS to anyone. They've never attempted to solve this problem. Ever. For anything.
Why shouldn't Google be devoting resources to solving this issue ? Being unable to upgrade is a massive security risk and prevents developers from rolling out new and interesting features in their apps.
It is largely a solved problem. You have a core OS/SDK which is upgradeable and some sort of plugin style architecture around it for themes/new features. Sure some OEMs may ignore it and fork the OS but then Google has the leverage of Play Services / Android brand they can use as a stick.
And whether iOS is licensable or not is irrelevant. For their particular phone it is upgradeable without carrier intervention. Why is every Android phone different ?
I don't understand why things like these are necessary in the USA. Why should network operator have control to which version you're running? Most other places you can just get new firmware directly from manufacturer.
Even if it weren't a contractual obligation, I can't imagine, say, the AT&T store loading a phone right now with iOS 7
Depending on how you define "version", 2 versions back is Jelly Bean. 90% of our users are on Jelly Bean or newer.
3 versions back is Ice Cream Sandwich, which in my case includes 99% of our users, and we only dropped Gingerbread support Christmas of 2014.
Facebook for example is known to siphon your contact list as soon as the app is installed, so even if you remove the permissions from the fb app, it is already too late.
Not ideal, but it works if its really an issue. Actually FB does not consume much bandwidth unless you are using it.
I never advise hacks for production code. Either it is first class support or it doesn't get used.
Adding extra layers to debug only increases production costs.
Forcing them to ask every time will either show my concern is wrong (a good thing) or stop them doing it (even better).
If you add an Android-specific class like TextView in your code, you can easily have Android Studio add the needed import command for it.
With Emacs/JDE, I point my jde-global-classpath to the Android jar, then when I need to add an import line I highlight the class and do a Control-C, Control-V, Control-Z. It is slightly more convoluted than Studio but works well enough, I could probably automate and simplify it more if I needed to. This was the main shortcut I missed when moving from Eclipse/ADT to Android, but doing this got it back for me.
As a Nexus 4 user, I'm not holding my breath (and my N4 isn't holding its charge).
There was a story posted a few weeks back about how a certain (Samsung or LG?) phone had added new members to the middle of a kernel struct, for the benefit of their camera driver. It hamstrung a lot of the community reverse engineering work to port a new kernel to the device.
I think the comparison between operating systems and browsers is apples (no pun) and oranges. Browsers generally don't implement any specific UI design language, whereas operating systems do.
Android is a system where Google controls most of the baseline UI and does implement much of the Material design language in the SDK- but at least on the launch of 5.0 several components were missing. As you rightly say the community came to the rescue and there are several versions of each component now on github.
Was just wondering if that was on purpose, and the strategy is only to provide base components in the SDK, and only visual designs of a more comprehensive set of UI components - and then let the community implement the missing components outlined in the design guidelines? Not saying that's a bad thing, just curious if it's done on purpose.
On the other hand, it's not clear to me that the user opts into the indexing, so Google might suddenly silently be getting access to a huge number of user's deep within-app data without them realising it. But that is old news, app indexing has been around for a while.
App indexing makes sense when you have more stable content inside of an app like a traditional public website. Think Yelp and their 'screen' per place inside of the app. It doesn't make sense to publish the contents of a chat conversation to Google's app index -- that would be a huge privacy leak! It would be the equivalent of GoogleBot indexing my Gmail inbox.
You might want to make you have parallel builds and the gradle daemon on for the gradle CLI. Android Studio seems to turn these on for you but if you build from the terminal I think they need to be specified in a gradle.properties file in the project root. You can also increase the amount of memory gradle is allowed to use.
As far as I know Kotlin does almost all of its magic at compile time so I am sure it will slow down builds slightly versus plain Java. From what I have seen so far I am more than willing to pay this price.
Here is a good overview with benchmarks from Square
https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhC...
There are a lot of 8GB devices that could be upgraded to iOS8 but are unable to because of lack of disk space.
http://store.apple.com/us/buy-iphone/iphone5c/iphone-5c-8gb-...
And by disk space I mean after the user has installed the typical number of apps, photos, music etc. My partner is an example of this. She has to choose between deleting apps and doing OS updates.
Based on the Android 5.1 source, there are a lot of permissions in the "normal" group, which will apparently now be accepted automatically at install time:
$ curl -sL http://git.io/vklnX | grep -B2 'protectionLevel="normal"' | grep name | cut -d'"' -f2 | sort
android.permission.ACCESS_LOCATION_EXTRA_COMMANDS
android.permission.ACCESS_NETWORK_STATE
android.permission.ACCESS_WIFI_STATE
android.permission.ACCESS_WIMAX_STATE
android.permission.BROADCAST_STICKY
android.permission.CHANGE_NETWORK_STATE
android.permission.EXPAND_STATUS_BAR
android.permission.FLASHLIGHT
android.permission.GET_ACCOUNTS
android.permission.GET_PACKAGE_SIZE
android.permission.GET_TASKS
android.permission.KILL_BACKGROUND_PROCESSES
android.permission.MODIFY_AUDIO_SETTINGS
android.permission.PERSISTENT_ACTIVITY
android.permission.READ_SYNC_SETTINGS
android.permission.READ_SYNC_STATS
android.permission.RECEIVE_BOOT_COMPLETED
android.permission.REORDER_TASKS
android.permission.RESTART_PACKAGES
android.permission.SET_TIME_ZONE
android.permission.SET_WALLPAPER
android.permission.SET_WALLPAPER_HINTS
android.permission.TRANSMIT_IR
android.permission.VIBRATE
android.permission.WAKE_LOCK
android.permission.WRITE_SETTINGS
android.permission.WRITE_SYNC_SETTINGS
android.permission.WRITE_USER_DICTIONARY
Application YourTypicalMobileApplication is asking for access to the Internet
to display advertisements powered by Google AdMob.
[ D̶E̶N̶Y̶ ] [ ALLOW ]
(Do you think we would give you the option to easily cut our income?)How can the OS tell if an HTTP request is for the Internet or for Ads? It can't.
Though Google could special-case AdMob effectively owning the ad scenario for apps which don't use the internet for anything else.
But I have to use Android, because it's the most open established mobile ecosystem. Only system that supports the mobile web browser I find tolerable to use for instance (hint - it's not the default browser or Chrome). Only system that allows developers to map executable pages. Only system that allows me to customize user experience as I see fit, and not offer one size fits all. And so on.
As for Internet, they leave that out of their "improved" Play store permissions as well (and the M groupings seems like a carbon copy).
Why would they do that? On it's own "Internet" may not seem to be an important category, but I am willing to give apps many more permissions if I know that they can't phone home. For tools, the Internet permission is often the deciding factor for me.
I'm not sure if Google would go for it, but I suppose it would encourage devs to use Play services for ads and analytics, since it wouldn't need any extra internet permissions, while using an external service for either would.
Sadly it's more likely I'll just get some stupid pony instead.
Sure, it can be a spy app, designed to listen and record! But then the OS can expose a per-app maximum wake setting. Yes, it'd look like a spreadsheet instead of a happy user UI, but that'd be a solution, instead of this "oh we can't do anything" excuse.
Because the OS shouldn't be making assumptions about applications' interaction models. People tend to write apps that OS creators never dreamed about. There are legitimate reasons for resource usage (camera) to continue without user interaction.From the top of my head, I can imagine writing a baby-monitor app that uses camera to stream video to my phone in the other room using wifi.
The resource-limiting heuristics have to be impossibly good, otherwise it gets in the way of useful apps.
Face unlock, dash cams, baby monitors, live-wallpapers-that-make-your-phone-look-transparent, security apps that snap a picture when someone fails to enter the correct unlock code and emails it to you, etc...
But replace camera with GPS and it's the same thing. Or audio. Or motion detectors. Or just really frequent alarms to poll a server (see IRC apps for an example)
With that, you can either let the old version die slowly as users upgrade devices. I haven't attempted it, but I assume you can still somehow push bugfixes for the older version without newer devices also getting it.
Just something you might want to investigate. You may not have as many actively using 2.3 as you might think. Creating a new branch for active build really isn't that much complexity and then a branch for legacy when the legacy is just maintenance mode only.
Damn it, Android without Google is already big in China. And lets not forget that Amazon is maintaining what amounts to a fork for their device range.
Google can't really play hardball unless they want to go full Apple.
In essence Android has gotten where it is by being more accommodating to OEMs etc than the competition. Something akin to what MS was doing until they went retard with Windows Mobile 7.
People have invested money in apps and content which locks them into that platform.
Tizen is a non-starter (nobody is building apps for it). And Microsoft is still struggling for traction.
Which seeing as they used it for a 400x248 image in the blogpost is pretty much exactly on point.
The U.S. system where operators are such gatekeepers for mobile devices is an anomaly. It doesn't need to be so, and it is not so elsewhere.
I don't understand the overall picture of the U.S. telecom industry in the first place. Slow speeds, data caps, bad coverage, high prices and control freak carriers.
They load it with a default that you can change. That doesn't inhibit my choice in the slightest.
But a large number of people don't care to change their OS from the default, so the ecosystem gets loaded with a large number of those phones.
I just don't understand why the telecoms wouldn't use the newest OS as the default.
Why would they allow you to upgrade the OS when they can sell you a new phone and a new multi year contract. It's a pretty basic strategy.
Also, the phone companies themselves need to put out the updates, which isn't happening a lot of the time (or with 6 month+ delays).
[1] http://arstechnica.com/information-technology/2015/03/a-revi...
M ready app, you get no permissions display up front but asked to approve on API use.
Older app, you get a permissions display up front and can disable API access in Android settings.
On older devices both M ready apps and older apps would behave like today, giving you a list of permissions up front and no way to control them (unless you are running a custom Android or the OEM added the possibility).
This would work nicely for GPS etc - sure, I want to be able to have My Tracks keep GPS on for 3 hours, but I don't need Uber to be able to do that - and their app has a nasty habit of forgetting to turn the GPS off if you leave it at the wrong time.
Also, I think analytics should be something fundamentaly optionnal, at least from a privacy POV.
There is, but there are multiple crash reporting services that provide more features than Google (and just having some competition in that area is pretty great).
In my company, we use Crashlytics on Android & iOS and Bugsense on wp.
Telstra didn't update because of a battery issue. Which was true... the battery died quickly if you left the GPS on. I didn't use the GPS much so I left it off. (This issue has since been resolved, then telstra enabled the update)
Considering I didn't even have Telstra as a carrier. it was because JB-HIFI is a Telstra reseller that this happened.
It's because the Manufacturer agreed to only update when Telstra updated. It's all through the Sony update software.