Skip to content
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

A better way to accommodate custom adb calls #446

Open
xpconanfan opened this issue May 11, 2018 · 6 comments
Open

A better way to accommodate custom adb calls #446

xpconanfan opened this issue May 11, 2018 · 6 comments
Assignees

Comments

@xpconanfan
Copy link
Collaborator

This came up in a discussion with @winterfroststrom

The AdbProxy was designed for the most straightforward use cases, like adb.shell('getprop') - simple call and return.

This does not work well if users want to have more control of the call.
E.g. process the live streaming of the stdout of the call subprocess.

We might want to consider providing a new adb interface for users who want to make long-running calls and have more control of the subprocess.

@xpconanfan xpconanfan self-assigned this May 11, 2018
@johnklee
Copy link
Contributor

This issue looks interesting to me. I can work on this issue if granted and this is still a valid issue. Thanks!

@xpconanfan
Copy link
Collaborator Author

This has not come up a lot recently, so it has not been a priority.
I'm thinking maybe a logcat service pub-sub mechanism is probably good enough for most users.

What idea do you have in mind for the adb level API?
Can you share some high level examples? :)

@johnklee
Copy link
Contributor

johnklee commented May 15, 2021

Thanks for your attention! It all depends on the requirements we have. e.g.:

This does not work well if users want to have more control of the call.
E.g. process the live streaming of the stdout of the call subprocess.

We might want to consider providing a new adb interface for users who want to make long-running calls and have more control of the subprocess.

If I can have more information about the discussion you had with @winterfroststrom so to learn more about details about requirements and your expectation on the result of this issue, then I can come up with a high-level proposal on API design for your review. Again, thanks for your asking and look forward to making a contribution to this repo.

@xpconanfan
Copy link
Collaborator Author

I see.

So basically, there is no good support for non-blocking long running adb commands today.
E.g. the adb logcat service has to use a raw start_standing_process call, and manage the process directly, in addition to handling the stdout and stderr.

So the idea for this request is to create a mid-layer between raw process management and AndroidDevice services for adb commands.

@johnklee
Copy link
Contributor

johnklee commented May 18, 2021

Understood!

Let me study some existing packages such as invoke, python-shell, pexpect and python-rrmngmnt to see if there is anything we can learn from them and then will propose a design document (module with API usage) for your review. Thanks!

@johnklee
Copy link
Contributor

Hi,

I made up slides as the proposal for this issue. Please check this link:

  • P2: Description of this issue
  • P3-6: The study of the original implementation
  • P7-8: The proposal for this issue.

Any advice and feedback are appreciated. Sorry for the late response and look forward to your lesson.
Many thanks!

johnklee added a commit to johnklee/mobly that referenced this issue May 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants