Assigned
Status Update
No update yet.
Comments
gh...@google.com
gh...@google.com
Looks like the feature can be introduced by a community app on Google Play, but it requires the phone to be rooted which I would not have to in the first place if its an inbuilt feature.
https://play.google.com/store/apps/details?id=sk.blade.globalvibratetoggle
da...@gmail.com
Fuck y'all pussy ass mfs
dw...@gmail.com
Please provide following information which will help us to investigate this further,
* What is the desired behavior of the feature? (Be specific!)
* If relevant, why are current approaches or workarounds insufficient?
* If relevant, what new use cases will this feature will enable?
* What is the desired behavior of the feature? (Be specific!)
* If relevant, why are current approaches or workarounds insufficient?
* If relevant, what new use cases will this feature will enable?
ol...@wonderpush.com
* What is the desired behavior of the feature? (Be specific!)
The desired behavior of this feature would be to stop the vibrations system wide irrespective of what the individual apps has to say about it. This vibrations feature would be independent of my sound being turned on or if I have a silent profile setup. If the sound is turned on it will just play the sound (no vibrations) and if the Silent profile is turned on then it effectively would just light up the screen ( as no sound and/or vibrations would be played).
An alternative would be to introduce a separate permission for allowing apps to use the vibration motors on the phone (which I should be able to deny to when installing the app and still be able to use the app unless the app is solely based on use case of controlling the vibrations)
* If relevant, why are current approaches or workarounds insufficient?
There is no current approach to solve this problem unless you root the phone. The only other alternative is to request each individual app maker to provide a setting to disable vibrations for notifications generated from their apps which is never heard to since the apps are mostly free and without any sort of support.
* If relevant, what new use cases will this feature will enable?
This will allow users to control vibrations just like users can currently control the sound level and notification sound in general. It will also benefit the users with giving back some battery life (and charge) when the vibration motors are not used. User, unlike present scenario, would not have to root their phones to get this feature, which can come with problems of warranty of their own.
Hope this helps, and am happy to provide any other details to get this feature to life.
Thanks!
The desired behavior of this feature would be to stop the vibrations system wide irrespective of what the individual apps has to say about it. This vibrations feature would be independent of my sound being turned on or if I have a silent profile setup. If the sound is turned on it will just play the sound (no vibrations) and if the Silent profile is turned on then it effectively would just light up the screen ( as no sound and/or vibrations would be played).
An alternative would be to introduce a separate permission for allowing apps to use the vibration motors on the phone (which I should be able to deny to when installing the app and still be able to use the app unless the app is solely based on use case of controlling the vibrations)
* If relevant, why are current approaches or workarounds insufficient?
There is no current approach to solve this problem unless you root the phone. The only other alternative is to request each individual app maker to provide a setting to disable vibrations for notifications generated from their apps which is never heard to since the apps are mostly free and without any sort of support.
* If relevant, what new use cases will this feature will enable?
This will allow users to control vibrations just like users can currently control the sound level and notification sound in general. It will also benefit the users with giving back some battery life (and charge) when the vibration motors are not used. User, unlike present scenario, would not have to root their phones to get this feature, which can come with problems of warranty of their own.
Hope this helps, and am happy to provide any other details to get this feature to life.
Thanks!
ta...@gmail.com
We have passed this to the development team and will update this issue with more information as it becomes available.
vi...@gmail.com
Fixed
ja...@gmail.com
I would LOVE this to be fixed!!! What a pain in the arse
Description
This will create a public issue which anybody can view and comment on.
Please provide as much information as possible. At least, this should include a description of your issue and steps to reproduce the problem. If possible please provide a summary of what steps or workarounds you have already tried, and any docs or articles you found (un)helpful.
Problem you have encountered:
The debian package
google-cloud-cli-app-engine-pythonfrom thecloud.google.comapt repository depends on the packagepython2.7which as of the date of this report has been deprecated from Debian unstable (and therefore in Debian 12, estimated to be released in May 2023).What you expected to happen:
google-cloud-cli-app-engine-pythoninstalls without issue without depending on Python 2.7 (which has been deprecated for over 3 years at this point)Steps to reproduce:
sudo apt install google-cloud-cli google-cloud-cli-app-engine-pythonOther information (workarounds you have tried, documentation consulted, etc):