Summary:
Some improvements on the previous diff that were too much for just comments.
- Remove an unnecessary `touch` that I commented on in the previous diff.
- Ensure that the recording button is not set to "recording" if there's an error during the setup.
- More reliable way of checking the file size on the device before pulling.
Still not done: Show the error more prominently in the UI. Out of scope for this but if we could come up with a design for showing this (perhaps in place of the recording button) when something went wrong, that would be more obvious than having the error caret show up at the top of the screen.
Reviewed By: jknoxville
Differential Revision: D19723627
fbshipit-source-id: 20babcc1482e5a9ac829ff6d6ae7a731a3454fa0
Summary:
Original commit changeset: 5caf9df02c95
It backs out the diff as it broke the video recording button in support form.
Bug:
{F227855063}
Reviewed By: passy
Differential Revision: D19742486
fbshipit-source-id: 4a275e6ead919b4f4ed94889545a650c101f89b7
Summary:
Backgrouds
- For screen recording Flipper use 'adb shell scrrenrecord' and 'adb pull'.
- 'screenrecord' make error and doens't works for some android devices and AOS versions.
- For example, "--bugreport" option doesn't work old version of AOS.
- We can not control 'screenrecord' command yet.
- It is better let user know the situation early.
<AS-IS>
When 'screenrecord' emit error:
- Noting happened for users.
- Result of screen record file is just empty. (pull command create the file)
<TO-BE>
When 'screenrecord' emit error:
- Let users know 'screenrecord' is not working properly.
Reviewed By: passy
Differential Revision: D19643060
fbshipit-source-id: 5caf9df02c956283f371c50c1735060be2158fb2
Summary:
There were two issues with the previous approach:
1) We didn't block the shell process, so we would immediately
start pulling the video from the device as soon as we **started**
recording it. This meant, you'd usually get the previous recording
or just an empty file.
2) The stop side doesn't know when it's actually safe to start displaying
the video as pulling takes time. So we need access to the process
promise there.
Reviewed By: jknoxville
Differential Revision: D17687827
fbshipit-source-id: 6ad5da52442f1888dd491b2a4c7f7a6b5a7885dd
Summary: Finally we are able to switch back from our adbkit-fb fork to the original `adbkit`. Replacing all imports
Reviewed By: jknoxville
Differential Revision: D17343236
fbshipit-source-id: e6dd328f1a956544e8be2ab768aa270972463c6b
Summary:
moving logic for screen recordings to the respective devices, instead of having it in the button component.
This is part of my wider effort to unify our use of adb/adbkit and upgrade to the latest version of adbkit.
Reviewed By: passy
Differential Revision: D17318702
fbshipit-source-id: cff4459047d7a197ed6cb8ee8c290b4eaab41479
Summary: Hmm, how did this land despite the formatting error?
Reviewed By: jknoxville
Differential Revision: D17342057
fbshipit-source-id: 514be1548feb024cc107139ac962b0d69ff42198
Summary:
Relies heavily on types (not) defined in other modules,
so right now it's mostly sprinkling more `any`s in.
My type declaration is based on `dts-gen` output and some
manual fixes. This is the same level as the old flow-typed
definition we had.
Reviewed By: jknoxville
Differential Revision: D17282739
fbshipit-source-id: 0e5015d3b61044615a03c50fefade908041310a8
Summary: Per title. Somehow both typecheck, but importing the module like this doesn't work.
Reviewed By: jknoxville
Differential Revision: D17285507
fbshipit-source-id: 40a38db5dfb52213e0407f8bda83f2ebad5c50c7
Summary:
This one is in TS, so we get types for free.
`promisify` makes it rather awkward to work with overloaded
functions like `spawn`, so there's still value in having
a proper library for this.
Reviewed By: jknoxville
Differential Revision: D17204471
fbshipit-source-id: 3d07edfe2bb8c1e4c4f3134b53a0c4a0d9be383b
Summary: OS must always be defined.
Reviewed By: jknoxville
Differential Revision: D17204398
fbshipit-source-id: 0d84111c382af623843a41360bcb472394daf3f1
Summary:
I have moved the screenshot functions from ScreenCaptureButtons to the Device classes. I have slightly rewritten them so that they return a Promise which resolves to a Buffer. The Buffer can then be saved to a file or converted to a data Blob.
I have removed streaming and simply loaded the image into memory. Once the image is in memory it can be manipulated for various tasks i.e. written to a file, or displayed in the app.
iOS screenshots had to be rewritten. I now save the image to a temp folder, load it into the apps memory, and then remove the temp image.
Reviewed By: jknoxville
Differential Revision: D16939901
fbshipit-source-id: 3e39a5aeda8d48829ac5a8ff912a98f110341c07
