I think I figured out my problem. True, at the same time I killed the system boot a couple of times
For some reason, apktool was disassembling
services.jar with the “do not compress dex” parameter set. After I removed this parameter from
apktool.yml everything worked.
An interesting thing is that control.html accepts query parameters "size" and "rate", which can take the values of "1080p" or "720p", and "Extra", "High", or "Low", respectively, and they do get passed to the respective websocket server that does the actual streaming when the websocket session starts, and there is some logic in the server code to switch size and bit rate accordingly (below the lines where the default size constants are set), but for some reason it does not work at all -- it always sets the values to default. Maybe I will try to untangle the spaghetti of conditions and gotos in the smali code to see why, but before that I'll try to change the default bitrate to different values to see if that works at all.
If you look in debug, you can see that the "size" and "rate" parameters are passed with the value null , so the server code sets these values by default.
I also thought about this point: with changes in services.jar described in the link, it turns out that checking application privileges is completely disabled. That is, any application can receive any permission. This may not be very good, I think. We need to think about how to make sure that permissions are granted only to our modified applications. You can try making a condition based on the application class name, for example. If this is com.rigol.scope or com.rigol.webcontrol, then the signature verification returns an unconditional positive result, otherwise let the standard verification be carried out.
As far as the screen recording goes, I think we already have the highest bitrate it can do. The encoder itself supports bitrate values up to 40000000 (10000000 was another value that I saw somewhere), but if I change the default value of 6000000 to a higher one, it doesn't result in the increase of the output file size or the video quality. If I make it lower, however (say 500000), then yes the quality drops, so we know that this parameter isn't ignored.
This is the maximum bitrate. Probably, during the compression process, the bitrate simply does not reach maximum values above 6,000,000. In general, the codec settings should have other parameters that are responsible for the quality of the compressed video stream, most likely because of them the bitrate does not rise high.