Status Update
No update yet.
Comments
sp...@google.com
aa...@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.
lb...@gmail.com
It's about time, no?
aa...@google.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.
lb...@gmail.com
Maybe let us set the limit instead (size/duration) ?
As for new API levels, can you please make it reach Android 13?
aa...@google.com
I suspect that removing the limitation will not be accepted. The screenrecord command writes to a file on the device. Having no limitation can result in the device being rendered unusable due to lack of space on the file system where the file is written. For example, if a user runs adb screenrecord /sdcard/foo.mp4 and forgets about it, the sdcard will eventually be full and many apps will start to fail.
lb...@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.
sp...@google.com
sp...@google.com
The three-minute limit is imposed by Android itself, but it's going to be lifted in Android 14.
lb...@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.
sp...@google.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.
lb...@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.
sp...@google.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.
lb...@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 ?
sp...@google.com
https://github.com/Genymobile/scrcpy/issues/44 is pretty informative. Showing touches is harder to do than I thought.- Accessibility APIs are not supposed to be used for anything except accessibility.
- Try it ;-)
lb...@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?
lb...@gmail.com
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:
sp...@google.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
lb...@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...
:)
sp...@google.com
When suggesting a new feature, please file a feature request.
lb...@gmail.com
Please allow to edit posts and titles of them.
sp...@google.com
It is unlikely that editing already submitted comments will be allowed any time soon.
lb...@gmail.com
I was talking about the thread's first content and it title.
lb...@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.
sp...@google.com
Are you saying that 30 minutes is not enough?
lb...@gmail.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?
aa...@google.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.
sp...@google.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.
aa...@google.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.
sp...@google.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.
aa...@google.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.
aa...@google.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.
lb...@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.
sp...@google.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 .
aa...@google.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.
lb...@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.
sp...@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.
lb...@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?
sp...@google.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
lb...@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 ?
sp...@google.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.
lb...@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.
sp...@google.com
Max duration of screen recording has been extended to 30 minutes on emulator and on Android 14+.
lb...@gmail.com
sa...@google.com
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Giraffe Canary 1 (2022.3.1.1)
- Android Gradle Plugin 8.1.0
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
lb...@gmail.com
Please just remove any time restriction. Stream directly to the PC. Can be encoded data too.
Maybe you changed it only from Android 14 (which isn't available yet) ?
sp...@google.com
Yes, the limitation comes from the Android itself. Have to wait for Android 14 to get higher limit for physical devices. For emulators the higher limit doesn't require Android 14.
lb...@gmail.com
What is the text then?
Is it finally without a time limit? No need for a limit, especially on PC where both the IDE and the emulator are on the same OS and same resources...
sp...@google.com
Yes, the text is changed appropriately. The time limit still exists, but it is increased to 30 minutes. No work is planned to support true limitless recording.
lb...@gmail.com
Also, why do you have to have a limit? Especially when it's saved on the PC?
I can record for hours on other apps, whether on the PC or on Android.
he...@gmail.com
anything which hook your site and I am not a robot. So please recover it.
ai...@gmail.com
fix problem
lb...@gmail.com
sp...@google.com
The recording time limit is 30 minutes on API 34.
lb...@gmail.com
Let us choose how long or how much space to take or any other trigger, but don't force us to have a limit.
Please remove the limitation and provide more options.
People can play and watch videos for much more than 30 minutes , for example.
sp...@google.com
See
lb...@gmail.com
The IDE has changed its text, but the request is to remove the limitation as it doesn't make sense.
PC has plenty of space these days, and we can have various rules about it.
Smartphones also have enough space to hold longer than a 30 minutes video. People watch videos of much longer time.
lb...@gmail.com
I want to remove the limitation, not to extend it.
Description
I don't see any reason to have it limited to 3 minutes.
Should be as much as we need.
Some video tutorials are longer.
Please set it to be without any limitation, with an option to limit it to a specific time.
Also add an option that if it is about to fail due to low storage, stop it.
See attached to understand what I'm taking about.