Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android M Developer Preview and Tools

android-developers.blogspot.com

Post reply on HN
Print view View original

141–150 of 153 posts

Re: Android M Developer Preview and Tools

#141

Post by 27182818284 »

krschultz wrote: post #87
27182818284 wrote: post #28

Google is showing off Android M dev previews while devices sold new last fall in major US retailers are still running KitKat with no updates from Google or their providers. They continue to actively create the "fractured" world of Android. 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 negot…

Damn lies and statistics. The Android dashboard numbers are always super pessimistic on upgrade rate. 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 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 poin…

I would imagine much more people have the Play Store installed than the 250,000 installs of your application. It seems reasonable then to point to Google's own page for the better count.

https://developer.android.com/about/dashboards/index.html?ut...

Re: Android M Developer Preview and Tools

#142

Post by dharma1 »

izacus wrote: post #131
dharma1 wrote: post #97

Earlier quoted context omitted.

Is that a deliberate strategy or a lack of communication between teams at Google to create the SDK level support for components their design team designs?

I don't understand this sentiment, why do you need those components? There's bunch of 3rd party libraries to implement the UI patterns. Do you go annoy Safari/Chrome/Firefox developers that they don't provide you with components for carousels in browsers as well?

Annoy? I'm not sure I understand that sentiment.

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.

Re: Android M Developer Preview and Tools

#143

Post by kllrnohj »

pas wrote: post #76
kllrnohj wrote: post #70

Earlier quoted context omitted.

I, too, would love to live in a world where it's impossible to write bugs. Things would be so much nicer if Google could just solve the halting problem already. Sadly it's more likely I'll just get some stupid pony instead.

The OS manages resources. It can temporarily grant (exclusive) control of a resource to an application. It can measure your other resource activity (touchscreen). If not touch screen activity for a long time, or when simply the screen is locked, then why is the camera on? 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 spreadsh…

> If not touch screen activity for a long time, or when simply the screen is locked, then why is the camera on?

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)

Re: Android M Developer Preview and Tools

#144

Post by kllrnohj »

biafra wrote: post #108
magicalist wrote: post #101

Earlier quoted context omitted.

According to the session after the keynote, you'll still be able to at least go back and revoke permissions individually for apps targeting older API levels.

And they will most likely crash if you do, because they are not expecting a SecurityException. I prefer the CyanogenMod way to just give out empty data, if a permission is not given by the user.

What you're calling the "CyanogenMod" way is actually what Google built, it's called AppOps. All CM did was expose it. The actual capability of permission revoking and handing out dummy data instead was all done by Google as part of AppOps and I assume that M is using that same system because it'd be silly not to.

Re: Android M Developer Preview and Tools

#145

Post by kuschku »

yareally wrote: post #106
kuschku wrote: post #93

Earlier quoted context omitted.

As someone developing another Android app, a FOSS app for an IRC bouncer: 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.

The Android Market lets you depreciate old versions of Android now for your apps by leaving up the last compatible apk for them while newer devices get the latest version of your app. 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.

But then those people wouldn’t get the normal upstream releases anymore, and we’d have to setup a branch for backports – not really great.

Re: Android M Developer Preview and Tools

#146

Post by yareally »

kuschku wrote: post #145
yareally wrote: post #106

Earlier quoted context omitted.

The Android Market lets you depreciate old versions of Android now for your apps by leaving up the last compatible apk for them while newer devices get the latest version of your app. 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.

But then those people wouldn’t get the normal upstream releases anymore, and we’d have to setup a branch for backports – not really great.

Backporting bug fixes or new features? I wouldn't be going out of my way to try adding new features to 5 year old versions of Android. If a user reports a crash for 2.3, sure, I will fix it. I know I have a fair amount of devices showing as Android 2.3 for one of my apps, but I've noticed most of them seem to be inactive. The app in question is a tool for testers and power users, so I would expect many of them to keep old devices around for fun/hobby, but not really using them actively.

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.

Re: Android M Developer Preview and Tools

#147

Post by on_and_off »

magicalist wrote: post #101
on_and_off wrote: post #83

Earlier quoted context omitted.

The app needs to target M in order to access to these granular permission. An app targeting a lower API level will work in legacy mode where it gets its permissions at install time, like before. I guess it makes sense in order to give enough time to the devs to update their apps to this new system. As long as the checking/warning becomes more aggressive in N, I am fine with that choice.

According to the session after the keynote, you'll still be able to at least go back and revoke permissions individually for apps targeting older API levels.

yeah, but that way you can only remove the permission after the installation.

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.

Re: Android M Developer Preview and Tools

#148

Post by on_and_off »

hrktb wrote: post #95
on_and_off wrote: post #80

Earlier quoted context omitted.

Crash reporting and analytics come to mind as reasonable applications of the default internet permission.

Isn't there an entry point on the OS/Google Play side that allows the dev to get crash reports? Also, I think analytics should be something fundamentaly optionnal, at least from a privacy POV.

>Isn't there an entry point on the OS/Google Play side that allows the dev to get crash reports?

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.

Re: Android M Developer Preview and Tools

#149

Post by kuschku »

yareally wrote: post #146
kuschku wrote: post #145

Earlier quoted context omitted.

But then those people wouldn’t get the normal upstream releases anymore, and we’d have to setup a branch for backports – not really great.

Backporting bug fixes or new features? I wouldn't be going out of my way to try adding new features to 5 year old versions of Android. If a user reports a crash for 2.3, sure, I will fix it. I know I have a fair amount of devices showing as Android 2.3 for one of my apps, but I've noticed most of them seem to be inactive. The app in question is a tool for testers and power users, so I would expect many of them to kee…

We are talking only about people who installed the latest version of the app – so they had to be online, and had updates activated, within of the past few weeks.

Re: Android M Developer Preview and Tools

#150

Post by ufmace »

wongarsu wrote: post #65
digi_owl wrote: post #61

Earlier quoted context omitted.

I guess they consider external storage to be already handled by the Storage Access Framework. As for Internet, they leave that out of their "improved" Play store permissions as well (and the M groupings seems like a carbon copy).

>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'd like to see a modified internet permission that permitted access to only a specific domain. Maybe along with a policy prohibiting or discouraging using the all-internet permission for anything that didn't clearly need it, like say a web browser. Say the Twitter app only has permission to access URLs under twitter.com, and accessing any other URL domain is a separate permission.

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.

Post reply on HN