Skip to content

fix(helper): recognise the accessibility service by component, not string - #169

Open
zhangifonly wants to merge 1 commit into
google:mainfrom
zhangifonly:fix/a11y-service-qualified-name
Open

zhangifonly wants to merge 1 commit into
google:mainfrom
zhangifonly:fix/a11y-service-qualified-name

Conversation

@zhangifonly

Copy link
Copy Markdown

Problem

enabled_accessibility_services can hold the same component in two spellings:

  • adb (what _enable_service() writes): com.artemis.helper/.ArtemisAccessibilityService
  • Settings UI (what Android writes when a user toggles it): com.artemis.helper/com.artemis.helper.ArtemisAccessibilityService

Some ROMs reject the adb secure-settings write. On a realme RMX2202 (ColorOS / realme UI, Android 14) artemis helper install reports "This device rejected enabling the accessibility service from adb" and opens the Accessibility screen, as designed. After the user enables the service by hand, only the fully-qualified spelling is present, and:

  • is_service_enabled() stays False, so artemis helper status keeps showing Service enabled: no and provision() keeps trying (and failing) to enable it;
  • _revive_service() keeps the qualified entry and appends the short one (duplicate);
  • uninstall() leaves the qualified entry behind.

Fix

Add _is_helper_service(), which expands a leading-dot class name and compares the normalized component, and use it at all four call sites. Writes still use SERVICE_NAME unchanged.

Tests

  • Two new unit tests in tests/unit/runtime/test_helper_manager.py (settings-UI spelling is recognised by provision() without rewriting the setting; uninstall() removes it). Both fail without the fix and pass with it.
  • tests/unit/runtime/: 141 passed; ruff check / ruff format --check clean; pyright --project pyright-core.json: 0 errors.
  • Verified on the realme device: after enabling the service by hand, artemis helper status now reports Service enabled: yes / Service answering: yes, and a Flash task completes using the helper.

…ring

The Settings UI stores the fully-qualified component
(com.artemis.helper/com.artemis.helper.ArtemisAccessibilityService) while adb
stores the short form (com.artemis.helper/.ArtemisAccessibilityService).
ROMs that reject the adb secure-settings write (seen on ColorOS / realme,
Android 14) can only be enabled by hand, so is_service_enabled() stayed False
forever, provision() kept reporting the service as disabled, and
_revive_service()/uninstall() missed the entry.

Compare the normalized component in all four places instead.
@google-cla

google-cla Bot commented Oct 6, 2026

Copy link
Copy Markdown

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant