-
-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: do not suppress accessibility services #289
Conversation
@KazuCocoa Any idea or plan how to fix the failing checks? (And whether to merge this fix at some point?) |
Do you have time to run this change with the accessibility service enabled app? I haven't tested this case, appium/appium#4910, well since I had no such app. |
We can run the test on Monday, what do we need to do? (We've only ever used appium releases so far...). |
okay, thanks. |
8dd242a
to
1679525
Compare
Then, make sure the above two overwritten apks will be installed on your Appium log. The apks in the apk.zip were generated from this branch by |
We tried to get it to work with these apks, but we haven't managed to do so. What do you need from us? |
The result of whether this UIA2 server apk works with the app under test which uses accessibility service without stopping the accessibility service |
We didn't see a difference in behaviour. |
thanks :) |
// The flag is necessary not to stop running accessibility service | ||
// https://github.com/appium/appium/issues/4910 | ||
// https://developer.android.com/reference/android/app/UiAutomation.html#FLAG_DONT_SUPPRESS_ACCESSIBILITY_SERVICES | ||
Configurator.getInstance().setUiAutomationFlags(UiAutomation.FLAG_DONT_SUPPRESS_ACCESSIBILITY_SERVICES); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we do this each time we get the instrumentation or it would be enough to call the configurator once?
I ensured this logic also works well with
|
Configurator.getInstance().setUiAutomationFlags(0); | ||
} | ||
|
||
private void disableSuppressAccessibilityService() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather rename this method to setAccessibilityServiceState
private ServerInstrumentation(Context context, int serverPort) { | ||
if (!isValidPort(serverPort)) { | ||
throw new UiAutomator2Exception(String.format( | ||
"The port is out of valid range [%s;%s]: %s", MIN_PORT, MAX_PORT, serverPort)); | ||
} | ||
this.serverPort = serverPort; | ||
this.powerManager = (PowerManager) context.getSystemService(Context.POWER_SERVICE); | ||
|
||
setDefaultAutomationFlag(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we always reset these flags or only before we actually change them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point.
I continued to observe the lifecycle of Configurator.getInstance()
after the latest commit.
The value could remain before/after uia2 server lifecycle.
So, changing the state explicitly is better.
Updated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would be nice to document this feature somewhere
Related to appium/appium#4910
Set
UiAutomation.FLAG_DONT_SUPPRESS_ACCESSIBILITY_SERVICES
ifDISABLE_SUPPRESS_ACCESSIBILITY_SERVICES
key and value,true
orfalse
is given as a parameter of instrument.Respect existing setting if no
DISABLE_SUPPRESS_ACCESSIBILITY_SERVICES
key is given