[Fire HD 8 and HD 10 Original Android Development] ggow:
Understanding the Camera Issue:

@daniel_hk made a good post on understanding this:

REF

: https://xdaforums.com/t/rom-7-1-2_r36-27jan2018-lineageos-14-1-custom-roms.3513466/

Relevant Extract of the information

III. The Camera

After my first ROM was out, the most eye catching in the log would be the stack corruption in libcam.halsensor.so.

11-24 21:53:55.967 490 490 F DEBUG : #08 pc 00017459 /system/lib/libcam.halsensor.so (_ZN12ImgSensorDrv13getResolutionEPP34ACDK_SENSOR_RESOLUTION_INFO_STRUCT+60)

After study the source for mt6735, I found it was called within the blob libcam.halsensor.so. In the function ImgSensorDrv::getResolution(), an ioctl() call was passed to the kernel. I was thinking it was caused by user space data handling in the kernel. After a series of trials and dumping, I remarked that part of code from the kernel. The crash persisted. That means it was from the blob itself. I tried a shim library to replace the function ImgSensorDrv::getResolution() but the result is the same. That means the callee was responsible.

After some digging, I was pretty sure it was caused by the alignment (address sanitize) of struct addresses. The latest blob from Lenovo dev.1631 (also the latest for mt6752 devices) were built with gcc 4.9 Clang 3.6. Nougat now use Clang 3.8 by default. Those blob already have alignment support in Clang 3.6 might have issues with the new Clang 3.8.

What is address alignment? In short, a 32 bit processor can handle 32 bit at a time. It would be a easier for the register to locate memories in 32 bits (4 bytes) cells (aligned). If the head or tail for a block of memory is not aligned, extra code would required to separately handle those loose ends. The new clang compiler would fill leading bytes with its own algorithm to make the pointer or variable aligned. Why is ImgSensorDrv::getResolution() being "affected"? The argument of it is a pointer to ACDK_SENSOR_RESOLUTION_INFO_STRUCT. Its definition can be found in the kernel. It is a struct of an array of pointers to another struct. The source from Mediatek use direct reference to the address of struct variables all the time. This is inappropriate in sense of address alignment. Early compilers didn't handle alignments and won't have problem with that. Newer compiler would use its own algorithm to align the structs and pointers. I guess Clang 3.6 didn't handle the above complex struct as argument well. Nougat linker and loader are all built with Clang 3.8. Local variables are allocated at load time which might be handled differently. Thus a call to ImgSensorDrv::getResolution() would cause the stack corruption. :eek:

** Those interested may read this article for detail. **

1. Work around

Using older blobs built by gcc 4.8 or earlier might work. Jiayu S3's AOSP were using those old blobs. I'm new to K3-note. I don't think I have the patience and experience to test all the existing blobs. That's the main reason I uploaded the last two test ROM. Trying blobs and hoping some combination would work is passive. Stlport is also obsolete for some time now. I rather deal with the problem directly. :cowboy:

2. The solution

Without the source, building the whole blob is impossible. Even if we have the source from other devices, those custom parameters are unique to each image sensor. It's impossible to guess or back engineer... :(

If we can change the way ImgSensorDrv::getResolution() is being called or didn't touch the argument within the function. It would avoid the crash. Unfortunately, the function need to fill a local struct within the ImgSensorDrv class. That means it is not seen outside ImgSensorDrv. The only way is to replace the whole ImgSensorDrv class. Fortunately, it is self contained. We can write a wrapper to replace the ImgSensorDrv class only. The source from mt6735 or mt6595 are a bit different and obviously can't be used directly. Most of the struct can be cross referenced to the kernel source. There are two local sturct left unknown. One is for the commands sent to the kernel. The other is some info. collected from the kernel.

With the wrapper, the crash was gone but still no preview. I wrote a test HAL to dump the values in stock ROM. Guessing the values against the names was not a decent job. Fortunately, there were only a few differences. After nights of trial and error, I finally pulled everything together. Camera is working now! Video recording is still not working. Seems codec related. Some say it's not a problem "again". Hoping there will be some real solutions and helps soon...