github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-05-20 11:01:36 -05:00
Code Issues 1.5k Packages Projects Releases 125 Wiki Activity

[GH-ISSUE #2631] CPU usage is @ 8% in the background [auto fill] #27575

New Issue
Closed
opened 2026-04-18 11:03:49 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-04-18 11:03:49 -05:00
Owner
Copy Link

Originally created by @xs1vr on GitHub (Jul 19, 2023).
Original GitHub issue: https://github.com/bitwarden/android/issues/2631

Steps To Reproduce

  1. Go to Bitwarden
  2. Enable all of the auto fill options (i didn't test which one specifically causes this 'issue')
  3. Open termux and write (if rooted) su -c top
  4. Move the top table to the right with > arrow, once you're there wait a few seconds for everything to normalize, once it normalizes start 'spamming' the < > arrows so the manifest changes - you'll notice Bitwarden is using 8-9% of the CPU.

Expected Result

Battery is not used as much

Actual Result

The battery usage is the same as if you had running top shell command all the time in the background which is not good.

Screenshots or Videos

No response

Additional Context

No response

Operating System

Android

Operating System Version

13

Device

Poco X3 NFC

Build Version

version 2023.7.0 com.x8bit.bitwarden versionCode 6781 targetSdk 33 minSdk 21 Installed: Jul 19, 2023; 21:08

Beta

  • Using a pre-release version of the application.
Originally created by @xs1vr on GitHub (Jul 19, 2023). Original GitHub issue: https://github.com/bitwarden/android/issues/2631 ### Steps To Reproduce 1. Go to Bitwarden 2. Enable all of the auto fill options (i didn't test which one specifically causes this 'issue') 3. Open termux and write (if rooted) `su -c top` 4. Move the `top` table to the right with > arrow, once you're there wait a few seconds for everything to normalize, once it normalizes start 'spamming' the < > arrows so the manifest changes - you'll notice Bitwarden is using 8-9% of the CPU. ### Expected Result Battery is not used as much ### Actual Result The battery usage is the same as if you had running `top` shell command all the time in the background which is not good. ### Screenshots or Videos _No response_ ### Additional Context _No response_ ### Operating System Android ### Operating System Version 13 ### Device Poco X3 NFC ### Build Version version 2023.7.0 com.x8bit.bitwarden versionCode 6781 targetSdk 33 minSdk 21 Installed: Jul 19, 2023; 21:08 ### Beta - [ ] Using a pre-release version of the application.
GiteaMirror added the bug label 2026-04-18 11:03:49 -05:00
GiteaMirror commented 2026-04-18 11:03:51 -05:00
Author
Owner
Copy Link

@mpbw2 commented on GitHub (Jul 19, 2023):

Hi @xs1vr , in the app's autofill settings can you disable the Use Accessibility option and see if the high CPU usage continues?

<!-- gh-comment-id:1642777745 --> @mpbw2 commented on GitHub (Jul 19, 2023): Hi @xs1vr , in the app's autofill settings can you disable the `Use Accessibility` option and see if the high CPU usage continues?
GiteaMirror commented 2026-04-18 11:03:52 -05:00
Author
Owner
Copy Link

@xs1vr commented on GitHub (Jul 19, 2023):

Hi @xs1vr , in the app's autofill settings can you disable the Use Accessibility option and see if the high CPU usage continues?

Hello @mpbw2,

yes - the issue is no longer persistent when Use accessibility is disabled. sorry for not verifying this earlier by myself.

<!-- gh-comment-id:1642780317 --> @xs1vr commented on GitHub (Jul 19, 2023): > Hi @xs1vr , in the app's autofill settings can you disable the `Use Accessibility` option and see if the high CPU usage continues? Hello @mpbw2, yes - the issue is no longer persistent when `Use accessibility` is disabled. sorry for not verifying this earlier by myself.
GiteaMirror commented 2026-04-18 11:03:53 -05:00
Author
Owner
Copy Link

@mpbw2 commented on GitHub (Jul 19, 2023):

@xs1vr No worries, appreciate the confirmation. This is fairly typical when using Accessibility services as it requires constant polling and parsing of the screen contents. We're routinely making improvements to our standard Autofill implementation in the hopes that one day users won't need to augment it with the use of Accessibility services anymore. Have you tried using recent versions of the app without enabling Use Accessibility?

<!-- gh-comment-id:1642789798 --> @mpbw2 commented on GitHub (Jul 19, 2023): @xs1vr No worries, appreciate the confirmation. This is fairly typical when using Accessibility services as it requires constant polling and parsing of the screen contents. We're routinely making improvements to our standard Autofill implementation in the hopes that one day users won't need to augment it with the use of Accessibility services anymore. Have you tried using recent versions of the app without enabling `Use Accessibility`?
GiteaMirror commented 2026-04-18 11:03:55 -05:00
Author
Owner
Copy Link

@xs1vr commented on GitHub (Jul 19, 2023):

@xs1vr No worries, appreciate the confirmation. This is fairly typical when using Accessibility services as it requires constant polling and parsing of the screen contents. We're routinely making improvements to our standard Autofill implementation in the hopes that one day users won't need to augment it with the use of Accessibility services anymore. Have you tried using recent versions of the app without enabling Use Accessibility?

I've always been using Use Accessibility and I understand why it uses a bit more battery. What have I noticed though is that phones without gms (google services) do much better with just Use draw-over as the option looks a bit better there / more reliable per se?

<!-- gh-comment-id:1642793965 --> @xs1vr commented on GitHub (Jul 19, 2023): > @xs1vr No worries, appreciate the confirmation. This is fairly typical when using Accessibility services as it requires constant polling and parsing of the screen contents. We're routinely making improvements to our standard Autofill implementation in the hopes that one day users won't need to augment it with the use of Accessibility services anymore. Have you tried using recent versions of the app without enabling `Use Accessibility`? I've always been using `Use Accessibility` and I understand why it uses a bit more battery. What have I noticed though is that phones without gms (google services) do much better with just `Use draw-over` as the option looks a bit better there / more reliable per se?
GiteaMirror commented 2026-04-18 11:03:56 -05:00
Author
Owner
Copy Link

@mpbw2 commented on GitHub (Jul 19, 2023):

Use draw-over isn't used when Use Accessibility is disabled. Are you perhaps referring to the Autofill popup when inline autofill is disabled or unavailable? It's visibly similar to the draw-over popup and tracks more reliably as it's part of the standard Autofill. (Hint: If the logo shield in the popup is blue, it's using standard Autofill. If the shield is black and white, it's using the accessibility draw-over)

Edit: meant to say "when Use Accessibility is disabled"

<!-- gh-comment-id:1642815559 --> @mpbw2 commented on GitHub (Jul 19, 2023): `Use draw-over` isn't used when `Use Accessibility` is disabled. Are you perhaps referring to the Autofill popup when inline autofill is disabled or unavailable? It's visibly similar to the draw-over popup and tracks more reliably as it's part of the standard Autofill. (Hint: If the logo shield in the popup is blue, it's using standard Autofill. If the shield is black and white, it's using the accessibility draw-over) Edit: meant to say "when `Use Accessibility` is _disabled_"
GiteaMirror commented 2026-04-18 11:03:56 -05:00
Author
Owner
Copy Link

@xs1vr commented on GitHub (Jul 20, 2023):

Use draw-over isn't used when Use Accessibility is disabled. Are you perhaps referring to the Autofill popup when inline autofill is disabled or unavailable? It's visibly similar to the draw-over popup and tracks more reliably as it's part of the standard Autofill. (Hint: If the logo shield in the popup is blue, it's using standard Autofill. If the shield is black and white, it's using the accessibility draw-over)

Edit: meant to say "when Use Accessibility is disabled"

You're right, it's disabled.
I won't use Use accessibility anymore, I'll stick to the default auto fill that appears in the Gboard, thanks!

<!-- gh-comment-id:1643549027 --> @xs1vr commented on GitHub (Jul 20, 2023): > `Use draw-over` isn't used when `Use Accessibility` is disabled. Are you perhaps referring to the Autofill popup when inline autofill is disabled or unavailable? It's visibly similar to the draw-over popup and tracks more reliably as it's part of the standard Autofill. (Hint: If the logo shield in the popup is blue, it's using standard Autofill. If the shield is black and white, it's using the accessibility draw-over) > > Edit: meant to say "when `Use Accessibility` is _disabled_" You're right, it's disabled. I won't use `Use accessibility` anymore, I'll stick to the default auto fill that appears in the Gboard, thanks!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#27575
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?