Fixed
Status Update
Comments
vi...@google.com <vi...@google.com> #2
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
bo...@gmail.com <bo...@gmail.com> #3
Fuck y'all pussy ass mfs
iv...@mixhalo.com <iv...@mixhalo.com> #4
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?
vi...@google.com <vi...@google.com> #5
* 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!
an...@arctouch.com <an...@arctouch.com> #6
We have passed this to the development team and will update this issue with more information as it becomes available.
[Deleted User] <[Deleted User]> #7
Fixed
iv...@mixhalo.com <iv...@mixhalo.com> #8
I would LOVE this to be fixed!!! What a pain in the arse
ub...@gmail.com <ub...@gmail.com> #9
Yes, I have vibrate turned off on every app including text and it still vibrates on text. I can't make it stop!
ub...@gmail.com <ub...@gmail.com> #10
i just want all vibrations off. even when they are supposed to be off i still get vibrate alerts.
ub...@gmail.com <ub...@gmail.com> #11
I wonder if this will be fixed, ever? Coming from IOS, I find this super irritating not to be able to turn it off in my current os
Description
Leak Canary detects a memory leak in the implementation of MediaBrowserService within our MusicService just by launching, starting a playback and quitting the app.
When we look at heap dumps, Leak Canary discovers a leak where a MediaBrowserService stays in memory when you open and exit the app. The following is the Leak Canary report:
┬───
│ GC Root: Global variable in native code
│
├─ android.service.media.MediaBrowserService$ServiceBinder instance
│ Leaking: UNKNOWN
│ Retaining 266.7 kB in 824 objects
│ this$0 instance of androidx.media.
│ MediaBrowserServiceCompat$MediaBrowserServiceImplApi26$MediaBrowserServiceA
│ pi26
│ ↓ MediaBrowserService$ServiceBinder.this$0
│ ~~~~~~
├─ androidx.media.
│ MediaBrowserServiceCompat$MediaBrowserServiceImplApi26$MediaBrowserServiceApi
│ 26 instance
│ Leaking: YES (Service not held by ActivityThread)
│ Retaining 266.2 kB in 823 objects
│ mBase instance of com.audiomack.playback.MusicService
│ ↓ ContextWrapper.mBase
╰→ com.audiomack.playback.MusicService instance
Leaking: YES (ObjectWatcher was watching this because com.audiomack.
playback.MusicService received Service#onDestroy() callback and Service
not held by ActivityThread)
Retaining 264.9 kB in 811 objects
key = efafad84-39d3-43fd-b6a8-d2c75c00b36b
watchDurationMillis = 4948
retainedDurationMillis = -84
mApplication instance of com.audiomack.MainApplication
mBase instance of android.app.ContextImpl
METADATA
Build.VERSION.SDK_INT: 30
Build.MANUFACTURER: Google
LeakCanary version: 2.7
App process name: com.audiomack
Count of retained yet cleared: 18 KeyedWeakReference instances
Stats: LruCache[maxSize=3000,hits=11503,misses=247414,hitRate=4%]
RandomAccess[bytes=19500730,reads=247414,travel=236375246960,range=59839840,size
=69944156]
Heap dump reason: 32 retained objects, app is not visible
Analysis duration: 18391 ms