My device is Nexus 4 running Jelly Bean 4.2. I'm trying to record the screen and send it out. Most codes on internet do the cap by read /dev/graphics/fb0. It works fine in some devices and the older systems. But when I try it on my device, it fail. It only gives me blackscreen and all "0" in the raw data. I have run "adb root" to get the root permission, tried "chmod 777 fb0", "cat fb0 > /sdcard/fb0". Also I have tried codes like "mmap" and "memcpy" to get the data. But all fail. I have searched on internet and there seems no solution. And some threads said that the kernel may forbid you reading the fb0. Anyone have idea on that?
As the hardware advances, you're less and less likely to find an actual framebuffer with the screen contents in it.
As noted in the comments, adb uses the "screencap" command, which contacts surfaceflinger through a Binder call, falling back on /dev/graphcs/fb0 if that fails. The latter path is rarely used now.
If you really want to dig into how this works, you need to examine how surfaceflinger does composition, especially the hwcomposer HAL. The hardware composer takes multiple gralloc surfaces and composites them during scan-out. How this works differs from device to device; the hwcomposer implementation is usually done by the graphics chip manufacturer.
Screen shot generation, used by the app framework to generate the thumbnails for the "recent apps" feature, applies the same composition steps HWC does but exclusively with GLES. As of Android 4.2, the hardware composer isn't able to composite into a buffer.
Sometimes the hardware composer "punts", e.g. because there are more layers to composite than the hardware can handle. In that case, surfaceflinger reverts to GLES composition, and there will be a buffer somewhere that has the complete image; whether or not you'll find it by opening /dev/graphics/fb0 is a different matter.
Some starting points:
surfaceflinger
hwcomposer HAL interface
adb shell dumpsys SurfaceFlinger
Related
I am studying the camera bring up process in Android with Qualcomm platform. I have searched many bring up tutorial but I just can't figure out one thing: most of the tutorial would focus on the .dtsi setting and the driver porting. But I just can't find out where is the camera sensor boot setting. I can see the i2c booting sequence when I log the kernel message, but where the setting be recorded in BSP? Thanks a lot!
Kernel log of camera sensor booting
If the kernel logs those lines, then the kernel sends the settings to the sensor. Which makes sense: initializing a device is supposed to be done by the device driver, and in Linux device drivers are supposed to be in the kernel.
Looking at your log, it seems like a file named msm_camera_cci_i2c.c does it.
After a basic online search, it looks like it comes from an Android kernel, and that msm_camera_cci_i2c.c is just a utility file whoes functions are used by your actual driver. Thus look into your driver, the initialization data should live there.
To know which driver is being used you can look either in your devicetree or navigate through the /sys directory, e.g. in /sys/bus/i2c/devices/.
My device is Nexus 4 running Jelly Bean 4.2. I'm trying to record the screen and send it out. Most codes on internet do the cap by read /dev/graphics/fb0. It works fine in some devices and the older systems. But when I try it on my device, it fail. It only gives me blackscreen and all "0" in the raw data. I have run "adb root" to get the root permission, tried "chmod 777 fb0", "cat fb0 > /sdcard/fb0". Also I have tried codes like "mmap" and "memcpy" to get the data. But all fail. I have searched on internet and there seems no solution. And some threads said that the kernel may forbid you reading the fb0. Anyone have idea on that?
As the hardware advances, you're less and less likely to find an actual framebuffer with the screen contents in it.
As noted in the comments, adb uses the "screencap" command, which contacts surfaceflinger through a Binder call, falling back on /dev/graphcs/fb0 if that fails. The latter path is rarely used now.
If you really want to dig into how this works, you need to examine how surfaceflinger does composition, especially the hwcomposer HAL. The hardware composer takes multiple gralloc surfaces and composites them during scan-out. How this works differs from device to device; the hwcomposer implementation is usually done by the graphics chip manufacturer.
Screen shot generation, used by the app framework to generate the thumbnails for the "recent apps" feature, applies the same composition steps HWC does but exclusively with GLES. As of Android 4.2, the hardware composer isn't able to composite into a buffer.
Sometimes the hardware composer "punts", e.g. because there are more layers to composite than the hardware can handle. In that case, surfaceflinger reverts to GLES composition, and there will be a buffer somewhere that has the complete image; whether or not you'll find it by opening /dev/graphics/fb0 is a different matter.
Some starting points:
surfaceflinger
hwcomposer HAL interface
adb shell dumpsys SurfaceFlinger
My question is that is there any chance that any command in adb can damage (both hardware and software) my android phone (my phone is not rooted) and if software can it be recovered by factory reset? It is Micromax A120 and runs on android 4.4.2.
Yes, you can easily mess up your phone if you mess with ADB and don't know what you are doing. This is particularly true if you are using the 'Recovery' options (flashing new software to your device) in particular, if don't do this correctly, there are opportunities to mess things up (particularly if you are not patient, and don't wait for all operations to complete).
For the most part ADB is just a communication mechanism, and if you are careful to do only things you are confident are safe, there is minimal risk.
Bottom line, there is nothing specific about ADB that is risky, but it is a tool, and if mis-used could cause issues. Use it carefully, and you should be fine.
With adb you can delete and copy data on your mobile phone. So you can loose data or damage the Android System. However you have every time the chance to go into fastboot mode and flash a new Android ROM using the fastboot tools. You only can damage your Android device if you flash a corrupted bootloader using fastboot.
So in short form:
ADB: You can delete data but you have everytime the chance to recover your system. (However you can loose all your data!)
Fastboot: You can destroy your Android device if you flash a corrupted bootloader. It's irreparable.
I have a widget that will tell the user the capacity of a connected USB device, as well as the amount of space used. I have gone through the android.hardware.usb API and I see nothing that can accomplish determining the size of a connected USB device and its usage.
Right now I am capturing Intent.ACTION_MEDIA_MOUNTED and searching in the Dir of the mount point for specific files etc... All of that is working fine, but for the life of me I cannot see how to leverage the API to determine the overall size, and usage, of a connected USB device.
Do any of you fine folks know, or have an article for me to read? Thanks all.
It sounds like your device is actually mounting the connected USB device's file system, which seems like it may be a vendor add-on rather than a stock android capability.
If that is indeed the case, whatever other options you might have you can use the df shell command, or more properly duplicate its functionality in java or a native subroutine.
You can view the source of android's df here:
https://github.com/android/platform_system_core/blob/master/toolbox/df.c
It looks to be a fairly standard implementation - read /proc/mounts to find the filesystems, call statfs() on each one. You'd probably want to filter by those of interest.
Yesterday I decided to fix the internal front speakers of my "HTC Desire Z" (aka. G2). While I was able to fix them, I broke the connector for the microSD slot (the left one). After trying to fix it for several hours, I gave up. It isn't in the scope of my hardwareskills :-(
Well, since I have like 600mb left on /data and my device is rooted, I tried to find a software solution i.e. "emulate" a SDcard device (because many applications require one to work properly, e.g. the camera app). I found here http://www.android-x86.org/documents/sdcardhowto a description how to create a vfat image and mount it as loopback.
While this is exactly what I want, I don't get it to work:
I don't know how to modifiy /proc/cmdline, or
how the entry in /etc/vold.fstab should look like.
dev_mount sdcard /mnt/sdcard auto /data/sdcard.img
didn't work for me. according to logcat, I have this version: I/Vold ( 2368): Vold 2.1 (the revenge) firing up
btw, just mounting the loopback device to /mnt/sdcard didn't work too. For example, the camera app still claims there isn't a SD card inserted.
edit: I also asked this on xda -> http://forum.xda-developers.com/showthread.php?t=1393395
There's no way for an Android application (constrained within the application sandbox) to create a loopback device.
Anything outside of this is not a developer question, and should be posted to another forum (e.g. https://superuser.com/).
I don't agree. Hanitaro Tide and PlasmaSoundHD both have created loop devices on my phone, all by themselves. On an x86 device it's even easier to fake an sdcard.img.p