Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
idea: more fine-grained permissions, improved app-ops style #795
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Oct 29, 2017
Contributor
No, exposing this wouldn't accomplish anything. Apps can register persistent jobs, etc.
There are already strict background execution restrictions for apps targeting API 26+ and it can be individually toggled on for apps targeting lower API levels.
|
No, exposing this wouldn't accomplish anything. Apps can register persistent jobs, etc. There are already strict background execution restrictions for apps targeting API 26+ and it can be individually toggled on for apps targeting lower API levels. |
thestinger
closed this
Oct 29, 2017
thestinger
added
Status: wontimplement
Type: enhancement
labels
Oct 29, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
xbtc-im
Oct 29, 2017
I mean persistent jobs too. I know about strict background execution restrictions, what i am suggesting is that an application never runs until the user opens it, and when the user closes that app, it should just terminate
xbtc-im
commented
Oct 29, 2017
|
I mean persistent jobs too. I know about strict background execution restrictions, what i am suggesting is that an application never runs until the user opens it, and when the user closes that app, it should just terminate |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Oct 29, 2017
Contributor
That isn't what you said in the issue you filed.
If you want that feature implemented, you could start by making a proof of concept to demonstrate how it would work.
|
That isn't what you said in the issue you filed. If you want that feature implemented, you could start by making a proof of concept to demonstrate how it would work. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
xbtc-im
Oct 29, 2017
Nobody can "want" or "demand" a feature on an open source / almost free project. What i am suggesting is a more fine grained user control, especially on "All permissions" . Some apps have a laundry list of permissions, that most of the time simply do not need to run as intended. The "run at startup" is just one of them.
corrected the title
xbtc-im
commented
Oct 29, 2017
•
edited
Edited 2 times
-
xbtc-im
edited Oct 29, 2017
-
xbtc-im
edited
Oct 29, 2017
edited
-
Oct 29, 2017 -
Oct 29, 2017
|
Nobody can "want" or "demand" a feature on an open source / almost free project. What i am suggesting is a more fine grained user control, especially on "All permissions" . Some apps have a laundry list of permissions, that most of the time simply do not need to run as intended. The "run at startup" is just one of them. |
xbtc-im
changed the title from
idea: run at startup permission
to
idea: more fine-grained permissions, improved app-ops style
Oct 29, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Oct 29, 2017
Contributor
There are already permission toggles and they use appops for apps targeting an API level before 23. You need to be specific about what you want. We aren't interested in working on exposing a bunch of toggles simply to have more stuff. There has to be a reason to do it.
|
There are already permission toggles and they use appops for apps targeting an API level before 23. You need to be specific about what you want. We aren't interested in working on exposing a bunch of toggles simply to have more stuff. There has to be a reason to do it. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
xbtc-im
Oct 29, 2017
actual requested permissions:
aapt dump badging ivms.apk | grep permission
uses-permission: name='android.permission.FLASHLIGHT'
uses-permission: name='android.permission.HARDWARE_TEST'
uses-permission: name='android.permission.DISABLE_KEYGUARD'
uses-permission: name='android.permission.KILL_BACKGROUND_PROCESSES'
uses-permission: name='android.permission.WRITE_EXTERNAL_STORAGE'
uses-permission: name='android.permission.MOUNT_UNMOUNT_FILESYSTEMS'
uses-permission: name='android.permission.READ_EXTERNAL_STORAGE'
uses-permission: name='android.permission.VIBRATE'
uses-permission: name='android.permission.INTERNET'
uses-permission: name='android.permission.ACCESS_NETWORK_STATE'
uses-permission: name='android.permission.ACCESS_WIFI_STATE'
uses-permission: name='android.permission.WAKE_LOCK'
uses-permission: name='android.permission.GET_TASKS'
uses-permission: name='android.permission.RECORD_AUDIO'
uses-permission: name='com.google.android.providers.gsf.permission.READ_GSERVICES'
uses-permission: name='android.permission.READ_PHONE_STATE'
uses-permission: name='android.permission.CAMERA'
uses-permission: name='android.permission.CHANGE_WIFI_STATE'
uses-permission: name='android.permission.GET_ACCOUNTS'
uses-permission: name='com.mcu.iVMSHD.permission.C2D_MESSAGE'
uses-permission: name='com.google.android.c2dm.permission.RECEIVE'
uses-permission: name='com.mcu.iVMSHD.push.sdk.permission.EZVIZ_MESSAGE'
uses-permission: name='android.permission.CHANGE_NETWORK_STATE'
uses-permission: name='android.permission.RECEIVE_BOOT_COMPLETED'
uses-implied-feature: name='android.hardware.camera' reason='requested android.permission.CAMERA permission'
uses-implied-feature: name='android.hardware.microphone' reason='requested android.permission.RECORD_AUDIO permission'
uses-implied-feature: name='android.hardware.wifi' reason='requested android.permission.ACCESS_WIFI_STATE permission, and requested android.permission.CHANGE_WIFI_STATE permission'
visible permissions:
Camera Contacts Microphone Network (on Copperhead) Phone Sensors Storage.
Most users maybe have no idea on those permissions, however, on an OS centered on security/privacy, my opinion is that all permissions should be user selectable. Does this count as a reason ?
xbtc-im
commented
Oct 29, 2017
•
edited
Edited 1 time
-
xbtc-im
edited
Oct 29, 2017
edited
-
Oct 29, 2017
|
actual requested permissions: aapt dump badging ivms.apk | grep permission visible permissions: Most users maybe have no idea on those permissions, however, on an OS centered on security/privacy, my opinion is that all permissions should be user selectable. Does this count as a reason ? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Oct 29, 2017
Contributor
You're comparing raw low-level install permissions used by developers to toggles for permission groups aimed at users. That's not something directly comparable.
Camera Contacts Microphone Network (on Copperhead) Phone Sensors Storage.
The Network and Sensors toggles are both specific to CopperheadOS.
|
You're comparing raw low-level install permissions used by developers to toggles for permission groups aimed at users. That's not something directly comparable.
The Network and Sensors toggles are both specific to CopperheadOS. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
xbtc-im
commented
Oct 29, 2017
|
Couldn't those raw level permissions be user selectable ? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment|
No, that's not how the permission group toggles work. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
xbtc-im
Oct 29, 2017
the app i talked about before, is a security cam viewer app, at every startup and when the screen is on, it tries to connect to an outside server. the vpn blocks it, but however it should only run when i want to see my cameras. it shouldn't even run if i don't need it. or google doesn't allow permissions to be so selectable ?
xbtc-im
commented
Oct 29, 2017
|
the app i talked about before, is a security cam viewer app, at every startup and when the screen is on, it tries to connect to an outside server. the vpn blocks it, but however it should only run when i want to see my cameras. it shouldn't even run if i don't need it. or google doesn't allow permissions to be so selectable ? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Oct 29, 2017
Contributor
or google doesn't allow permissions to be so selectable ?
It's not about what Google does or doesn't allow. Permissions don't work the way you think. You're getting bogged down in assumptions about implementation details.
It's not about what Google does or doesn't allow. Permissions don't work the way you think. You're getting bogged down in assumptions about implementation details. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
xbtc-im
Oct 29, 2017
Maybe i am, i'm not a developer. But some permissions should be more user-configurable.
xbtc-im
commented
Oct 29, 2017
|
Maybe i am, i'm not a developer. But some permissions should be more user-configurable. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Oct 29, 2017
Contributor
the app i talked about before, is a security cam viewer app, at every startup and when the screen is on, it tries to connect to an outside server. the vpn blocks it, but however it should only run when i want to see my cameras. it shouldn't even run if i don't need it.
Apps don't need any permissions to run in the background. The app being treated as not having RECEIVE_BOOT_COMPLETED wouldn't accomplish what you want.
Apps don't need any permissions to run in the background. The app being treated as not having |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Oct 29, 2017
Contributor
Maybe i am, i'm not a developer. But some permissions should be more user-configurable.
It certainly doesn't make sense to simply expose the remaining permissions as toggles. That's not how designing features and user interfaces works, and we're also not going to do a bunch of pointless work on useless toggles.
It certainly doesn't make sense to simply expose the remaining permissions as toggles. That's not how designing features and user interfaces works, and we're also not going to do a bunch of pointless work on useless toggles. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
xbtc-im
Oct 29, 2017
:) my point exactly. they should be allowed to run in background
or disallowed for that matter
xbtc-im
commented
Oct 29, 2017
•
edited
Edited 1 time
-
xbtc-im
edited
Oct 29, 2017
edited
-
Oct 29, 2017
|
:) my point exactly. they should be allowed to run in background |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Oct 29, 2017
Contributor
The appops RUN_IN_BACKGROUND doesn't actually do that, which is exactly why it makes no sense to directly expose low-level implementation details to users. It would just confuse and mislead people along with being a complex maintenance burden.
thestinger
commented
Oct 29, 2017
•
edited
Edited 2 times
-
thestinger
edited Oct 29, 2017
-
thestinger
edited
Oct 29, 2017
edited
-
Oct 29, 2017 -
Oct 29, 2017
|
The appops |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
xbtc-im
commented
Oct 29, 2017
|
Understwood |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Oct 29, 2017
Contributor
I don't think we need more open issues about permissions in the background or the ability to run in the background until the existing tasks are finished. It's something we're conscious of as you can see from the background clipboard access toggle and those issues. Ideas are worthless without putting in the work though, and we don't have the resources to get everything on the tracker implemented.
|
I don't think we need more open issues about permissions in the background or the ability to run in the background until the existing tasks are finished. It's something we're conscious of as you can see from the background clipboard access toggle and those issues. Ideas are worthless without putting in the work though, and we don't have the resources to get everything on the tracker implemented. |
xbtc-im commentedOct 29, 2017
could a "runt at startup" permission be added, app-ops style ? it could be useful, resource and bandwidth wise, for some ...