[TOOL][WIN][v1.5]Take Screenshots in Recovery & Aroma - All devices

This is a tool to capture screenshots while in Recovery or the Aroma Installer.

Your Recovery MUST have ADB enabled or no matter what you do you'll NEVER pull a Screenshot

v1.5
Feb 9, 2014
-Total rewrite of structure and function
-Added check for framebuffer in /dev/fb0
-Added a manual mode where you don't have to have ADB connected as long as you have a file
-Added loops for every pixel format supported as input for FFmpeg
-Added folders for pngs to go into when they are rendered
-Added the option to convert both framebuffers into two seperate images; or grab the top or botom images

One big problem people are having when trying to capture screenshots in recovery, on some devices, is the extra framebuffer info that is tacked on to the end of each pixel row. Through a lot of digging and not finding too much information on it, I've finally found a way to determine what dimensions to use for, I believe, all android devices.

Fb2png is a great open source program, but unfortunately it only works with framebuffers that don't have a stride. FFmpeg is what I use here. FFmpeg is a great open source command line transcoder. It's pretty hefty and can do a vast amount of conversions (audio/video/codecs/images) all from the command line. They are two different beasts with, Fb2png made for the sole purpose of grabbing the framebuffer then converting it into a png file. While FFmpeg is more of a computer side program, and you tell it exactly what you want it to do.

Dealing with the framebuffer we are dealing with raw data. There is 0 extra information in this file, no line size, title, header, no nothing except a continuous write of pixel data. That's great for guessing the exact file size, and that's about it. But to get it to a view-able image, you have to specify where each line starts/stops, and convert the pixel format to whatever you want to use, your file-type.

I found that if you divide your width; the Nexus 5 for example is 1080; by 32, your stride will equal the value to add to that 1080 to go up and make it evenly divisible by 32. The next number up from 1080 that is evenly divisible by 32 is 1088, and those 8 extra pixels is your stride. Height is not as important, as far as what we are doing, simply because everything is read left to right, then advance down. Resolution being divisible by 32, or MOD 32 to graphics people, is becoming not as common on devices nowadays, AND those are the devices fb2png gives distorted screenshots with. Maybe @Phil3759 knows how to fix this for fb2png.

I made this batch script that takes into account your stride, if you have one. If your width is 768 for example, you won't have one because 32 goes into 768 an even 24 times.

You can also use manual mode and use any raw image you have saved.
Please read the instructions below.

Recovery Screenshot v1.5 batch script

Instructions:
If you have already downloaded a previous version, you do not have to download everything again. The bat file is the only difference between any of the versions. You can copy the script up above for v1.5 and edit the one you already have in Notepad, or any other text editor; Paste the new version in there and save it. And thats it.
Download Recovery Screenshot v1.5
Extract it to a new folder.
You will have the programs FFmpeg & ADB.
Two .dll files for ADB. And the batch script RUNrs.bat
I assume you have your ADB drivers squared away!!

Reboot into your recovery.
Run RUNrs.bat and it will ask you if you want to set up a configuration or go into manual mode.
If you have ADB good and ready to go, I would reccommend going ahead and setting up your configuration now.
Enter you native resolution, with width being the short side! Don't adjust for stride either. Your native resolution should be entered.
It will then pull the framebuffer, and convert it into several pngs with different pixel formats.
Go to the folder "Pixel_formats" and look through them and make note of the correct one, specifically the filename of the correct one.
If you see your image, then hit "1" to input the name of the pixel format (which is the name of the png that is right)
If you don't see your screenshot in that folder hit "2" and it will generate a bunch more from various pixel formats.
Look through those, it might take some time LOL, and see if you can skip over the cool looking ones until you see yours.
Hit 1 and go input it.
From there you are good to go. You'll see your configuration in the upper left corner of the main menu window, and it will be persistent when you close the program out. You have the option to grab both framebuffers with this version. You are probably wandering why there's two. Well android uses a double framebuffer. Have you ever noticed that sometimes when you got a screenshot before, it will be a previous screen on there? Android has one screen that is displayed, and another one adjacent to it (they are butted top to bottom) that is meant for drawing on (really quick I might add). The idea behind that (on a fast scale) is: When the device switches to a new frame, the device can render the next screen in a different buffer while the current screen stays displayed. And then pop up that screen when it is ready. If it didn't do that, and used just one framebuffer, then when you go to a different screen, the new screen would have to be processed and drawn over the old screen and just wouldn't look as good. When ANY little bit of information changes on you screen, yes even the minute number on the clock, it draws it quickly and swaps the two buffers. So now all of the sudden your main framebuffer is opposite what it was before. And the other one is the artboard.

Manual mode does not take into account stride. It is just a tool to convert any raw image into pngs, and at the same time figure out what pixel format something, like a splash screen, might be. You don't have to have ADB enabled to use it. You can use a file of you own, just place it in the main folder, and after you supply the width and height, input the file name. If you just press enter instead, it will pull you framebuffer, and you will need ADB for that.

In Manual mode you can select between different pixel formats grouped by Bytes per pixel (1&2 Byte/pp, 3Bpp, 4Bpp, 5Bpp, and 6&8 Byte/pp)
Or you can run them all. If you run into errors with FFmpeg in manual mode, try not to seek too far down with your height in the resolution selection. If you overshoot the expected filesize looking for data, FFmpeg will not convert it.

Notes:
If you change your recovery, you may have to clear the settings, it depends if there is a different pixel format. You can do so easily in the program, or you can just delete 'settings.cfg'

Sometimes your screenshot may seem disorganized or torn. This may happen when the very first screen is drawn, and also in between framebuffer swaps and writes. This is totally normal. This tool grabs your current framebuffer in its current state (in your devices memory). It can't automatically discern if the image is in fact what you see on your device in a given moment. If your screenshot is torn, you can:

• Grab both framebuffers (option 3 in normal mode)
• Quit hitting buttons to change the screen when you are pulling the framebuffer! lol
• Wait for the framebuffer to swap with a clock change, or force it to change by going anywhere in the menu and then back to where you want to get your screenshot. A sub note on that: A button highlighting, and then a screen change will result in two swaps of the framebuffer and your next image will be on the same side of the framebuffer. If your screen was on the top and you hit a button (that highlights), then the next screen will also be on top. If there is no button highlight, hence just a draw of the next screen and a swap: The next screen will be on the opposite side. Same goes for any other change to your device screen, such as a clock digit changing. What was up now is down, and vice versa.
• Aroma only uses the top framebuffer. It never calls for a swap, and the bottom framebuffer will stay whatever was last on it.

I do need to thank @Whiskey103 for his work over here. And I promise this is the last time I'll mention you, lol

Changelog:
v1.5
Feb 9, 2014
-Total rewrite of structure and function
-Added check for framebuffer in /dev/fb0
-Added a manual mode where you don't have to have ADB connected as long as you have a file
-Added loops for every pixel format supported as input for FFmpeg
-Added folders for pngs to go into when they are rendered
-Added the option to convert both framebuffers into two seperate images; or grab the top or botom images

v1.1
Feb. 5, 2014
- Fixed algorithm for calculating stride on devices that don't have one.