Options for dealing with Android 6.0's new permissions requirements from a service or model component? -

i'm looking porting existing code take android m's new way of dealing permissions consideration. permission api needs have activity associated (for example requestpermissions() method's first parameter activity).

so how should service needs check if permissions has been granted , request permissions use new api if service doesn't have activity?

is possible service create dummy invisible activity use permissions api? (if possible don't thought of doing anyway though).

or suppose not service model class needs perform permissions check, in mvc model shouldn't have knowledge of vs , cs , yet either has in order know activity use permission api. or potentially lots of code might have migrate model code activity code.

any thoughts on how migrate non activity based code needs check/prompt permissions on android 6.0?

update: left out important piece of information - code pre-installed (our company provides code device manufacture's place in rom) , may run @ device boot time , run in background. therefore usual situation of user being prompted permission when launch app or later (and there therefore being activity @ point) not apply.

so how should service needs check if permissions has been granted , request permissions use new api if service doesn't have activity?

there activity, except pre-installed apps , plugins other apps. otherwise, service unlikely ever run, nothing have used explicit intent start 1 of app's components, remain in stopped state.

for ~99.9% of android apps have activity already, if permissions needed whole operation of app, request them on first run. snild dolkow notes, if user later revokes permission through settings, can detect without activity, use other ui options (e.g., notification, app widget) let user know operation suspended until grant permissions again, through activity.

is possible service create dummy invisible activity use permissions api?

presumably can have theme.nodisplay activity use requestpermissions(). however, user's standpoint, not make sense, unless there's alternative ui (app widget?) interacting with. popping permission dialog out of unlikely make popular.

in mvc model shouldn't have knowledge of vs , cs , yet either has in order know activity use permission api

do not touch models until have requested permission, , gracefully fail if permission revoked. have gracefully fail in other circumstances (out of disk space, no internet connection, etc.), revoked permission should handled in same way.

using new 6.0 api seems recipe bad design , tight coupling

you welcome opinion. based on have read, android engineers believe asking user permissions part of user experience , best handled @ ui layer result.

again: vast majority of android apps not have problem this, have user interface. apps not have user interface and need dangerous permissions in amount of rework.

this code pre-installed (our company provides code device manufacture's place in rom) , may run @ device boot time

first, please understand far normal can't see normal due curvature of earth. :-) can't complain google did not optimize particular scenario.

as understand it, system apps should asking runtime permissions. camera app did, example, on 6.0 preview. being said, there's gotta database on device somewhere tracking has been granted, , presumably there way pre-populate it. however, user still revoke settings, presumably. but, manufacturer pull stunts (e.g., messing settings app) possibly preclude scenario. i'd looking in same area "how app cannot force-stopped?" device manufacturers can do.

your alternatives rid of dangerous permissions or migrate app off sdk , standard linux binary run part of boot process , put linux user group has access stuff need.