Status Update
No update yet.
Comments
am...@google.com
I'm not sure why the 3 min limit was put in place. It looks like it arbitrarily put in for Emulator recording in ag/3265023 and later in ag/3455232 was enforced on non-emulator recording as well.
I'll investigate why it was added in the first place and then experiment with a no limit version.
ja...@gmail.com
It's about time, no?
dm...@gmail.com
Seems like there was an arbitrary decision at some point to limit the screenrecord command to 3 minutes.
ag/350897
I have reopened internal bug
Note that if my request is approved, it'll only take affect for new API levels.
jp...@google.com
Maybe let us set the limit instead (size/duration) ?
As for new API levels, can you please make it reach Android 13?
ja...@gmail.com
ja...@gmail.com
I meant without limitation on duration. About storage, as long as there is enough and the OS is ok with it, it should be fine and without limitation.
If I want to take a video of hours of what's on the display, and I have enough storage for it, I see no reason why I shouldn't be able to do it.
After all, people can take very long videos using their camera (especially in low-resolution), so why can't I take a long video of something as simple as what's on the display?
You could even optimize it so that every now and then, the adb command will copy what the device has created and add it to what's on the PC, instead of having one huge file on the device that will be pulled. Meaning take small files one after another, and merge them. Or, have it stream it directly, without files on the device.
lu...@gmail.com
The three-minute limit is imposed by Android itself, but it's going to be lifted in Android 14.
ae...@gmail.com
Isn't there any kind of workaround for this?
What if you use on PC what ScrCpy is using, to mirror into the PC what's on the device (probably the same protocol as mirroring using USB to the TV), and capture the video straight into the PC, instead of storing anything on the device?
It's even better, because you aren't relying on Android versions, and the only restriction is how good the USB cable is.
Please think about it.
You could even record audio this way, because they also have some audio solution.
If you don't know of this marvelous tool, please check it out:
You could have some integration with it via the IDE, too (example is to detect if it's running, and if so, use it to record instead of adb). Maybe talk to the team there.
rs...@gmail.com
Electric Eel can mirror physical devices similarly to scrcpy, but uses adb shell screenrecord for video recording. Reimplementing video recording without adb shell screenrecord is definitely a possibility. We may consider it.
si...@gmail.com
If it uses the adb command, doesn't it mean it's also limited to 3 minutes?
ScrCpy is very efficient. And it has very convenient keys too (right mouse button for back key is the most common that I use).
The only downsides of ScrCpy currently, which I wonder if you solve, are:
1. mouse pressing doesn't show as touch. There is no way to put touch indication made by the mouse.
2. Unicode support. I can't type in Hebrew, for example.
3. No UI at all. Everything is in commands. They are quite good, but it means I have to read a lot to find what is useful for me.
Please consider teaming up with them. See what can help them to make it work better for both the tool, the IDE and adb commands.
Maybe have Android 14 more suitable for mirroring and screen-recording than ever.
jo...@gmail.com
Studio currently solves #3 but not #1 and #2. #1 is quite doable, but #2 is very hard. Please try mirroring in Studio (it's in Experimental settings in Electric Eel) and give us your feedback.
so...@gmail.com
1. How is it doable? Please tell them about it too. I requested it here:
I find it weird that even for adb commands of simulating touches, it's not shown, yet for "pointer location" it does get shown. To me it looks like a bug, so I reported about this here:
2. I thought that maybe I could create an accessibility app that just writes the Unicode, but it seems that there are very few things that accessibility could write for the user. Is it technically possible using accessibility? I couldn't find, so I requested here:
I also requested support of typing unicode via adb:
3. What options are there in the UI ? How do you even get to this on the IDE? Could it handle multiple devices ?
ma...@gmail.com Restricted+
he...@gmail.com
1. Please talk with them
2. A chair is supposed to be used for sitting, yet people sometimes stand on it to replace the light bulb. You should check the Play Store, of how many useful features apps use that are for everyone, not just people with some disability. Making life easier is not something that is good only for people with disabilities.
Besides, such a feature (typing for the user) is useful for all users, including people that have some issues with touches. Imagine for example an API that can type for the user, as it listens to what he says or thinks, using proper sensors. This can be useful for everyone. If a person lacks the ability to properly touch the screen, this can be useful. If the screen's touch doesn't work, it can be useful. There are plenty of usages that you can think of.
I myself don't consider myself as disabled in any way. Does it mean I'm not allowed to use apps that use accessibility API? Not even of Google? Of course not. Everyone should be allowed to use this API, whether it's for people with some disability or not.
3. Where?
th...@gmail.com
li...@blindenbacher.ch
Could be nice if it had similar features, and also have similar control as on ScrCpy.
You should really allow to turn off the display of the device while mirroring. I do it to save on battery and avoid smartphone display usage over time.
Check what happens on ScrCpy when using this:
scrcpy-noconsole.vbs -S --always-on-top --stay-awake
Here, requested:
wi...@gmail.com
I usually prefer it being an on-top floating window
Click on the Window icon, which is to the left of the gear one at the top of the Running Devices window.
You should really allow to turn off the display of the device while mirroring.
See
ma...@gmail.com
A stand-alone solution should be offered, which the IDE is used only as a convenience to open it, just like the emulator.
As for the display, that's good. It's not a bug though. Why everything here is marked as a bug...
:)
be...@googlemail.com
When suggesting a new feature, please file a feature request.
de...@gmail.com
Please allow to edit posts and titles of them.
ma...@googlemail.com
It is unlikely that editing already submitted comments will be allowed any time soon.
lu...@gmail.com
I was talking about the thread's first content and it title.
sc...@gmail.com
Please avoid this. Remove it completely.
It can depend on available storage, and if done via adb, it can be stored directly on the PC, instead of the device.
al...@gmail.com
Are you saying that 30 minutes is not enough?
ni...@googlemail.com
I can record the screen on the PC for hours, as long as there is enough storage and electricity.
How long can a smartphone last while connected via USB , that a restriction is needed? Why should a modern smartphone be limited by such a thing?
Why not store the file on the PC, directly?
Is it a problem related to USB speed?
If so, you can have a flag for infinite recording, and if it detects the USB speed isn't enough, you can act accordingly (use cache, show warnings, skip frames,... all depending on more flags if needed).
But even if it's recorded on the device, devices nowadays ship with plenty of storage. Why limit it?
lo...@gmail.com
The problem is that we do the recording using adb shell screenrecord which unfortunately, doesn't seem to support writing to stdout. It requires a local file. So we record and then pull the file.
If we allow unlimited recording we will eventually render the device unusable to unsuspecting users.
na...@gmail.com
Not enough for what?
For all reasonable scenarios where screen recording can be used. If you disagree, please describe a scenario where 30 minutes is not sufficient. If your description is convincing enough, we may increase the limit.
Why not store the file on the PC, directly?
This is far from trivial.
Is it a problem related to USB speed?
No.
ul...@googlemail.com
I suppose we could add the ability to screenrecord to write to stdout but even if we do that, it will have to be in a future release.
mr...@gmail.com
Re #29
This is not possible because the file header has to contain length information that becomes available only at the end of the recording.
In principle, it is feasible to implement screen recording without screenrecord, but it is far from trivial and may run into some licensing issues.
na...@gmail.com
Do all video formats put the size in the header?
scrcpy -r localfile.mp4 -N manages to do this. Maybe it writes temporary data to the local file and when you terminate it, it reads it back an writes it with the proper header?
This brings up a couple of options:
- Use
scrcpyinstead ofadb shell screenrecord.
- Might require OS specific handling
- Might require maintenance
- Might require licencing
- Write a
screenrecordadb command (as opposed to a adb shell command).
- This will allow the local (host) side of adb to read in the temp file and rewrite it with the correct header.
lo...@gmail.com
FWIW, I don't personally think either of the options above is worth the effort. The use case for unlimited recording seems to be niche to me and not worth such an investment on our side.
If you REALLY need unlimited recording, you can always use a 3rd party tool like scrcpy which you are already familiar with.
lo...@gmail.com
I don't understand what is this "render the device unusable to unsuspecting users" ? It's an existing feature that I want to remove its restriction. Why would users suspect a feature now in case its restrictions are removed?
How is the duration of the recording make things suspicious?
@28 What do you mean by "all reasonable scenarios "?
If I want to record myself playing a game that takes more than 30 minutes to finish, why should I be denied to do it via this command?
Most games take much more than 30 minutes to finish, for example.
Another example is that I don't know how long the video will take, so it's unfair to stop the recording before I finish.
Do you always know how long the recording will be?
Don't increase the limit. Remove it while adding more features.
It's not far from trivial to store on the PC.
Check ScrCpy, for example:
No limitation on time. Try it. Try more than 3 minutes. Try more than 30 minutes.
It writes directly to the PC. You can see the file gets larger over time on the PC.
And Android Studio also got screen mirroring recently, so even without mirroring it should be possible.
It doesn't have to be in a future release when using this method.
You could have it on adb these days too, and use the newer method on newer Android versions that will be more prepared for such changes. Maybe by then you could think of ways to enhance it, with more features and better performance.
@30 No issue. Use a format that is free.
On ScrCpy it's MP4. Format AVC.
mo...@gmail.com
Few points:
- Android Studio is intended for software development, not for things like recording somebody playing a game.
- scrcpy doesn't use
adb shell screenrecord. It does recording itself. - The AVC format (aka H.264) is not license-free. See, for example,
https://jina-liu.medium.com/settle-your-questions-about-h-264-license-cost-once-and-for-all-hopefully-a058c2149256#:~:text=Licensing%20is%20required%20if%20you,264%20videos .
an...@gmail.com
Re #33, So much to unpack here:
render the device unusable to unsuspecting users
If a user starts recording and forgets to stop, the device will quickly run out of storage and we'll start getting bug reports from users about their devices not working after they connected them to Android Studio. Wasting time on both sides.
playing a game that takes more than 30 minutes
Is this a business need of yours to record a game for over 30 minutes? Android Studio is a development tool. Even if you are developing a mobile game, I don't see why you would need to record such a long game session. And if you do, just use srccpy.
scrcpy can do it, why can't adb?
Well, there's an important distinction between adb shell screenrecord and scrcpy. ADB runs screenrecord on the device as a shell command. It doesn't treat that command any differently than any other command. So all it can do it read/write to the commands input & output streams. It can't do any post processing operations. Like amending the file header. scrcpy on the other hand runs entirely on the host side so if can do whatever it wants, including writing temp data to a local file and later, load it and emit a usable video file.
ch...@gmail.com
1. I'm not talking about Android Studio. I'm talking about adb.
Also, even on Android Studio, you can make games, and you can record videos of you working on the games, so testing them for more than 30 mintues is quite possible.
2. It shows that it's possible. I didn't say it uses it. If it used it, it means there is no limitation on this command, and then the request to remove the limitation of this command doesn't make sense.
3. So use something else that you know that is free, like the MP4 that the adb command creates.
There, I solved all your problems with such a request to remove a random restriction on recording video of something that's supposed to be a modern device. Something that was possible for years even before the first Android device came to be.
@35
But when you start recording, there is already a UI on the console/IDE that shows that it's recording, so it's easy to notice.
Plus, once you disconnect the device (everyone do it), it should cancel it anyway, or show some notification to ask what to do (maybe was disconnected by accident?).
The request was for adb. Android Studio uses adb, I know, but you can do it from outside, too.
and adb isn't used only for development. That's wrong. It's used for many uses. Example is mirroring, flashing ROMs, performing operations that can't be done on the device...
As for the game, it's an example out of many.
And ScrCpy isn't perfect either: I failed to find how to record the screen with audio.
@36 I'm the one suggesting to check it out, and use something similar as some people here say it's impossible for adb.
Please guys, what's the purpose of this restriction? If you have to have a restriction, just have a default one (30 minutes), and have an optional argument to set a different restriction, including one that's based on storage instead of time.
This way you can cover all your cases, and it's up to the user to choose what he wishes.
This is often the best solution for "what's the best behavior": Have a default one that you believe in, and let users have more options to cover the rest.
ni...@google.com
Any ADB feature requests have to be filed against ADB.
If you have to have a restriction, just have a default one (30 minutes), and have an optional argument to set a different restriction, including one that's based on storage instead of time.
This is exactly how adb shell screenrecord will work in Android 14, except for the storage option.
a....@gmail.com
1. So how will it work? I can set it to be 1000 minutes if I want to?
2. What extra options do you offer related to this ? Automatic triggers to stop recording?
3. Can you make it record directly to the PC ?
4. Can it record audio too (from speakers and/or mic) ?
5. Can it record orientation changes?
6. It seems adb actually uses AVC format, and you said that it's problematic. Would you use something else from now on?
ri...@gmail.com
Re #39
- Yes, but not through Studio. It shouldn't be too hard to offer this option in Studio, but additional effort is not justified due to lack of a compelling use case
- None
- No
- No
- No (limitation of
adb shell screenrecord) - Manufacturers of Android phones license H.264 codec
ri...@gmail.com
1. Please add to the IDE too, and offer perhaps "-1" for unlimited, based on storage, or something.
2. ok
3. Please make it so. Much more reliable on the PC, and the file won't be "ghost" if the USB is accidentally disconnected.
4. Please add this. Very important. Smartphones are capable of doing more than just show content. They also make sound on the way. See the case of YouTube, when the user watches a video there. Or when the user plays a game, and he wishes to send a video report that includes audio, as the audio has some bug.
5. Please add this. Very important. Smartphones can be rotated. See the case of YouTube, of how the orientation can change to show the video in full screen.
6. I don't understand. On PC it's ok because Windows OS has it covered, or something? Why can't you use the same format (the best that you can find) on Android and PC ?
so...@gmail.com
You may file feature requests for 2, 3, 4 and 5. You may do it for 1 too of you have a compelling use case.
- In
adb shell screenrecordvideo encoding happens on the phone, not on the host PC.
38...@gmail.com
The current request is for #1 . Why create a new request that is identical? I already requested to remove the restriction. The rumor is that the change isn't to remove it, but to replace it with a different duration, which isn't what I requested here.
Really I don't get you . I want a good competition between tools. Why would I use the IDE or adb for screen recording, if ScrCpy does much more? What could the IDE and adb offer that ScrCpy can't/doesn't offer , for both users and developers?
After so much time, mirroring is finally possible, but it lacks many features compared to the competition, and doesn't even work outside of the IDE (not portable, not standalone).
Anyway, here:
1+2.
3.
4.
5.
6. As it copies to the PC, couldn't it stream the encoded video, not letting the PC encode anything ? Is there such a format, that encodes "on-the-go" , meaning while recording ? Looking at how the file on ScrCpy is created and gets its size increased, it seems it's exactly how it works.
I still don't understand what is the issue, too. How come ScrCpy is fine with using this format, but you say it's problematic when using adb, in case the encoding is done on the PC ?
Anyway, this should be available anyway on the PC request. PCs can have various codecs, including for encoding.
I see no reason there should be a problem here.
vi...@gmail.com
Max duration of screen recording has been extended to 30 minutes on emulator and on Android 14+.
Description
- Build Number: google/crosshatch/crosshatch:12/SPB4.210715.014/7654839:user/release-keys
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
What type of issue is this? Crash
When did this happen?
Aug 27, 2021 07:00 GMT-05:00
What steps would let us observe this issue?
1. Set an alarm
2. It doesnt work
What did you expect to happen?
To sound
What actually happened?
It just vibrated once and stopped
How often has this happened?
Frequently
What was the effect of this issue on your device usage, such as lost time or work?
Moderate
Additional comments
It has always worked and its really bad that it can't wake me up
Related apps
Clock
com.google.android.deskclock
Version 64001698 (6.4 (361440548))
System App (Updated)
Filed by Android Beta Feedback. Version (Bundled): 2.18-betterbug.external_20210512_RC04