Database Develop

[Q] Camera API?

Does anyone out there actually have one yet? Does the stock android API allow you to take full 16MP photos, access the hardware zoom, etc? If not, are there Samsung API extensions available in the open source code that would allow custom camera developers to get to all the features of the camera?
I ask because I find developing on the "other" android camera from Nikon to be very frustrating. It has a 16MP camera, but the stock Camera class only allows access to a max 8MP picture size (and other features are apparently also limited).
I'd like to know if it is worth the extra money to get a platform that is better for developers (but I really don't want to buy a data plan from AT&T to go with it).

+1 for this question.
It would be cool to be able to develop some computational photography type apps (and therefore make it worth buying the device), so having access to focus, shutter time, while balance, etc. would be rather useful.

lardman said:
+1 for this question.
It would be cool to be able to develop some computational photography type apps (and therefore make it worth buying the device), so having access to focus, shutter time, while balance, etc. would be rather useful.
Click to expand...
Click to collapse
I did finally get one, and my camera app can indeed take 16 MP images, so at least one of the high end features is available. My app needs lots more work before I find out about everything else, but it is looking hopeful.

Claghorn said:
I did finally get one, and my camera app can indeed take 16 MP images, so at least one of the high end features is available. My app needs lots more work before I find out about everything else, but it is looking hopeful.
Click to expand...
Click to collapse
And could your application control optical zoom programmatically? (not by hardware button)

kingarold said:
And could your application control optical zoom programmatically? (not by hardware button)
Click to expand...
Click to collapse
That's one of the zillions of things I haven't written any code to try yet (I'm mostly working on fancy triggering methods - motion detection, light detection, etc., so I haven't done much with many of the settings).

Please read forum rules before posting
Questions go in Q&A
Thread moved
Thank you for your cooperation
Friendly Neighborhood Moderator

kingarold said:
And could your application control optical zoom programmatically? (not by hardware button)
Click to expand...
Click to collapse
I played around with the camera more today, and noticed that the "paper camera" app which comes preinstalled can indeed control the zoom (you can watch the lens move in and out as you use the slider on the screen). So unless samsung have installed some special samsung only version of paper camera, that probably means optical zoom works in the normal camera API.

I've had a look at the Camera api and it appears that manual focus isn't supported (on any Android phone). It does seem that people have coded manual focus capabilities by extending the camera driver in the kernel (see e.g. http://forum.xda-developers.com/showthread.php?t=630989)
Therefore we need to know what the camera chipset is. I'll have a look around and see if there's some dmesg and sysfs output, otherwise those would be useful. I've already grabbed the kernel source and will have a look through to see what's specified in the defconfig.

Just had a trawl through the defconfig and source code and didn't see anything that looked obviously like the camera chip. I suppose it and the processing chip may well be completely closed source (which is probably quite likely) in which case it would be interesting to see what kernel modules are loaded with the camera app open.
Ah, relevant system info here: http://forum.xda-developers.com/showthread.php?t=1982198 time to do some more digging

I'd guess that the camera and other image processing hw are attached to the m9mo SoC.
The kernel header says this:
* Driver for M9MO (16MP camera) from NEC
(header here: Kernel\include\media\m9mo_platform.h)
and this module appears to be loaded in the output linked above.
I suppose with some work one might be able to determine the meaning of the parameters which are passed through the kernel module functions, and perhaps enable manual focus mode.

All the non stock camera apps I have tried so far use the optical zoom through the software interface. The lens barrel clearly moving in response to the zoom function.
In fact what's missing is the ability to use the hardware button to control the zoom in a third party app. Awkwardly written to use an on screen slider instead but understandable as these apps are designed to be run on phones/devices without hardware zoom buttons.

Not sure if y'all have seen this, but here is the publicly released code from Samsung for the Galaxy Camera:
http://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=EK-GC100

I grabbed the factory images (http://forum.xda-developers.com/showthread.php?t=2006138), and attempted to extract the initramfs from the boot.img file; unfortunately this failed using the tools I've previously used on the Galaxy Tab (i.e. https://github.com/mistadman/Extract-Kernel-Initramfs/blob/master/unpack-initramfs). Any thoughts appreciated (I'm trying to get hold of the closed source kernel modules, namely *m9mo*.ko assuming this exists)
I had more success with the system.img (using simg2img to convert the file then mounting it as an ext4 loop device). There are also some camera-named odex files, which I took a quick look at, but I'm new to the whole reverse-engineering of Dalvik files so will have to re-visit this when I have some more time at the weekend.
More interestingly, there are some native library files in /lib and /lib/hw that look relevant. There's a camera service and a camera client library, which presumably are used by the Java code via JNI (or the like). I also note that there are a group of files named libarcsoft_*.so, which perform things like blink/smile/face detection and tracking (from the names).
Anyway I'll have a look at the .so files later in the week (as this is what I'm used to doing), but any advice/analysis on the Dalvik side would be appreciated.
---------- Post added at 07:26 PM ---------- Previous post was at 07:09 PM ----------
apprentice said:
All the non stock camera apps I have tried so far use the optical zoom through the software interface. The lens barrel clearly moving in response to the zoom function.
In fact what's missing is the ability to use the hardware button to control the zoom in a third party app. Awkwardly written to use an on screen slider instead but understandable as these apps are designed to be run on phones/devices without hardware zoom buttons.
Click to expand...
Click to collapse
Is the hw button status available thought the sysfs? I.e. check /sys/class/input (or open the relevant dev files directly if possible). I'm still unsure how much of the camera functionality is handled by a SoC which would need to be talked to (i.e. to control the sensor, zoom, focus, etc.), or whether some of this functionality is controlled directly by the kernel (i.e. easier for us to get into).

For those who need some android camera information that can be retrieved on SGC, I can say that:
optical zoom can be controlled by
Code:
Camera camera = ...
Camera.Parameters params = camera.getParameters();
params.setZoom(number);
camera.setParameters(params);
Flatten returns such parametres:
Code:
flash-mode-values=off,auto,red-eye,fillin,slow,red-eye-fix;
focus-mode-values=auto,infinity,macro,fixed,face-detection,continuous,manual,multi,touch,object-tracking;
preferred-preview-size-for-video=640x480;
factory-af-led-lv-limit=-1,-1;
zoom=0;
factory-af-scan-limit=-1,-1;
max-num-detected-faces-hw=0;
continuous-mode=off;
zoom-supported=true;
metering=center;
whitebalance=auto;
scene-mode=auto;
jpeg-quality=1;
factory-testno=0;
factory-af-diff-check=-1,-1;
preview-format-values=yuv420sp,yuv420p;
best-mode=off;
red-eye-fix=fail;
jpeg-thumbnail-quality=100;
preview-format=yuv420sp;
zoom-action=zoom-stop;
face-detection=off;
video-size-values=1920x1080,1280x720,768x512,640x480,320x240,176x144;
factory-zoom-slope-check-data=-1,-1;
preview-size=640x480;
focal-length=4.100000;
flash-charging=0;
factory-cap-range=-1,-1;
factory-iris-range=-1,-1;
preview-frame-rate-values=120,60,30,25,20,15,10,7;
factory-af-scan-range=-1,-1;
preview-frame-rate=30;
jpeg-thumbnail-width=160;
video-size=0x0;
scene-mode-values=auto,portrait,landscape,night,beach,snow,sunset,fireworks,sports,party,candlelight,dusk-dawn,fall-color,back-light,text;
preview-fps-range-values=(7000,120000);
jpeg-thumbnail-size-values=160x120,160x90,192x128,0x0;
zoom-ratios=100,120,150,180,220,280,340,400,500,610,750,940,1140,1390,1790,2100;
preview-size-values=1280x720,1056x704,960x720,768x512,640x480;
factory-zoom-range-check-data=-1,-1;
factory-af-led-range=-1,-1,-1,-1;
picture-size-values=4608x2592,3264x2448,4608x3456,4608x3072,3648x2736,2592x1944,2304x1728,1984x1488,1920x1080,1024x768,960x720;
preview-fps-range=7000,120000;
auto-whitebalance-lock=false;
min-exposure-compensation=-6;
antibanding=off;
max-num-focus-areas=1;
vertical-view-angle=46.3;
factory-wb-value=-1,-1,-1,-1;
horizontal-view-angle=59.6;
jpeg-thumbnail-height=120;
continuous-fps=;
focus-mode=auto;
factory-sc-speedtime=-1,-1;
factory-gyro-range-data=-1,-1,-1,-1;
video-frame-format=yuv420sp;
max-num-detected-faces-sw=3;
picture-format-values=jpeg;
max-exposure-compensation=6;
factory-ois-range-data=-1,-1,-1,-1,-1,-1,-1;
focus-areas=(0,0,0,0,0);
exposure-compensation=0;
exposure-compensation-step=0.33;
flash-mode=off;
flash-standby=off;
auto-exposure-lock=false;
wb-custom=-1,-1;
effect-values=none,mono,negative,sepia,antique,point-blue,point-red,point-yellow,warm,cold,washed;
factory-punt-range-data=-1,-1,-1;
factory-vib-range-data=-1,-1,-1,-1,-1,-1;
picture-size=4608x2592;
max-zoom=15;
factory-gain-liveview-range=-1,-1;
effect=none;
blink=fail;
whitebalance-values=auto,incandescent,fluorescent,warm-fluorescent,daylight,cloudy-daylight,custom,temperature,incandescent,prohibition,horizon,ledlight;
picture-format=jpeg;
focus-distances=0.15,1.20,Infinity;
factory-flash-range=-1,-1;
raw-save=0;
curr_zoom_level=0;
hdr-mode=0;
antibanding-values=50hz,off;
Also I have noticed in log that internal camera has such parametres:
Code:
AppShutterSound=0;
acb=off;
af-lamp=off;
antibanding=50hz;
antibanding-values=50hz,off;
aperture=80;
auto-exposure-lock=false;
auto-whitebalance-lock=false;
best-mode=off;
blink=fail;
bracket=off;burst-mode=off;
cam_mode=0;
camera-id=1;
continuous-fps=1fps;
continuous-mode=off;
contrast=0;
curr_zoom_level=0;
disable-aeawb-lock=0;
drive=single;
effect=none;
effect-values=none,mono,negative,sepia,antique,point-blue,point-red,point-yellow,warm,cold,washed;
exposure-compensation=0;
exposure-compensation-step=0.33;
face-detection=off;
factory-af-diff-check=-1,-1;
factory-af-led-lv-limit=-1,-1;
factory-af-led-range=-1,-1,-1,-1;
factory-af-scan-limit=-1,-1;
factory-af-scan-range=-1,-1;
factory-cap-range=-1,-1;
factory-flash-range=-1,-1;
factory-gain-liveview-range=-1,-1;
factory-gyro-range-data=-1,-1,-1,-1;
factory-iris-range=-1,-1;
factory-ois-range-data=-1,-1,-1,-1,-1,-1,-1;
factory-punt-range-data=-1,-1,-1;
factory-sc-speedtime=-1,-1;
factory-testno=0;
factory-vib-range-data=-1,-1,-1,-1,-1,-1;
factory-wb-value=-1,-1,-1,-1;
The only thing that does not work for me is setting ISO value.
I have tried such methods, but camera shoots in auto mode, not 200:
Code:
Camera camera = ...
Camera.Parameters params = camera.getParameters();
params.set("iso", 200);
params.set("current-iso", 200);
params.set("iso-mode-value", 200);
params.set("iso-value", 200);
params.set("iso-mode", 200);
camera.setParameters(params);
Any help, how can I control ISO?

No idea how to set your desired ISO value I'm afraid, perhaps try setting scene-mode to something other than auto to see if the scene mode selection overrides your ISO setting?
I was interested in focus rather than zoom, is it possible to programmatically set the focus using e.g. focus-mode=manual (or fixed) and then setting a value for "focal-length"?

lardman said:
No idea how to set your desired ISO value I'm afraid, perhaps try setting scene-mode to something other than auto to see if the scene mode selection overrides your ISO setting?
I was interested in focus rather than zoom, is it possible to programmatically set the focus using e.g. focus-mode=manual (or fixed) and then setting a value for "focal-length"?
Click to expand...
Click to collapse
Tried doing this, had no effect.
I set focus-mode to "manual" then dumped parameters (got the same parameters so nothing changed). As a shot in the dark I tried setting focal-length but it's a float value and you can only set string and int values. I tried setting it as an int which did nothing and also as the string representation of a float which did nothing.
It appears to me that this is going to require some spalunking through libraries to see if someone exposed a move_lense function lol

luscoma said:
Tried doing this, had no effect.
I set focus-mode to "manual" then dumped parameters (got the same parameters so nothing changed). As a shot in the dark I tried setting focal-length but it's a float value and you can only set string and int values. I tried setting it as an int which did nothing and also as the string representation of a float which did nothing.
It appears to me that this is going to require some spalunking through libraries to see if someone exposed a move_lense function lol
Click to expand...
Click to collapse
I've spent the last day or so poking around in the camera and have pretty much approached the limit of my knowledge. I'm going to post what I've found here so that maybe someone whose been down this road can give some more information.
TL;DR; The functionality we seek is not directly exposed, there's a possibility that some functions which look like factory test functions in the driver may do what we need to do but I am not sure if that can really be confirmed.
Okay starting with the bits I know:
First up the m9mo driver in the linux kernel (/drivers/media/video/m9mo.c/h). As far as I can tell this is the driver for the soc actually used in the camera it writes some i2c commands and maintains the state of the hardware. It has a lot of neat functions which are all exposed to the v4l2 subsystem and can be poked via ioctls if you can get a sysfs node to do it on. It seems to me that this thing is a registered as subdevice in v4l2 and subsequently it's set to not expose itself as a sysfs node. Only the main device which I believe is registered by libfimc is exposed in sysfs. Looking back at the m9mo driver it seems like the only way that manual control of the focus motor can be achieved is via a set of methods called factory_af*, particularly I'm looking at set_factory_af, set_factory_af_step, set_factory_af_position. set_factory_af has a lot of options for manually manipulating the focus lock and the focus range and things but I believe most of that functionality is exposed already via Android (with the exception of setting specific scan ranges).
The other two though look more interestin, particularly set_factory_af_position. If you look though the m9mo.h file it seems like the i2c commands it sends are divided into categories, this function sends a function under the CAMERA_LENS category called AUTOFOCUS_ADJUST which to me feels like a way to either relatively or absolutely position the camera motor. I have not tried sending the raw i2c command though it's pretty trivial to figure out what to send based on the driver code. I may try this if I find some time.
Going up a level to fimc (/drivers/media/video/s5p-fimc):
I'm pretty hazy on this but I think that this is the unified camera interface for samsung. This has been explored some by the CM team and so there's knowledge out there about this sub-system I just don't have it lol. Based on my rudimentary understanding of v4l2 this seems like it's registered as the main camera device and then m9mo is registered as a sub device of it. So on my device /dev/video2 and /dev/video3 are registered by libfimc and I can't seem to open /dev/video1 or 0 (the other video devices in the teens are libjpeg stuff).
Going up another level to the android hal type things, libcamera_client.so does contain some very interesting tidbits. This is the module that basically services android calls via android.hardware.camera and it seems to me that if you do objdump -T on it that it actually contains parameter name strings for the super interesting stuff in the m9mo driver. Things like:
000222f7 g DO .rodata 0000000b _ZN7android16CameraParameters26FACTORY_AF_ZONE_AUTO_MACROE
000233ea g DO .rodata 00000006 _ZN7android16CameraParameters21FACTORY_AF_ZONE_MACROE
00022899 g DO .rodata 00000007 _ZN7android16CameraParameters22FACTORY_AF_ZONE_NORMALE
0002298d g DO .rodata 00000006 _ZN7android16CameraParameters20FACTORY_AFLENS_CLOSEE
0002206a g DO .rodata 00000005 _ZN7android16CameraParameters19FACTORY_AFLENS_OPENE
0002283a g DO .rodata 00000002 _ZN7android16CameraParameters28FACTORY_AF_POSITION_POSITIONE
00022737 g DO .rodata 00000002 _ZN7android16CameraParameters24FACTORY_AF_POSITION_NEARE
00022406 g DO .rodata 00000002 _ZN7android16CameraParameters23FACTORY_AF_POSITION_FARE
00022847 g DO .rodata 00000008 _ZN7android16CameraParameters18FACTORY_AF_LED_LOGE
00022603 g DO .rodata 0000000e _ZN7android16CameraParameters24FACTORY_AF_LED_END_CHECKE
00022726 g DO .rodata 0000000a _ZN7android16CameraParameters20FACTORY_AF_STEP_SAVEE
00022eb8 g DO .rodata 00000008 _ZN7android16CameraParameters24FACTORY_AF_INTERRUPT_SETE
000222e5 g DO .rodata 0000000a _ZN7android16CameraParameters20FACTORY_AF_FOCUS_LOGE
000230a8 g DO .rodata 0000000a _ZN7android16CameraParameters20FACTORY_AF_RANGE_LOGE
00022ef1 g DO .rodata 0000000a _ZN7android16CameraParameters20FACTORY_AF_LOCK_STOPE
0002283c g DO .rodata 0000000b _ZN7android16CameraParameters21FACTORY_AF_LOCK_STARTE
00022d2c g DO .rodata 00000009 _ZN7android16CameraParameters19FACTORY_AF_STEP_LOGE
00022bfd g DO .rodata 0000000a _ZN7android16CameraParameters25FACTORY_AF_MOVE_END_CHECKE
00023359 g DO .rodata 00000005 _ZN7android16CameraParameters15FACTORY_AF_MOVEE
00022788 g DO .rodata 00000009 _ZN7android16CameraParameters23FACTORY_AF_LOCK_OFF_SETE
00022f87 g DO .rodata 00000008 _ZN7android16CameraParameters22FACTORY_AF_LOCK_ON_SETE
00022c1f g DO .rodata 00000003 _ZN7android16CameraParameters10AF_LAMP_ONE
00022445 g DO .rodata 00000004 _ZN7android16CameraParameters11AF_LAMP_OFFE
00022214 g DO .rodata 00000016 _ZN7android16CameraParameters25KEY_FACTORY_TILT_AF_RANGEE
00022ca3 g DO .rodata 00000014 _ZN7android16CameraParameters41KEY_FACTORY_DEFECTPIXEL_SET_NLV_DRAFT1_HDE
00023173 g DO .rodata 00000010 _ZN7android16CameraParameters40KEY_FACTORY_DEFECTPIXEL_SET_NLV_DRAFT_HSE
000225e7 g DO .rodata 00000011 _ZN7android16CameraParameters38KEY_FACTORY_DEFECTPIXEL_SET_NLV_DRAFT2E
000220a0 g DO .rodata 00000011 _ZN7android16CameraParameters38KEY_FACTORY_DEFECTPIXEL_SET_NLV_DRAFT1E
000235fc g DO .rodata 00000011 _ZN7android16CameraParameters38KEY_FACTORY_DEFECTPIXEL_SET_NLV_DRAFT0E
0002321c g DO .rodata 00000016 _ZN7android16CameraParameters25KEY_FACTORY_AF_DIFF_CHECKE
00022e07 g DO .rodata 00000013 _ZN7android16CameraParameters23KEY_FACTORY_AF_LED_TIMEE
00022b6b g DO .rodata 00000018 _ZN7android16CameraParameters27KEY_FACTORY_AF_LED_LV_LIMITE
00022bb3 g DO .rodata 00000015 _ZN7android16CameraParameters24KEY_FACTORY_AF_LED_RANGEE
00021f8c g DO .rodata 00000010 _ZN7android16CameraParameters19KEY_FACTORY_AF_ZONEE
000228ac g DO .rodata 0000000f _ZN7android16CameraParameters18KEY_FACTORY_AFLENSE
00022b8e g DO .rodata 00000019 _ZN7android16CameraParameters28KEY_FACTORY_AF_RESOL_CAPTUREE
00022049 g DO .rodata 00000016 _ZN7android16CameraParameters25KEY_FACTORY_AF_SCAN_RANGEE
00023583 g DO .rodata 00000016 _ZN7android16CameraParameters25KEY_FACTORY_AF_SCAN_LIMITE
00021f00 g DO .rodata 0000000f _ZN7android16CameraParameters23KEY_FACTORY_AF_POSITIONE
000226d2 g DO .rodata 00000010 _ZN7android16CameraParameters23KEY_FACTORY_AF_STEP_SETE
000233df g DO .rodata 0000000b _ZN7android16CameraParameters14KEY_FACTORY_AFE
000229ac g DO .rodata 00000008 _ZN7android16CameraParameters11KEY_AF_LAMPE
00022732 g DO .rodata 00000002 _ZN7android16CameraParameters23FACTORY_AF_POSITION_PARE
Going a step further and disasembling in ida or doing a string dump, the key_factory_* blah stuff actually maps to parameter names you can set in CameraParameters:
factory-af-pos
factory-af-zone
factory-af-scan-range
factory-tilt-af-range
factory-af-step
factory-aflens
af-lamp
factory-af-led-lv-limit
factory-af-resol-capture
factory-af-led-range
factory-af-ledtime
factory-af-diff-check
factory-af
factory-af-scan-limit
Unfortunately I tried just doing:
Camera c = Camera.open()
Parameters p = c.getParameters()
p.set("focus-mode", "manual") // This actually works the camera defines a valid autofocus mode of manual and if you look at the kernel logs this does get sent to the driver
p.set("factory-af-pos", 123) // The function in the driver writes a single byte of 0-255 so I imagine this is just a focus step range.
c.setParameters(p)
This appeared to do nothing but it doesn't raise a RuntimeError so that's something. If you try reading (most) of those parameters you just get null out, a few of them actually show up with factory data. My guess is that you probably have to put the camera into a special mode or know the right incantation to get it to respond properly -- even then I'm not sure how it is implemented in the hardware (i.e. it probably wouldn't trigger an AutoFocusMoved callback in Android).
Hope this helps someone, I'm dieing for this functionality

And it continues:
Here are the camera parameters you can set in Camera.Parameters (determined via dumpstrings and a regex to look for anything lowercase with '-'. Interestingly you can't poke the factory ones UNLESS factory-testno is > 0. So I did a quick experiment setting factory-testno to 1 and then poked factory-af-pos. I had hoped that that would let me control the motor, unfortunately it seemed like it just toggled the AF mode from af, macro, infinity or something similar :/ Still searching for a way if I can find out.
aeb-value
af-lamp
alive-off
alive-on
antibanding-values
aperture-capture
aperture-cmd
aperture-preview
auto-exposure-lock
auto-exposure-lock-supported
auto-macro
auto-macro
auto-value
auto-whitebalance-lock
auto-whitebalance-lock-supported
background-blur
back-light
back-light-portrait
barrel-off
barrel-on
barrel-start
barrel-stop
bayer-rggb
beach-snow
best-group-pose
best-mode
blue-sky
burst-mode
burst-shot-save-folder
charge-end
check-off
check-on
close-up
cloudy-daylight
comp-off
comp-on
comp-start
comp-stop
contextualtag-weather
continuous-fps
continuous-mode
continuous-picture
continuous-video
cross-filter
digital-tele-start
digital-wide-start
dl-check
dual-is
dual-off
dual-on
dusk-dawn
eep-write
effect-values
end-check
end-check
end-check
end-check
exposure-compensation
exposure-compensation-step
face-detection
face-detection
face-retouch
factory-adj-iris
factory-ae-target
factory-af
factory-af-diff-check
factory-af-led-lv-limit
factory-af-led-range
factory-af-ledtime
factory-aflens
factory-af-pos
factory-af-resol-capture
factory-af-scan-limit
factory-af-scan-range
factory-af-step
factory-af-zone
factory-backlash
factory-backlash-count
factory-bl-max
factory-cap-ctrl
factory-cap-gain
factory-cap-gain-offset-sign
factory-cap-gain-offset-val
factory-cap-range
factory-common
factory-defocus
factory-dfpx
factory-dfpx-dr0
factory-dfpx-dr1
factory-dfpx-dr1-hd
factory-dfpx-dr2
factory-dfpx-hs
factory-dfpx-nlvcap
factory-df-tele
factory-df-wide
factory-down-result
factory-end-result
factory-fail-stop
factory-flash-chg-chk
factory-flash-cmd
factory-flash-manual-charge
factory-flash-manual-en
factory-flash-range
factory-flicker
factory-fw-ver-isp
factory-fw-ver-ois
factory-fw-ver-result
factory-gain-live
factory-gain-liveview-range
factory-gyro
factory-gyro-range-data
factory-interpolation
factory-ircheck-bgain
factory-ircheck-rgain
factory-iris-range
factory-ldc
factory-liveview-offset-sign
factory-liveview-offset-val
factory-lsc
factory-lsc-ref
factory-lsc-table
factory-lsc-zoom-interrupt
factory-lv-target
factory-mode
factory-nodefocusyes
factory-ois
factory-ois-centering-move-shift-data
factory-ois-range-data
factory-punt
factory-punt-long
factory-punt-range-data
factory-punt-short
factory-resol
factory-rtc-manually-limit
factory-rtc-manually-time
factory-sc
factory-sc-iris-num
factory-sc-iso
factory-sc-range
factory-sc-set-iris
factory-sc-speedtime
factory-shift
factory-shift-x
factory-shift-y
factory-sys-mode
factory-testno
factory-tilt-1time-sciprt-run
factory-tilt-af-range
factory-tilt-diff-range
factory-tilt-field
factory-tilt-scan-limiit
factory-vib
factory-vib-range-data
factory-wb
factory-wb-range
factory-wb-value
factory-zoom
factory-zoom-range-check-data
factory-zoom-slope-check-data
factory-zoom-step
fall-color
fillin-step
firm-dl
flash-charging
flash-low-battery
flash-mode
flash-mode-values
flash-standby
flash-step
flash-value-of-isp
focal-length
focus-area-mode
focus-areas
focus-distances
focus-log
focus-mode
focus-mode-values
focus-range
gps-altitude
gps-latitude
gps-longitude
gps-processing-method
gps-timestamp
h}D-h
h}D-h
h}D-h
h}D-h
h}D-h
h}D-h
h}D-h
h}D-h
h}D-h
h}D-h
h}D-h
h}D-h
h}D-h
h}D-h
h}D-h
high-speed
hold-lens
horizontal-view-angle
image-stabilizer
indoor-end-check
indoor-run
int-set
ircheck-run
jpeg-quality
jpeg-thumbnail-height
jpeg-thumbnail-quality
jpeg-thumbnail-size-values
jpeg-thumbnail-width
led-end-check
led-log
lens-control
light-trail-shot
lock-off
lock-on
lock-start
lock-stop
long-scan-data
long-scan-start
long-scan-stop
low-light-mode
lsc-log
macro-color
macro-text
max-exposure-compensation
max-num-detected-faces-hw
max-num-detected-faces-sw
max-num-focus-areas
max-num-metering-areas
max-thr
max-zoom
metering-areas
min-exposure-compensation
move-step
moving-shot
natural-green
natural-green
night-portrait
object-tracking
optical-scale-zoom
optical-tele-start
optical-wide-start
outdoor-end-check
outdoor-run
picture-format
picture-format-values
picture-size
picture-size-values
point-blue
point-red
point-yellow
preferred-preview-size-for-video
preview-format
preview-format-values
preview-fps-range
preview-fps-range-values
preview-frame-rate
preview-frame-rate-values
preview-size
preview-size-values
range-check-start
range-check-stop
range-log
range-start
range-stop
raw-save
recording-hint
red-eye
red-eye-fix
return-center
scenario-6
scene-mode
scene-mode-values
short-scan-data
short-scan-start
short-scan-stop
shutter-speed
slope-check-start
slope-check-stop
slow-tele-start
slow-wide-start
smart-auto
smart-scene-detection
smart-touch
smooth-zoom-supported
start-filter
step-log
step-save
vertical-view-angle
video-frame-format
video-size
video-size-values
video-snapshot-supported
video-stabilization
video-stabilization-supported
warm-fluorescent
warm-fluorescent
wb-a
wb-b
wbb-value
wb-custom
wb-g
wb-k
wb-m
whitebalance-values
wide-run
widget-mode-level
yuv422i-yuyv
zoom-action
zoom-key-start
zoom-lens-status
zoom-pinch-start
zoom-ratios
zoom-stop
zoom-stop
zoom-supported

luscoma said:
Camera c = Camera.open()
Parameters p = c.getParameters()
p.set("focus-mode", "manual") // This actually works the camera defines a valid autofocus mode of manual and if you look at the kernel logs this does get sent to the driver
p.set("factory-af-pos", 123) // The function in the driver writes a single byte of 0-255 so I imagine this is just a focus step range.
c.setParameters(p)
Hope this helps someone, I'm dieing for this functionality
Click to expand...
Click to collapse
I just now used this code to change the paramaters and my app actually took a picture without having to set factory-testno.
But I actually have no idea how to determine if the camera is doing any manual focusing. How can I do that?
What I'm really looking for is changing aperture and ISO.

beerockxs said:
I just now used this code to change the paramaters and my app actually took a picture without having to set factory-testno.
But I actually have no idea how to determine if the camera is doing any manual focusing. How can I do that?
What I'm really looking for is changing aperture and ISO.
Click to expand...
Click to collapse
Ya it will let you set the parameter but it doesn't do anything unless you have factory-testno set. The only way to check if manual focusing was working would be to take a picture and then another after twiddling the knobs and see if they were at different focal distances.
I think the aperture and ISO will be via an Android API but I didn't look into how.
As a follow up to my previous post, I've dug through the driver code. They just didn't expose the control of the autofocus motor in the driver. The driver is only responsible for telling the SOC was mode to be in and when to trigger its autofocus routine. My gut says there's an i2c command you can send to the soc and have it move but it isn't used in the driver and unless someone mysteriously turns up a datasheet then it isn't likely to be added in by anyone but Samsung.

chroot success: ? about Freedreno drivers

Hey everyone. Hope this is 'dev' enough.
I haven't seen anything anywhere about AT&T note3 chroots, other than AT&T N3 can not because of lack of boot loop. Anyway, I thought i'd mention that it works quite well with partition & Xsdl. I made a small post for the interested in the general forum.
To my question: has anyone tried the freedreno drivers? ~Github link~
I haven't been able to build it properly, it's missing some .o's. I have gcc working on my chroot.
I'm also having problems with pulse/alsa/gstreamer, I think it's a permission problem. The android audio user shows as aid_audio, but the dir /dev/socket/ shows as usr:Media/grp:audio and the socket is system/system. They're recognized as users in the chroot, but they're still unable to find get access to it. I couldn't get an alsa recording app on from playstore to connect to it either.
I'm kinda wondering if something funky with permissions after towelroot. I couldn't get su,chroot, etc to work properly until I got the system to recognize su as 'root' instead of uid:0. Once I got that everything for su started working? So, lost and confused. Ideas on what i'm doing wrong?
thanks!

I was able to build a kernel with DRM and KGSL DRM interface enabled, boot CM11 with it, open SSH in my Debian chroot, kill Android, and then attempt to run Xorg with the freedreno driver but I ended up getting a memory mapping error and a segfault.
The Note 3's panel is a command-mode DSI panel which means it will not automatically display what is written to /dev/graphics/fb0 like you would expect. Instead, you must call an ioctl (FBIOPAN_DISPLAY) to force a refresh of the display. The panel must be on for this to work. I'm not sure the exact sequence required to turn on the display but it involves opening /dev/graphics/fb0 and possibly mmap'ing it. If you use the fbdev Xorg driver it will turn on the panel, but you must then run a program to continuously send the FBIOPAN_DISPLAY ioctl to refresh it. This is non-accelerated and also seems to crash any GTK apps (only X11 basic apps like xterm worked, and even then the refreshing was glitchy).
I'm trying to tackle kexec-hardboot first because that will allow booting an entirely-Debian-focused kernel with the correct color mode and the DRM drivers and all. It will likely require some patches to the KGSL GPU code in the kernel, at least it did on my Note 1. Get on #freedreno on Freenode if you aren't already there, lots of knowledgeable people there to analyze logs and find patches. I got it working on my HP TouchPad and Note i717 with help from there.

Very nice, thanks!
I've only gotten fb to work on my nexus5.
Also thanks for the heads up on the freenode. Going to check it out.
Have you messed with sound at all?
Edit:
Wait, did you do this on a 900A? (I'm probably way behind times?)

N900T, so bootloader-unlocked. It will be doubly hard to do on the N900A since you'll have to compile as modules rather than just compile your own kernel, at least unless you guys get kexec (non-hardboot) working on the locked variants. You should be able to mess around with the framebuffer on the stock kernel just fine though, only the freedreno driver needs custom kernel changes.
I haven't messed around with sound at all. On my HP TouchPad I figured out how to use ALSA UCM files which set up the mixer controls. By default Android locks the sound devices so using them from a chroot while Android is running probably won't happen, but with Android out of the way you may be able to use them. I do know on the Note 1 and the HP TouchPad you have to load q6.xxx firmware files for the audio system to initialize during boot.
This file will be of interest when writing ALSA UCM files:
https://github.com/CyanogenMod/android_device_samsung_hlte-common/blob/cm-11.0/audio/mixer_paths.xml
I used the TouchPad's mixer_paths.xml file to write two UCM "verbs" - one to turn on internal speakers and one to turn on headphones. The UCM file basically sets the given switches to the given values and is basically just a reformatting of mixer_paths.xml. I was unable to find a mixer_paths.xml for the Note 1 and thus haven't messed with sound on it yet (it has to exist somewhere...).

CalcProgrammer1 said:
N900T, so bootloader-unlocked. It will be doubly hard to do on the N900A since you'll have to compile as modules rather than just compile your own kernel, at least unless you guys get kexec (non-hardboot) working on the locked variants. You should be able to mess around with the framebuffer on the stock kernel just fine though, only the freedreno driver needs custom kernel changes.
I haven't messed around with sound at all. On my HP TouchPad I figured out how to use ALSA UCM files which set up the mixer controls. By default Android locks the sound devices so using them from a chroot while Android is running probably won't happen, but with Android out of the way you may be able to use them. I do know on the Note 1 and the HP TouchPad you have to load q6.xxx firmware files for the audio system to initialize during boot.
This file will be of interest when writing ALSA UCM files:
https://github.com/CyanogenMod/android_device_samsung_hlte-common/blob/cm-11.0/audio/mixer_paths.xml
I used the TouchPad's mixer_paths.xml file to write two UCM "verbs" - one to turn on internal speakers and one to turn on headphones. The UCM file basically sets the given switches to the given values and is basically just a reformatting of mixer_paths.xml. I was unable to find a mixer_paths.xml for the Note 1 and thus haven't messed with sound on it yet (it has to exist somewhere...).
Click to expand...
Click to collapse
Great thanks! That explains a few things with the boot lock. FB has been a total no go for me. I read something about the type of display not working with it? I have no idea if that's true, and can't seem to find that information right now. (it worked great on the my note2). If someone has gotten success let me know! I'll check out the UCM once more. I did get ALSA working with debian on the note 1, so that's the first thing I tried. My Touchpad, I thought, worked right out of the box. (I miss that thing!)
I'll give it shot tonight and see what I get. thanks a lot to both of you.

The Note 3's panel is a command mode panel while the Note 1's panel is video mode. I'm not sure about the Note 2 as I don't have one but if it worked for you it was likely video mode as well. In video mode it works like you'd expect any display to work - the framebuffer memory is automatically drawn to the screen at a fixed refresh rate (60Hz). A command mode panel is different, the framebuffer is only drawn to the display when it is commanded to, and thus the software has control over the refresh rate of the display. I did a test where I found the section of code in the Note 3's kernel where it does the software refresh and stuck a printk in there. I had the kmsg printing out over SSH while I swiped the screen around in Android. Sure enough, the printout only happened when I moved my finger and caused the framebuffer to update, the screen completely stopped refreshing otherwise.
I'm still trying to find a good solution to this, especially in regards to running kexec-hardboot and the kexecboot bootloader GUI. I've been able to get kexecboot to display by sticking an FBIOPAN_DISPLAY ioctl into the framebuffer sync function that kexecboot calls after it updates the screen. This ioctl seems to force the display to refresh, but only if certain conditions are met (and I'm unsure what all these conditions are). I do know that the LCD (actually AMOLED but it's listed as LCD panel in the code) must be powered on, the framebuffer must be open (i.e. call the open() function to /dev/graphics/fb0 and get a file descriptor), and possibly memory-mapped as well (the code I was using as a software refresher had mmap, though it might not be necessary). This is another thing to go to #freedreno for, a user there (crondog) has been working on Freedreno on the 2013 Nexus 7 which also has a command mode panel and he's done some software refresher work.

[ROM] [OFFICIAL/UNOFFICIAL] Cyanogenmod 13.0 for Shield Portable

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
CyanogenMod is a free, community built, aftermarket firmware distribution of Android 6.0.x (Marshmallow), which is designed to increase performance and reliability over stock Android for your device.
Code:
/*
* Your warranty is now void.
*
* We are not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at us for messing up your device, we will laugh at you.
*
*/
CyanogenMod is based on the Android Open Source Project with extra contributions from many people within the Android community. It can be used without any need to have any Google application installed. You will need to provide your own Google Applications package (gapps). CyanogenMod does still include various hardware-specific code, which is also slowly being open-sourced anyway.
All the source code for CyanogenMod is available in the CyanogenMod Github Repo. And if you would like to contribute to CyanogenMod, please visit our Gerrit Code Review. Your changelog is whatever was merged into gerrit.
Instructions:
1. First time flashing CyanogenMod 13.0 your device, or coming from another ROM?
2. Download the zip(s).
3. Install a compatible Recovery
4. Perform a NANDroid backup of your current ROM (Optional)
5. Wipe data & cache partitions of your device
6. Flash CyanogenMod.
7. Optional: Install the Google Apps addon package.
Firmware Update:
If you have not installed the latest stock ota, then some firmware files need updated. The following flashable zips will update the bootloader and the dtb corresponding with the listed stock version. Only the latest one listed here will be supported by recent CM builds.
106
Official Nightly Downloads:
get.cm
GAPPS
Unofficial Downloads with Nvidia App Support (CM 12.1):
20151003
Bugreport:
Report in this thread. CM's JIRA is only for stable builds, which I have not released.
Known Problems:
Only the power button seems to wake the device.
Wireless controller doesn't work.
Source Code:
https://github.com/CM-Shield/android_device_nvidia_roth
https://github.com/CM-Shield/android_kernel_nvidia_roth
XDA:DevDB Information
CM13.0 Unofficial Roth, ROM for the Nvidia Shield
Contributors
Steel01, Unjustified Dev
ROM OS Version: 6.0.x Marshmallow
ROM Kernel: Linux 3.4.x
Based On: CyanogenMod
Version Information
Status: Nightly
Created 2015-02-28
Last Updated 2016-03-15

sweet - since I'm not using most of the quicksettings on the stock shield I can finally get rid of most of them without installing xposed and gravity box...
but right now its missing the buttons-menu in the settings - so you cant configure the power menu or any of that stuff.
still, the bootup time is amazing on this thing compared to stock...

Sweet! Does this have the stuff I sent to @Unjustified Dev? (Setting volume button as volume down)

r3pwn said:
Sweet! Does this have the stuff I sent to @Unjustified Dev? (Setting volume button as volume down)
Click to expand...
Click to collapse
No, this build does nothing with the volume button. What I'd like to see it do is bring up the volume widget without changing the volume which would be as similar to stock as I can figure, but I don't see a way to do that. You can change that pretty easily locally, if you want that on your install.
@Spleeno: I expect that has to do with upstream cm. I didn't turn off any settins and I don't think Unjustified Dev did either. I know upstream was still working on forward porting all of 11's features last I looked. I don't know where they're at on that now.

Also, if it helps at all, it's possible to disable the LED by running (as root) "echo 0 > /sys/class/leds/roth-led/brightness". (This was a setting on stock, not sure if you guys want to re-add it in.)
Steel01 said:
No, this build does nothing with the volume button. What I'd like to see it do is bring up the volume widget without changing the volume which would be as similar to stock as I can figure, but I don't see a way to do that. You can change that pretty easily locally, if you want that on your install
Click to expand...
Click to collapse
I had mine set to Volume down for a couple reasons:
1. When tapped once, it would pull up the volume menu (and lower volume by one step, but not a huge issue)
2. When held with the power button, it takes a screenshot (that's what happened on stock, too)
3. Holding it down mutes it, if for some reason you needed to quickly mute the device.

r3pwn said:
Also, if it helps at all, it's possible to disable the LED by running (as root) "echo 0 > /sys/class/leds/roth-led/brightness". (This was a setting on stock, not sure if you guys want to re-add it in.)
I had mine set to Volume down for a couple reasons:
1. When tapped once, it would pull up the volume menu (and lower volume by one step, but not a huge issue)
2. When held with the power button, it takes a screenshot (that's what happened on stock, too)
3. Holding it down mutes it, if for some reason you needed to quickly mute the device.
Click to expand...
Click to collapse
For the first, I'd want to leave that to user choice. Wonder how hard it would be to add that to the settings section. Can you even add setting pages from the device tree without modifying upstream?
On the second, you might have me convinced there. I'll change it on mine next time I'm poking at it. And will probably change it in the tree unless something weird pops out.
There's several more things I want to look at porting over. Console mode looks to be really easy. At least in basic form. There's a couple props to force hdmi only and resolution. Only problem is if the cable is unplugged, it wont automatically switch back over. The wireless controller is another, but more difficult. I got the apps to run, but they errored out. I have a couple more ideas to try, but haven't got there yet. Took a break over the weekend, but should be back at it tomorrow night.

Steel01 said:
For the first, I'd want to leave that to user choice. Wonder how hard it would be to add that to the settings section. Can you even add setting pages from the device tree without modifying upstream?
Click to expand...
Click to collapse
I'm not sure. I'll have to take a look. Anything is possible with overlays, though, right?
Absolute worst case scenario, I'll make an app with a few misc. things like this to gain some functionality back from stock.
And while we're in the spirit of discussing rom-related components, I have a bug report: Attempting to use Nvidia's GRID Streaming service results in only the audio going through. (Not sure if that affects PC streaming, as my PC is nowhere near powerful enough to test)
And also,
There seems to be some weird issue with storage. Either apps aren't getting moved to the sdcard when told or the system is factoring them into the internal storage space calculation anyways. (I'll get back to you on this one, it isn't too hard to test to figure it out.)
Steel01 said:
Took a break over the weekend, but should be back at it tomorrow night.
Click to expand...
Click to collapse
Alright. No rush, take as long of a break as you need!

Steel01 said:
I expect that has to do with upstream cm. I didn't turn off any settins and I don't think Unjustified Dev did either. I know upstream was still working on forward porting all of 11's features last I looked. I don't know where they're at on that now.
Click to expand...
Click to collapse
Hm, I'm running the 20150223 cm12 nightly on my z3 compact and it already has the button menu - I wouldnt have expected/noticed with some of the early january builds ofc

So I started a proper post with quotes and all, but the android keyboard or textbox edit thing in Firefox did something weird and ate my post. And there's no undo... So this is my shorter and more miffed second attempt.
@Spleeno: My bad, I see that on my Nexus 5 now. I'll compare my dev tree with the N5's and see what the difference in that area is.
@r3pwn: On the Grid issue: I confirmed that this morning, but didn't have much time to look at the logs. I saw something about missing codecs, but that was at the top and maybe not related. I'll look more into it tonight. It could well be a worse underlying problem.

@Steel01 man thanks so much for your initiative, i'm happy to see a custom rom o my shield and its working great, i have tested with retroarch nightly and ppsspp nightly and its working awesome.
if its possible until you define the function to volume button i think you can change from program_red to button_select to at least we can use on the emulators
another thing i have noticed the volume button on original shield rom is 109 on you rom is 183
thanks for your time and thanks so much for the custom rom!
update:
other things i have noticed
when we make a fresh installation the shield don't have the mtp option checked
we have a vibration option on sound menu (i dont know if this make some erros on system if enable/disable)
if the kernel have the option Prism from nvidia its possible to put on display using the adaptive brightness ( /sys/class/graphics/fb0/device/smartdimmer/enable)
thanks again

I looked at the sdcard issue. It appears that only the app is getting transferred over,not any obbs that belong to the app. You can move those manually, but that's not very user-friendly.

Okay, I've been chasing this grid problem around most of the night... Finally got a lead when I gave up and started trying to mess with the controller stuff again. Apparently the Grid service want to use stuff from the main Nvidia control service. Which is embedded in the stock build and not open source. I was able to pull the apks (NvCPLSvc and the controller related NvBlakeManager and BlakePairing) from my Shield Tablet (already on lollipop), resign them with CM's keys and get them to run. Once NvCPLSvc was happy, the logs related to Grid stuff look a lot more similar to what I get on my stock tablet, but still no dice. It's getting stuck in the queue. Dunno if I'll make any more progress on that tonight or not, but I'm a lot closer.
On the controller front, at least it's more obvious what the problem is. Nvidia modified the wireless p2p stuff in the android framework. Some functions that blake calls don't exist in CM and causes the service to bomb. I'm playing with a diff between the aosp tree and CM. Should be able to get get a sane one tonight and run off a build to see how much further I can get. Then the question will be if I can magically add the changes to the device tree or if they would have to be submitted to upstream CM or Google which isn't likely to get merged.
@YamazakiRobert:
The mtp part could be due to some testing we were doing and trying to get adb up when cm wasn't booting. I'll check when I'm working on the device tree again.
I doubt turning on vibrate would damage anything since there isn't any hardware for it. But I agree the option shouldn't be there. More things to add to the device tree list.
That smartdimmer path is there on this build and is enabled by default. Though, I haven't seen any effects like adaptive brightness. That feature drives me nuts and is one of the first things I turn off on a phone reinstall... But, I'll look into enabling auto brightness in CM. Should be able to find that in the N5 tree as well.
@r3pwn:
Creating a open source control app would probably be the easiest way to go. Control things like the leds, console mode, etc. If someone could figure out what blake is actually doing under the hood, it would be nice to get away from those stock programs as well. But I didn't have a whole lot of luck with deciphering that a few weeks ago. But it's looking like NvCPLSvc will have to stick around if people want Grid access, which is unfortunate.
The transfer problem sounds like an upstream issue or even on-purpose decision. Does this work on other CM ports?
Edit: Ugh. The wifi framework stuff appears to have been refactored between 4.4 and 5.0. Got the patch cleaned up and applied and stuff overlaps and isn't found and all kinds of fun. I probably should have pulled all this from the tablet aosp. Guess I'll try that angle tomorrow.

Thank you for this majestic piece of work.
I'm going to build a shrine with your username when you'll make a working CM12 with GRID.

Steel01 said:
@r3pwn:
Creating a open source control app would probably be the easiest way to go. Control things like the leds, console mode, etc. If someone could figure out what blake is actually doing under the hood, it would be nice to get away from those stock programs as well. But I didn't have a whole lot of luck with deciphering that a few weeks ago. But it's looking like NvCPLSvc will have to stick around if people want Grid access, which is unfortunate.
The transfer problem sounds like an upstream issue or even on-purpose decision. Does this work on other CM ports?
Edit: Ugh. The wifi framework stuff appears to have been refactored between 4.4 and 5.0. Got the patch cleaned up and applied and stuff overlaps and isn't found and all kinds of fun. I probably should have pulled all this from the tablet aosp. Guess I'll try that angle tomorrow.
Click to expand...
Click to collapse
I can get right on making the app to control the LED, just as soon as I get back to my shield. Ah, who cares, I can start on it now! Also, glad to see you're making progress with GRID and the controller. I'll check out the storage thing on my G3 to see if it's a CM thing or something else.

So, the wifi framework stuff for the controller is taking more work than I bargained for. The changes needed are not in the tablet aosp tree at all, so I can't base from there. Makes me think they got put in the portables tree by accident. Somewhat of a break, it seems. But stuff is all in the wrong directories when trying to pull it into lollipop. It doesn't help that I'm mostly shooting blind and reacting to compiler errors. I think I'm starting to get a picture of what's going on, though. I'm probably going to have to start over at least one more time, but it's starting to look like it might be a small patch after all. I just need to find where all the files are really supposed to go...
Edit:
Got it to compile with only a few file changes (and I think only three lines in one file matter), but blake still errors out. Saying it can't find a different virtual function that should be right where it says it's looking for it. Somewhat confused atm. Doing a full clean and recompile just to make sure something didn't get way confused as I was tweaking and compiling. I'll see what that looks like tomorrow.

Does anyone around here have the first clue about smali? Given the following snippets from a decompiled BlakeManager:
Code:
.line 498
invoke-virtual {v1}, Landroid/net/wifi/p2p/WifiP2pGroup;->getNetworkId()I
move-result v0
*snip*
iget-object v5, p0, Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi$6;->this$0:Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi;
# getter for: Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi;->mWifiP2pMgr:Landroid/net/wifi/p2p/WifiP2pManager;
invoke-static {v5}, Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi;->access$500(Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi;)Landroid/net/wifi/p2p/WifiP2pManager;
move-result-object v5
iget-object v6, p0, Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi$6;->this$0:Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi;
# getter for: Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi;->mChannel:Landroid/net/wifi/p2p/WifiP2pManager$Channel;
invoke-static {v6}, Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi;->access$400(Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi;)Landroid/net/wifi/p2p/WifiP2pManager$Channel;
move-result-object v6
new-instance v7, Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi$6$1;
invoke-direct {v7, p0}, Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi$6$1;-><init>(Lcom/nvidia/blakemanager/connectivity/BlakePairManagerMainWifi$6;)V
invoke-virtual {v5, v6, v0, v7}, Landroid/net/wifi/p2p/WifiP2pManager;->createGroup(Landroid/net/wifi/p2p/WifiP2pManager$Channel;ILandroid/net/wifi/p2p/WifiP2pManager$ActionListener;)V
I am totally confused about the last line. The function createGroup is declared as "public void createGroup(Channel c, ActionListener listener)" in mainline Android and the Shield Portable tree. Which matches the longhand call there. However, the function is being passed 4 parameters. Afaik, that should only be three. One for the 'this' pointer and two for the parameters. What is it doing with that fourth parameter (as I read, v0 is the extra)?
Other info. The logcat error I'm getting is:
Code:
--------- beginning of crash
E/AndroidRuntime( 1236): FATAL EXCEPTION: main
E/AndroidRuntime( 1236): Process: com.nvidia.blakemanager, PID: 1236
E/AndroidRuntime( 1236): java.lang.NoSuchMethodError: No virtual method createGroup(Landroid/net/wifi/p2p/WifiP2pManager$Channel;ILandroid/net/wifi/p2p/WifiP2pManager$ActionListener;)V in class Landroid/net/wifi/p2p/WifiP2pManager; or its super classes (declaration of 'android.net.wifi.p2p.WifiP2pManager' appears in /system/framework/framework.jar)
E/AndroidRuntime( 1236): at com.nvidia.blakemanager.connectivity.BlakePairManagerMainWifi$6.onPersistentGroupInfoAvailable(BlakePairManagerMainWifi.java:505)
E/AndroidRuntime( 1236): at android.net.wifi.p2p.WifiP2pManager$Channel$P2pHandler.handleMessage(WifiP2pManager.java:776)
E/AndroidRuntime( 1236): at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime( 1236): at android.os.Looper.loop(Looper.java:135)
E/AndroidRuntime( 1236): at android.app.ActivityThread.main(ActivityThread.java:5256)
E/AndroidRuntime( 1236): at java.lang.reflect.Method.invoke(Native Method)
E/AndroidRuntime( 1236): at java.lang.reflect.Method.invoke(Method.java:372)
E/AndroidRuntime( 1236): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:898)
E/AndroidRuntime( 1236): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:693)
That virtual method is there in my build and the line in framework.jar/classes.dex matches byte for byte the line from the Shield Tablet's framework. Also, decompiling the Portables BlakeManager shows a way different application, though the call to createGroup only passes 3 parameters. I tried tweaking the smali file to remove v0 and reassembling, but that failed some art verification when I tried copy it over. Even after clearing the cache and a full factory reset. Like so:
Code:
I/art ( 1364): Verification error in void com.nvidia.blakemanager.connectivity.BlakePairManagerMainWifi$6.onPersistentGroupInfoAvailable(android.net.wifi.p2p.WifiP2pGroupList)
I/art ( 1364): couldn't find method android.net.wifi.p2p.WifiP2pManager.createGroup (Landroid/net/wifi/p2p/WifiP2pManager$Channel;ILandroid/net/wifi/p2p/WifiP2pManager$ActionListener;)V
I/art ( 1364): void com.nvidia.blakemanager.connectivity.BlakePairManagerMainWifi$6.onPersistentGroupInfoAvailable(android.net.wifi.p2p.WifiP2pGroupList) failed to verify: register v7 has type Precise Reference: com.nvidia.blakemanager.connectivity.BlakePairManagerMainWifi$6$1 but expected Integer2pGroupList): [0x56]
E/art ( 1364): Verification failed on class com.nvidia.blakemanager.connectivity.BlakePairManagerMainWifi$6 in /system/app/NvBlakeManager.apk because: Verifier rejected class com.nvidia.blakemanager.connectivity.BlakePairManagerMainWifi$6 due to bad method void com.nvidia.blakemanager.connectivity.BlakePairManagerMainWifi$6.onPersistentGroupInfoAvailable(android.net.wifi.p2p.WifiP2pGroupList)
E/JavaBinder( 1364): *** Uncaught remote exception! (Exceptions are not yet supported across processes.)
What is it verifying against? The function declaration doesn't have that parameter... I'm beginning to think I'm out of my league unless someone can give me a crash course in low level Android programming. I mean, I can hazard an educated guess as to what that parameter (result of getNetworkId()) does (instead of WifiP2pGroup.PERSISTENT_NET_ID in createGroup, use that), but that would change the declaration. I even tried overloading the function. So confused...
Edit:
Scratch all of that. I botched the overload first time through. Got the overload in correctly and now it's happier. WifiP2P stuff isn't activating correctly, though. Don't know if that's due to their changes to hostapd and wpa_supplicant or if I'm missing more framework stuff.
I'm thinking of throwing together another build to release tomorrow along with a flashable zip of of the Nvidia stuff. That way if anyone else wants to tinker with it, they can. More eyes do make this stuff easier.

I don't like triple posting, but I still want to trigger new post alerts...
Okay, new build is up here: cm-12-20150305-UNOFFICIAL-roth.zip. That includes everything I've done to date. Attached are the two patches I don't have on github. They apply in cm12 to frameworks/base and frameworks/opt/net/wifi respectively. Also attached is a flashable zip of the Nvidia system apps pulled from my tablet (which can be obtained by anyone from Nvidia's ota zips). These are unmodified outside of resigning them with CM's key to allow them to run as system. The command I used is below for reproducibility. Neither Grid or the controller pairing works correctly yet, but nothing outright crashes either. If someone has any ideas from the logs or wherever about what's missing now, I'd appreciate suggestions.
Code:
java -jar /path/to/cm12/out/host/linux-x86/framework/signapk.jar /path/to/cm12/build/target/product/security/platform.x509.pem /path/to/cm12/build/target/product/security/platform.pk8 old.apk new.apk
Changes and known problems:
The volume button is now mapped to volume_down.
If 'Google Play Movies and TV' is updated, it starts FCing on the next reboot. I haven't tried to track down the problem yet. I just removed it.
Edit:
Well, blast... This is going to be much more of a pain than I thought. Good news: I got the wireless controller to connect. Bad news: I had to copy wpa_supplicant and hostapd over from my tablet. This code, I don't see anywhere... I've reuploaded the flashable zip with these files. I do not like this as a long term solution. Not at all.
Edit 2:
So, it connects, but won't reconnect and old pairings aren't saving correctly. Think I have a fix for it, but I'm having to recompile. This works, but after the 2 minute timeout, you have to reboot and re-pair.
Edit 3: Or worse... It just disconnects period after 2 minutes. Hoping my change in the rebuild changes this.
Edit 4: And no dice. It dies after two minutes with a few comments in the log. Any time a button is pressed, it spits a bunch of stuff about not being able to open the audio device. Probably trying to make the button sound through the headphone jack while that isn't completely initialized. More research to do later, but I think I'm done for the night.

Steel01 said:
I don't like triple posting, but I still want to trigger new post alerts...
Click to expand...
Click to collapse
Instead of using baksmali, why not use jadx (decompiles from apk straight to java and is interactive too)?
Sorry for the short (and only potentially helpful) reply to such a massive wall of text, but it's about midnight here and I need some sleep.
Also, I'm guessing your "nvservices.zip" file isn't supposed to be 5 bytes.

r3pwn said:
Instead of using baksmali, why not use jadx (decompiles from apk straight to java and is interactive too)?
Sorry for the short (and only potentially helpful) reply to such a massive wall of text, but it's about midnight here and I need some sleep.
Also, I'm guessing your "nvservices.zip" file isn't supposed to be 5 bytes.
Click to expand...
Click to collapse
I tried several tools to get there... Apktool being the one that got me the smali. Thanks for the reference, I'll look it up tomorrow. It's late here too. And the zip is 2.8 MB on this side. Just downloaded and it opened fine. Dunno what happened on your side.

Steel01 said:
I tried several tools to get there... Apktool being the one that got me the smali. Thanks for the reference, I'll look it up tomorrow. It's late here too. And the zip is 2.8 MB on this side. Just downloaded and it opened fine. Dunno what happened on your side.
Click to expand...
Click to collapse
Oh. I guess it was Tapatalk being stupid.

Android N and new SELinux configuration.

First of all, I don't have a Nexus 5, but I have a Galaxy Tab Pro 8.4 with the same SoC and I think the N5 has the same issues with the new SELinux policy.
I'm having issues building Android 7.0 because of this SELinux rule: allow mediaserver system_file:file execmod;
Which is also needed on the N5.
Code:
# Grant access to Qualcomm MSM Interface (QMI) audio sockets to mediaserver
qmux_socket(mediaserver)
unix_socket_send(mediaserver, camera, camera)
unix_socket_send(mediaserver, mpdecision, mpdecision)
# Permit mediaserver to create sockets with no specific SELinux class.
# TODO: Investigate the specific type of socket.
allow mediaserver self:socket create_socket_perms;
[B]# For text relocations in /system/vendor/lib/libmmjpeg.so
allow mediaserver system_file:file execmod;[/B]
https://github.com/CyanogenMod/andr.../blob/staging/cm-14.0/sepolicy/mediaserver.te
When I try to build with it uncommented I get a neverallow error. The same rule is applied to other modules, so if I comment it out I can successfully build and boot, but many things don't work.
I don't know much about SELinux and I haven't found a way to bypass this rule without disabling SELinux. Maybe in this subforum someone can help me since there are already Nougat ROMs for the N5.
Thanks.

The sepolicy in bold was for text relocation as it commented. Bionic linker in Nougat has disallowed this feature, that's, all libraries must contain no text relocation section. So it was officially deprecated even in CM codes.
If you just want to bypass the build error, comment out disallow policy in externel/sepolicy to fix up the conflicts. But if you're wondering to get libmmjpeg.so working, go allow text relocation in bionic or find out the proper prebuilts (see bullhead).
BTW, This library is just for jpeg deconding/encoding. And of course it's not related to 'many things'.

how does xposed modify/affect ART?

Hi people,
I was wondering which parts of ART and what optimizations does Xposed disable. I read from one of @rovo89 GitHub that he needed to disable a couple of optimizations. Do these changes affect performance? If so, how can I make performance better?
Cheers!
-LLJY

It mostly disables method inlining and call sharpening. The latter would usually detect that a call to "myObject.toString()" will always resolve to one particular implementation, so ART would create a call directly to the native address of the compiled method. Both of these make it impossible to hook a method, as ART simply wouldn't look up the method anymore. I don't see a way to avoid this.

Little insight to demonstrate this. Consider this Java code:
Code:
package de.robv.android.xposed.smallapp;
public class MyClass {
private static int sMyField = 999;
public static int returnConstant() {
return 1234;
}
public static void main() {
sMyField = returnConstant();
}
}
This is the Dex code for the main() method:
Code:
0x0000: 7100 0700 0000 | invoke-static {}, int de.robv.android.xposed.smallapp.MyClass.returnConstant() // [email protected]
0x0003: 0a00 | move-result v0
0x0004: 6700 0600 | sput v0, I de.robv.android.xposed.smallapp.MyClass.sMyField // [email protected]
0x0006: 0e00 | return-void
And here is what ART (on Nougat / x86) compiles it to:
Code:
0x00001054: 83EC0C sub esp, 12
0x00001057: 890424 mov [esp], eax
0x0000105a: 8B08 mov ecx, [eax]
0x0000105c: C781B0010000D2040000 mov [ecx + 432], 1234
0x00001066: 83C40C add esp, 12
0x00001069: C3 ret
As you can see, the call to returnConstant() is gone. The value it would always return has been inlined. Granted, this is a very simple example, but this can happen for more complex methods as well. It's incremental, so if returnConstant() returned the result of "square(9)" and that square() function returned "x*x", then it would remove all of those calls and insert the precalculated value 81 in the native code.
Now if a module hooks returnConstant(), that hook would never be called, because, well, the method isn't called either. This behavior would depend on many factors (e.g. compiler filter settings in the ROM), so module developers couldn't even rely on the assumption that the hook isn't called. It would be virtually random.
To avoid this (and also a few similar simplifications), the Xposed fork of ART disables these optimizations and recompiles all the odex/oat files. I actually have no idea how big the performance impact is, but it's necessary. It can't even be selective, as it's not known at compile time which methods will be hooked. This optimization can't be reverted when a method is hooked (e.g. by recompiling that method), because it would mean that all the calling methods would have to be recompiled, which would require a list of all callers of that method (or at least those that have inlined it).
I'm not sure about Nougat yet. It has a JIT compiler (Marshmallow had one, too, but it was disabled because it wasn't stable yet), maybe that brings some new opportunities. But that's still a long way, first hooking has to work at all.

rovo89 said:
Little insight to demonstrate this. Consider this Java code:
This is the Dex code for the main() method:
And here is what ART (on Nougat / x86) compiles it to:
As you can see, the call to returnConstant() is gone. The value it would always return has been inlined.
some new opportunities. But that's still a long way, first hooking has to work at all.
Click to expand...
Click to collapse
Thank you for the response, I would just like to report that xposed adds a substantial amount of overhead compared to normal ART. Especially noticeable when ART is set to optimize everything.
Before flashing xposed, my phone running my own custom rom is noticeably faster compared to the iPhone 7. After flashing xposed, it lags behind quite abit.
I did loads of testing to come to this conclusion.
Just some feedback for you

_LLJY said:
I did loads of testing to come to this conclusion.
Click to expand...
Click to collapse
Did you also do real benchmarks? Most of the time when people talk about performance, they say it "feels" slower, but that's hard to investigate...
Also, modules might of course add overhead as well. What I mentioned above just refers to the framework itself.

rovo89 said:
Did you also do real benchmarks? Most of the time when people talk about performance, they say it "feels" slower, but that's hard to investigate...
Also, modules might of course add overhead as well. What I mentioned above just refers to the framework itself.
Click to expand...
Click to collapse
I tested Xposed on 3 devices, 2 ARMV7 and one ARM64. The Redmi note 4g(snapdragon 400) doesn't seem to be affected much at all. The Xperia Z5 (810) seems to slow down noticeably(I tested against a brand new Z5 with the same Rom) the Xiaomi mi3(800) does also get affected slightly although i haven't compared it against another new device. I will conduct a more scientific test where I actually time the devices using discomark to see how they do and put the results in a spreadsheet.

rovo89 said:
Did you also do real benchmarks? Most of the time when people talk about performance, they say it "feels" slower, but that's hard to investigate...
Also, modules might of course add overhead as well. What I mentioned above just refers to the framework itself.
Click to expand...
Click to collapse
on 6.0.1(nexus 5x) i don`t see any diference with or without xposed but seems on nougat will be a little complicate with the art modifications ! btw @rovo89 the xposed can be your phD theme (this is research)

Xposed sdk 23 v 86 does not work with cm 13 for i 9515 with newest kernel 3.4.113 anymore. Hope there will still be updates for xposed sdk 23????
Quote:
Originally Posted by friscoboi @sombree 20161115 got me stuck in a bootloop so far. I did everything as always with updates? Or does it take more than 30 minutes to reboot with the new kernel the first time?
It's because you're using xposed. And no, I'm not going to rebuild ROM with one of those unofficial fixes - you'll have to wait for fixed xposed
(Sorry to post here, but the older xposed thread is closed...)

rovo89 said:
Little insight to demonstrate this. Consider this Java code:
Code:
package de.robv.android.xposed.smallapp;
public class MyClass {
private static int sMyField = 999;
public static int returnConstant() {
return 1234;
}
public static void main() {
sMyField = returnConstant();
}
}
This is the Dex code for the main() method:
Code:
0x0000: 7100 0700 0000 | invoke-static {}, int de.robv.android.xposed.smallapp.MyClass.returnConstant() // [email protected]
0x0003: 0a00 | move-result v0
0x0004: 6700 0600 | sput v0, I de.robv.android.xposed.smallapp.MyClass.sMyField // [email protected]
0x0006: 0e00 | return-void
And here is what ART (on Nougat / x86) compiles it to:
Code:
0x00001054: 83EC0C sub esp, 12
0x00001057: 890424 mov [esp], eax
0x0000105a: 8B08 mov ecx, [eax]
0x0000105c: C781B0010000D2040000 mov [ecx + 432], 1234
0x00001066: 83C40C add esp, 12
0x00001069: C3 ret
As you can see, the call to returnConstant() is gone. The value it would always return has been inlined. Granted, this is a very simple example, but this can happen for more complex methods as well. It's incremental, so if returnConstant() returned the result of "square(9)" and that square() function returned "x*x", then it would remove all of those calls and insert the precalculated value 81 in the native code.
Now if a module hooks returnConstant(), that hook would never be called, because, well, the method isn't called either. This behavior would depend on many factors (e.g. compiler filter settings in the ROM), so module developers couldn't even rely on the assumption that the hook isn't called. It would be virtually random.
To avoid this (and also a few similar simplifications), the Xposed fork of ART disables these optimizations and recompiles all the odex/oat files. I actually have no idea how big the performance impact is, but it's necessary. It can't even be selective, as it's not known at compile time which methods will be hooked. This optimization can't be reverted when a method is hooked (e.g. by recompiling that method), because it would mean that all the calling methods would have to be recompiled, which would require a list of all callers of that method (or at least those that have inlined it).
I'm not sure about Nougat yet. It has a JIT compiler (Marshmallow had one, too, but it was disabled because it wasn't stable yet), maybe that brings some new opportunities. But that's still a long way, first hooking has to work at all.
Click to expand...
Click to collapse
Dalvik VM also uses JIT compiler
Sent from my GT-S7580 using Tapatalk

DodoGTA said:
This is the Dex code for the main() method:
And here is what ART (on Nougat / x86) compiles it to:
As you can see, the call to returnConstant() is gone. The value it would always return has been inlined. Granted, this is a very simple example, but this can happen for more complex methods as well. It's incremental, so if returnConstant() returned the result of "square(9)" and that square() function returned "x*x", then it would remove all of those calls and insert the precalculated value 81 in the native code.
Now if a module hooks returnConstant(), that hook would never be called, because, well, the method isn't called either. This behavior would depend on many factors (e.g. compiler filter settings in the ROM), so module developers couldn't even rely on the assumption that the hook isn't called. It would be virtually random.
To avoid this (and also a few similar simplifications), the Xposed fork of ART disables these optimizations and recompiles all the odex/oat files. I actually have no idea how big the performance impact is, but it's necessary. It can't even be selective, as it's not known at compile time which methods will be hooked. This optimization can't be reverted when a method is hooked (e.g. by recompiling that method), because it would mean that all the calling methods would have to be recompiled, which would require a list of all callers of that method (or at least those that have inlined it).
I'm not sure about Nougat yet. It has a JIT compiler (Marshmallow had one, too, but it was disabled because it wasn't stable yet), maybe that brings some new opportunities. But that's still a long way, first hooking has to work at all.
Dalvik VM also uses JIT compiler
Click to expand...
Click to collapse
You don't say

rovo89 said:
Did you also do real benchmarks? Most of the time when people talk about performance, they say it "feels" slower, but that's hard to investigate...
Also, modules might of course add overhead as well. What I mentioned above just refers to the framework itself.
Click to expand...
Click to collapse
I still haven't done actual tests due to time constraints but an interesting thing is that XDA labs does indeed take a fraction of a second longer to launch with Xposed. But it's barely noticeable, I had to time it.

_LLJY said:
I still haven't done actual tests due to time constraints but an interesting thing is that XDA labs does indeed take a fraction of a second longer to launch with Xposed. But it's barely noticeable, I had to time it.
Click to expand...
Click to collapse
if it helps, with xposed activated and deactivated (typically after a new rom install), activated it's perfectly fine, performance is a bit hindered but not so much that you notice it right away. Skip ahead a couple hours and it's laggy and slow, stuttering, apps don't open quite as fast, nor do they stay open (that's to do with another issue regarding xposed v87). But before that v87 update, that issue persisted.
But when i have xposed disabled (after flashing the new build), it's perfectly fine, performance is as snappy as a GS4 (SD600) would get you and apps open faster, don't lag or get bogged down. And they generally perform much better over time.
I can at least for me, confirm this since I've started using xposed (v70-76 i believe).
(Sprint Galaxy S4 SD600 16gb model, cm13 (12/4/2016 nightly) with ten modules installed.)
Do let me know if this helps at all with determining the performance hit with xposed enabled and with a decent amount of modules installed.

I'm gonna guess there's no new news about xposed for nougat

Shiftydogit said:
I'm gonna guess there's no new news about xposed for nougat
Click to expand...
Click to collapse
Correct. @rovo89 has not quite cracked the code on making it work with N just yet. He's working on it though so patience is required.

sjamie said:
Correct. @rovo89 has not quite cracked the code on making it work with N just yet. He's working on it though so patience is required.
Click to expand...
Click to collapse
Hopefully he gets it N seems like a pain in the grass for a lot of things we power users enjoy

Shiftydogit said:
Hopefully he gets it N seems like a pain in the grass for a lot of things we power users enjoy
Click to expand...
Click to collapse
Amen.

Wonder what's happening, I heard that Nougat xposed is unreliable with JIT?
I hope it gets fixed soon and gets out to the public.
Anyways, great job devs<3

Rotated Quickbits said:
Wonder what's happening, I heard that Nougat xposed is unreliable with JIT?
I hope it gets fixed soon and gets out to the public.
Anyways, great job devs<3
Click to expand...
Click to collapse
Maybe a new year present????

mitas35 said:
Maybe a new year present????
Click to expand...
Click to collapse
I'm going to like and respond to this post as it was only minutes away from the new years

All I'm hoping for, is that Android O doesn't mess with the compiler any more than N did, Android O Developer Previews are going to come before the official announcement on the 17 - 19 May 2017, and first betas are set to come in the summer, which aren't that far away...
If it does, then its going to be a long catch up game for @rovo89