Database Info

A request to all devs...

I think the this is pertinent to all Samsung ROMs, and I would like Devs to provide input on an aspect that affects the whole reason we buy the phone - in this case the Skyrocket.
This is about brightness/clarity changes that happen between ROMs. One MAIN reason that we buy the Samsung phones is the brilliance of the Super AMOLED screens. When custom ROMs are flashed, the screen brighness and clarity - yes, clarity which may itself be a psychological link to brightness - changes quite a bit.
Almost all ROMs do NOT mention if the dev ACTIVELY changed the brightness settings in framework-res. NO DISSIN ANYBODY here. So please this is not a negative. Or did the dev remove stock apks, files etc., that may or may not be linked to screen/display settings. I UNDERSTAND THAT THIS MAY BE DONE TO SAVE BATTERY. So no biggie there either.
ALSO, I know how to hack the brightness in framework-res, and also have apps that can do it for me.
It would be great if devs could indicate if brightness was hacked, because STOCK BRIGHTNESS/DISPLAY always looks so much more impressive. Much more impressive than any custom rom, BUT STOCK SUCKS otherwise. If it was not hacked then clearly settings are getting affected.
It would be really great if we could retain stock display quality in custom ROMs. Also, by indicating about brightness in Rom OP, this would give a heads up what to expect. Whether to hack myself, or use apk.
THANKS TO ALL DEVS, anyways for their super work that makes the phones so much better than manufacturer's want us to have !!

chappatti said:
I think the this is pertinent to all Samsung ROMs, and I would like Devs to provide input on an aspect that affects the whole reason we buy the phone - in this case the Skyrocket.
This is about brightness/clarity changes that happen between ROMs. One MAIN reason that we buy the Samsung phones is the brilliance of the Super AMOLED screens. When custom ROMs are flashed, the screen brighness and clarity - yes, clarity which may itself be a psychological link to brightness - changes quite a bit.
Almost all ROMs do NOT mention if the dev ACTIVELY changed the brightness settings in framework-res. NO DISSIN ANYBODY here. So please this is not a negative. Or did the dev remove stock apks, files etc., that may or may not be linked to screen/display settings. I UNDERSTAND THAT THIS MAY BE DONE TO SAVE BATTERY. So no biggie there either.
ALSO, I know how to hack the brightness in framework-res, and also have apps that can do it for me.
It would be great if devs could indicate if brightness was hacked, because STOCK BRIGHTNESS/DISPLAY always looks so much more impressive. Much more impressive than any custom rom, BUT STOCK SUCKS otherwise. If it was not hacked then clearly settings are getting affected.
It would be really great if we could retain stock display quality in custom ROMs. Also, by indicating about brightness in Rom OP, this would give a heads up what to expect. Whether to hack myself, or use apk.
THANKS TO ALL DEVS, anyways for their super work that makes the phones so much better than manufacturer's want us to have !!
Click to expand...
Click to collapse
how exactly do you hack the brightness? I'd love to play with this.
Sent from my SAMSUNG-SGH-I727 using xda premium

Shadeslayers said:
how exactly do you hack the brightness? I'd love to play with this.
Sent from my SAMSUNG-SGH-I727 using xda premium
Click to expand...
Click to collapse
Here are some spots to help you: I would try to make a tutorial but have not gotten arond to it since it is available in some places.
The first is very up-to-date:
http://forum.xda-developers.com/showthread.php?t=1377410
http://forum.xda-developers.com/showthread.php?t=1337722
This tutorial below is form a different forum posted originally by DRGilroy (at Team BAMF Forums). This particular post is not available and I have copied it from Google's cached version: BUT ALL CREDIT GOES TO DRGilroy:
[How To] Customize Auto Brightness
I've created my own Auto Brightness Mods for people to use and I thought I would help those out who are interested in creating their own.
I learned how to do it myself by searching and finding tutorials here and there in different posts and forums. Some of what I found was either not detailed enough or had incorrect instructions for the version of APK Manager I am using. So, most of what I'm going to do here is just reiterate what someone else has already written out there somewhere in the world wide web.
Tools:
APK-Manager v5.0.2 (versions earlier than 5.0 behave differently so instructions would be somewhat different if your attempting to use one of them)
Notead++
7-Zip
Instructions for Creating Your Own Custom Auto Brightness Levels:
Extract the file "framework-res.apk" from your favorite ROM. You can find it in /system/framework/
Copy the framework-res.apk file into the APK Manager directory "place-apk-here-for-modding"
Execute the Script.bat file in the root of the APK Manager directory
Type option "9" and press Enter to Decompile the framework-res.apk file
Leaving the Command Window open, with Notepad++ open the file "arrays.xml" found under "\projects\framework-res.apk\res\values"
Find and edit the following *values:
<integer-array name="config_autoBrightnessLcdBacklightValues">
<item>94</item>
<item>94</item>
<item>94</item>
<item>94</item>
<item>143</item>
<item>143</item>
<item>171</item>
<item>199</item>
<item>227</item>
<item>255</item>
</integer-array>
<integer-array name="config_autoBrightnessLcdBacklightValuesUp">
<item>94</item>
<item>94</item>
<item>94</item>
<item>94</item>
<item>143</item>
<item>143</item>
<item>171</item>
<item>199</item>
<item>227</item>
<item>255</item>
</integer-array>
<integer-array name="config_autoBrightnessLcdBacklightValuesDown" >
<item>94</item>
<item>94</item>
<item>94</item>
<item>94</item>
<item>143</item>
<item>143</item>
<item>171</item>
<item>199</item>
<item>227</item>
<item>255</item>
Save your edits and close Notepad++
Reopen the Command Window and Type option "11", press Enter to Compile apk
When asked "Is this a system apk (y/n)" type "y" and press Enter
When asked "Aside from the signatures, would you like to copy... (y/n)" type "y" and press Enter
When prompted with "Press any key to continue . . .", Leaving the Command Window open, Navigate to the APK Manager directory "keep" and delete the file "resources.arsc"
Reopen the Command Window and now press any key to continue
Type option "22" and press Enter to Set current project
Select the newly compiled unsignedframework-res.apk file, it should be number 2, type "2" and press Enter
Take note of the "Current-App:" unsignedframework-res.apk should be shown on the upper right corner of the Command Window
Type option "5" and press Enter to Zipalign apk
At this point you can close the Command Window
Copy the file "unsignedframework-res.apk" from the APK Manager directory "place-apk-here-for-modding" and rename it to framework-res.apk
Congratulations, you now have a framework-res.apk that has your own custom Auto Brightness values!
Now what do you do with the framework-res.apk file?
There are a couple things you can do with the file.
You can use ADB to push your new framework-res.apk to the phone
You can create a flashable Zip using the UOT Kitchen website
You can use an existing flashable Zip that contains a framework-res.apk file and replace it with yours
I'll throw you a bone and you can use my flashable zip below, Yes, I'm just that nice!
bamf_forever_1.0.8_auto_brightness_1.0.zip
Brightness: 31, 31, 59, 87, 115, 143, 171, 199, 227, 255
MD5: A1360E982CE401E9302929D527BC3641
*Brightness Values Explained
The following numbers represent the light sensors steps for using brightness:
11, 41, 91, 161, 226, 321, 641, 1281, 2601
The following numbers are the stock values that I mod and they represent the level of brightness, lowest to highest in ten level steps:
94, 94, 94, 94, 143, 143, 171, 199, 227, 255
Example:
Light Sensor___Brightness
10---------------94
40---------------94
90---------------94
160--------------94
225--------------143
320--------------143
640--------------171
1280-------------199
2600-------------227
Higher------------255 = Max
You can use a free app on the Market called AndroSensor. It can provide you with the value of how much light the sensor is detecting.
In my testing, it appears to me that brightness values lower than 30 do not cause the backlight to dim any further. Also, when connected to a charger with battery charging, the light sensor doesn't go lower than 40 until the battery is fully charged, then it will lower to 10.
Then there is this http://forum.xda-developers.com/showpost.php?p=24437288&postcount=29
After all this there are free apps: I am using LogGraph.......
Good Luck !!

call me crazy but why bother. there are three options, I always just use dim to save battery, but occasionally ill go full bright when viewing a photo or something.

edgex said:
call me crazy but why bother. there are three options, I always just use dim to save battery, but occasionally ill go full bright when viewing a photo or something.
Click to expand...
Click to collapse
This phone has a great screen that clearly is the major selling point for it. Why ruin the screen under sub optimal conditions?
I am actually running mhx's full bloat stock ROM, and am loving the screen......... but I am restricted to this if I want the full visual experience. It is a little like buying HDTV for watching only 480p programming.
also automatic brightness when executed properly makes viewing under changing light conditions so much more smoother and pleasurable..
Well........that's just my opinion, not really complaining since a custom room is better than ATT cares to give us and I am thankful For that.

[PARANOIDANDROID JB/CS] Developers only: Porting, Support and Maintanance

{
"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"
}
disclaimer:
it shouldnt be necessary to mention but well, Paranoid-Settings is meant for official paranoid android only or ports that stay true to our vision. it is not meant to be included in other roms or kangs - unless we give permission. this is our good name that people pull through the mud when they mix it with conflicting source like aokp. hybrid engine and dpi changer will only result in a crappy user experience for the end-user. Hybrid relies on a clean system and does not change its DPI, thats the whole point of it. furthermore hybrid engine is huge and complicated to kang because it grew over half a year and hundreds of commits, resets, reverts, rewrites. the only real hybrid engine is the result of a clean repo init and . rom-build.sh devicename.
kangs and roms that dont have our permission can either write their own implementation (its really just a text file reader/writer) or adapt on the old paprefs version in the ICS branch, which is 100% opensource. hybrid engine is 100% open source aswell of course.
Some of you may have heard of tablet mode and if you have tried it you know well that it smashes your phone. Apps are small, their layout is screwed, things overlap, crash or stop working, Google Play forbids you to download, if you tried AOKP you cant even use launcher and phone. In short, it is a mess.
PARANOIDANDROID changed that. It does not "heal" tablet mode, it obliterates the boundaries. You define how big or small apps are, you define in which UI they display, no matter if your phone runs in tablet or phone mode, which also you can define. Customize every single entity on your phone, lockscreen, navigationbar, system-components, widgets, apps. If you prefer stay with your three bearpaw buttons + drop-down curtain or switch to a combined navigationbar + drop-up notificationcenter, enjoy Youtube in 3D, Gmail and settings in 2-columns, Chrome in its better mobile UI, etc. Nothing overlaps, nothing crashes, everything works as you'd expect. This is completely new ground and has never been realized before, it is lightyears from tablet mode.
We created it to establish the idea that tablet/hybrid mode can indeed work and that is was an error on Googles side to use the same layout for high resolution devices that is used on tiny little things like htc wildfire. We saw how badly build.prop tablet-mode was milked so we decided to remain closedsource until the codebase is mature enough to publish. Our first repos went public last week and the rest will follow soon, i will personally commit the hybrid sourcetree into CM9. Until then, do not ask us for sources, we have good reason to do it like this and when it's out people will know why, they will see something that works, not features for show. We are still fully open to ports. As long as they stay true to our vision and base on CM9.
As the sheer amount of porting requests needed to be addressed somehow we open this topic so maintainers can help each other and it'll be easy for us to take a look once in awhile as our pm-boxes are exploding. We understand that setting up PA can be quite confusing since it introduces must-have configurations that are unique.
​
GUIDE FOR PORTING PA 1.6 and higher (JELLYBEAN/CM10)
the bad news is, everything has changed. the good news is, porting will be way less troublesome. (-;
look at the ICS guide for more info, this ones onna be straight forward.
1. pad.prop no more. you'll have to look in /system/etc/paranoid/properties.conf. dont forget to supply the same file twice, as backup.conf, its a sefety net for users who screw their properties.
you dont need to worry about this file anymore. rom_min/max are arbitrary values. choose something that makes sense for your device. the GUI will pick it up and load its sliders with these values.
rom default dpi is a simple fallback value, used by the GUI aswell. rom default mode is the same. notice though that modes are not hardcoded, Youre targeting the actual layout containers. the GUI can even extract them from any apk. layouts for sysUI are: 360 (phone mode), 600 (phablet mode) and 720 (tablet mode). apps can define these tresholds as they want. thats the reason you couldnt get tabUI for playmarket for instance, because its containers sits at 800dp. "tabletUI" was hardcoded to 720. so thats no problem anymore.
the rest is clear, find a couple of good values for standard apps. make sure you dont create a spotty experience. and do set tabUI for the interesting apps. i have seen PA reviews on youtube and the guy browses the phone and everythings stock ... that kinda sucks. you dont need to boot into tablet mode right away, but at least take the time to find good values for settings, gmail, etc.
Code:
###################
# PARANOIDANDROID #
###################
## CONFIGURATION
%rom_dpi_min=160
%rom_dpi_max=320
%rom_default_dpi=320
%rom_default_layout=360
## CONFIGURATION
%hybrid_mode=1
%system_default_layout=0
%user_default_layout=0
%system_default_dpi=0
%user_default_dpi=0
## WORKSPACE PREFERENCES
android.dpi=0
android.layout=0
com.android.systemui.dpi=%rom_default_dpi
com.android.systemui.layout=%rom_default_layout
## SYSTEM PREFERENCES
com.paranoid.preferences.dpi=270
com.android.chrome.dpi=%rom_default_dpi
com.android.chrome.layout=%rom_default_layout
com.android.contacts.dpi=%rom_default_dpi
com.android.contacts.layout=%rom_default_layout
com.android.settings.dpi=245
com.android.settings.layout=720
com.android.calendar.dpi=260
com.android.browser.dpi=260
com.android.browser.layout=600
com.android.calculator2.dpi=160
com.android.calculator2.layout=600
com.android.email.dpi=230
com.android.email.layout=600
com.android.vending.dpi=220
com.android.vending.layout=1000
com.google.android.gm.dpi=250
com.google.android.gm.layout=600
com.google.android.talk.dpi=260
com.google.android.talk.layout=360
com.google.android.youtube.dpi=240
com.google.android.youtube.layout=800
com.google.android.apps.docs.dpi=240
com.google.android.apps.docs.layout=600
## USER PREFERENCES
well, thats it. i told you it was easy.
for those who port for legacy devices, we included a hide softscreenbuttons option in settings/system/navigationbar.
and then theres the speed dial preferences in the PA panel. thats a little bit compliated right now because the xml files that drive it are in the app itself. im not sure if you can backsmali it, it has a rom fingerprint. i need to ask jesus. one thing more, then that is resolved you will be able to create your own configurations, and those can not only contain hybrid data but ANY setting you can make in the entire android system.
example: on nexus we dont have much space in portrait mode, so the android standard of 5 notificationicons in tabletUI overlaps. so in one of those prefs i simply say: sysUI.dpi=240, that makes the systembar pretty big, sysUI.layout=720, that drops it into tabletUI, clock=0, that hides the android clock, notificationnumber=2, that limits the icons to two. i guess most of you will switch off softbuttons, and with these prefs you can do it, or even create several and let your users choose.
i know jesus has already completed the code to load user presets, i will add the information when i have it.
and dont forget this in your build.prop
Code:
ro.cm.version=PARANOIDANDROID
ro.modversion=PARANOIDANDROID
ro.pa.version=PARANOIDANDROID-pa_YOURDEVICE-1.XXa-DDMMMYYYY
oh, and do not, under any circumstance, touch build.prop dpi. system dpi runs always in default dpi.

GUIDE FOR PA 1.5 and lower (ICS)
1. Unlock Tablet Mode for all devices
This has been already stuffend into the framework by us and if you use our files you wont need it, but i will include it nonetheless. Legacy devices crippled with hardware buttons need hacks to make tablet mode work. I dont know exactly whom to thank for this find, names that pop up in my head are Xylograph and evilisto. Ics compilant devices simply need one more entry in their build.prop: qemu.hw.mainkeys=1. You can include both, doesnt hurt.
Code:
--- a/services/java/com/android/server/wm/WindowManagerService.java
+++ b/services/java/com/android/server/wm/WindowManagerService.java
@@ -5962,7 +5962,7 @@ public class WindowManagerService extends IWindowManager.S
unrotDw = dw;
unrotDh = dh;
}
- int sw = reduceConfigWidthSize(unrotDw, Surface.ROTATION_0, density, un
+ int sw = reduceConfigWidthSize((int)(unrotDw / density), Surface.ROTATI
sw = reduceConfigWidthSize(sw, Surface.ROTATION_90, density, unrotDh, u
sw = reduceConfigWidthSize(sw, Surface.ROTATION_180, density, unrotDw,
sw = reduceConfigWidthSize(sw, Surface.ROTATION_270, density, unrotDh,
build.prop
Code:
###################
# PARANOIDANDROID #
###################
ro.sf.lcd_density=192
qemu.hw.mainkeys=1
2. Find out tabletmode DPI treshold value
Tablet mode is AOSP standard functionality. ICS is will drop into tablet mode if it acknowledges a certain treshold DPI, depending on your devices screen. Changing ro.sf.lcd_density in /system/build.prop will do. You can calculate that value as follows, here's a snippet of the ICS code that decides if your UI runs in tablet mode or phone mode.
Code:
int shortSizeDp = shortSize * DisplayMetrics.DENSITY_DEFAULT / DisplayMetrics.DENSITY_DEVICE;
mStatusBarCanHide = shortSizeDp < 600;
In short, you need to reach a short-side device-independend pixel number of 600. Example: Nexus has a width of 720 and a height of 1280, shortest side is 720, default density is 320. shortSizeDp = 720 * 160 / 320 = 360. lower than 600, phone mode. We need to lower the Dpi: shortSizeDp = 720 * 160 / 192 = 600. Thats it, tablet mode!
The formula is:
Code:
treshold_dpi = shortest-side-dp * 160 / 600
3. Setting up pad.prop and build.prop
/system/pad.prop is the file that defines how apps scale and in which UI they display. You should provide your users with a nice selection of everyday apps and define the system-apps well. Users should not be shocked when the phone boots up, what they are supposed to see is something that drops their jaws.
For Galaxy Nexus it looks like this:
Code:
###################
# PARANOIDANDROID #
###################
## DEFAULTS
%rom_tablet_base=192
%rom_phone_base=320
%rom_mid_base=260
%rom_mid_high_base=290
%rom_framework_dpi=250
%rom_systemui_dpi=220
%rom_launcher_dpi=290
%screen_default_width=360
%screen_default_height=567
%screen_default_layout=268435474
%screen_opposite_width=600
%screen_opposite_height=1018
%screen_opposite_layout=268435491
## CONFIGURATION
%hybrid_mode=1
%system_default_dpi=%rom_mid_base
%user_default_dpi=%rom_mid_base
%user_default_mode=1
android.dpi=%rom_framework_dpi
com.android.systemui.dpi=%rom_systemui_dpi
## PREFERENCES
com.android.phone.mode=1
com.android.inputmethod.dpi=%rom_phone_base
com.android.inputmethod.latin.mode=1
com.android.inputmethod.dpi=%rom_phone_base
com.android.camera.mode=2
com.android.camera.dpi=%rom_tablet_base
com.cyanogenmod.trebuchet.mode=1
com.cyanogenmod.trebuchet.dpi=%rom_launcher_dpi
com.anddoes.launcher.mode=1
com.anddoes.launcher.dpi=%rom_launcher_dpi
com.teslacoilsw.launcher.mode=1
com.teslacoilsw.launcher.dpi=%rom_launcher_dpi
com.android.chrome.mode=1
com.android.chrome.dpi=%rom_mid_high_base
com.android.calendar.mode=2
com.android.contacts.mode=2
com.android.email.mode=2
com.android.htmlviewer.mode=1
com.android.mms.mode=1
com.android.settings.mode=2
com.android.vending.mode=2
com.google.android.gm.mode=2
com.google.android.googlequicksearchbox.mode=2
com.google.android.talk.mode=1
com.google.android.youtube.mode=2
What is important here is that you need to set it up first with device specific informations. Here's a small rundown of these values:
%rom_tablet_base=xxx - table mode treshold dpi
%rom_phone_base=xxx - default device dpi
%rom_mid_base=xxx - a good middle value that works both for tabUI & phoneUI apps, for nexus its ~260
%rom_mid_high_base=xxx - a little bit higher than middle
%rom_framework_dpi=xxx - a good value for the lockscreen
%rom_systemui_dpi=xxx - good value for navigationbar
%rom_launcher_dpi=xxx - default value for trebuchet
%system_default_dpi=0 - sets the global density for system apps. 0 means undefined. We will probably make it obsolete soon.
%user_default_dpi=xxx - sets the global density for non-system apps, set it to default dpi as this will guarantee that all of your users apps will look stock
%user_default_mode=1 - sets the global UI for non-system apps. 1 = phoneUI, 2 = tablet UI. set it to 1, all user apps will display in mobileUI. If the user has tablet ready apps he can switch himself in the settings panel
## P.A.L PARAMETERS - these are extremely important. you get them by logging the output of Configuration in tablet mode (_opposite) and phonemode (_default) kevdliu wrote a nice little helper to make it easier for you, look here
make dead sure you get pad.prop right or you'll get bootloops or crashes!
notice that we use packagenames for apps, if you dont know the name of an app open up your shell and type:
Code:
adb shell
pm list packages -f
android - framework-res, applies to lockscreen, dialogs, powermenu, toasts
systemUI - applies to the navigationbar, makes it bigger or smaller. DO NOT APPLY an UI to these two apps. everything else is fine, set it to tablet or phoneUI all you want, but not these two!
Configuration in phone mode and tablet mode
build.prop needs to be configures like this:
Code:
###################
# PARANOIDANDROID #
###################
ro.sf.lcd_density=192
ro.cm.version=PARANOIDANDROID
ro.modversion=PARANOIDANDROID
ro.pa.version=PARANOIDANDROID-pa_maguro-1.5a-28JUN2012-180025
density to tablet treshold. versions to PA and version in that exact format because internal functions are relying on it (OTA for example). change the name of your device and the date. the last numbers, i have no idea what they are, came from the buildscript.
4. Check our sourcetrees
More and more source will be published soon. Right now we have three projects out, OTA, Backup and Trebuchet (optimized for tabletmode with cool features). Hybrid code will come out soon. Use what you can get from there: http://betadan.com/paranoid/sources/
5. Port the rom
You are ready to go. Do what you always do when porting roms. I have zero experience with that. Again, use CM9. Do not even think about using AOKP.
Check out Xylopgraph's PA porting guide
6. Link to our Google Apps
Google policy forbids you to use their market if you change your DPI. The only values allowed are 160, 240, 320. Why? No one knows why. There have been workaroundw, wiping cache, using a valid DPI, open market, reboot back, blablabla, forget it, its rubbish. It will work for a minute and then it will cease to. In our package Phonesky and GoogleServicesFramework were hacked. It has other additions aswell: http://4ndr01d.com/drcmda/common/
7. Post your port link and help out others
We will include you in our webpage and when our repo's are open you are invited to compile from source and/or submit patches and additions. We might even work together as theres still much to do. Be sure to help out others here.
​

-----------------------------reserved

Thanks Moles, this will continue to help us on the Vivow Port till we can build from source.

Thanks for this innovation. Salute!

I just thanked all post ,if yo had one more I woudl have thanked it to ,
in other words , thanks !

Awesome! Thanks for this awesome contribution!

Thanks for opening up this thread, I actually have a question for you professionals. I have been trying to figure out how to enable audio during the boot animation. I have been searching like crazy to figure it out. I have tried adding the following to /system/customize/CID/default.xml. And also ading a android_audio.mp3 to /data/local.
Code:
audio="/system/customize/resource/android_audio.mp3"
I have also tried placing the android_audio.mp3 and the bootanimation in /system/media but no love.
My buddy GROGG88 even made a zip file for me to flash that added some files to /system/bin but still no luck. Here is the zip if you would like to take a look at it.
I plan on making some more bootanimations for the Paranoid Android ROM for the Sensation and would really like to be able to include audio with them. Any assistance you can give will be very much appreciated.

What files does ParanoidOTA depend on, (/system/framework or others)? I get it copied over, but it crashes on me when I try to open it.

sgtkwol said:
What files does ParanoidOTA depend on, (/system/framework or others)? I get it copied over, but it crashes on me when I try to open it.
Click to expand...
Click to collapse
Only settings are used (but settings depends on OTA not OTA on settings), you must be sure the right intent is sent via Settings > About > Check for updates. Also we need first to setup environment if some device is gonna add OTA.

D4rKn3sSyS said:
Only settings are used (but settings depends on OTA not OTA on settings), you must be sure the right intent is sent via Settings > About > Check for updates. Also we need first to setup environment if some device is gonna add OTA.
Click to expand...
Click to collapse
I'm porting from Crespo4g to Epic4g which are very similar devices.
Paranoid OTA and Paranoid Settings showing in Settings.apk I pulled from Crespo4g must be different, then. Not seeing a ParanoidSettings.apk, am I missing something? I have "Paranoid Settings" showing, but clicking it or "System" crash Settings.apk that I pulled from Crespo. No Paranoid Settings when I compile from source. Unable to local pad or pal within existing builds, either.

made an app that displays the needed PAL information and tablet dpi threshold and thought i would share it here for other developers
its attached to this post

kevdliu said:
made an app that displays the needed PAL information and thought i would share it here for other developers
its attached to this post
Click to expand...
Click to collapse
thanks! is there a way to make it calculate the treshold dpi aswell?

molesarecoming said:
thanks! is there a way to make it calculate the treshold dpi aswell?
Click to expand...
Click to collapse
yup im going to update it shortly
uploaded

mole: ive got my port on i717 almost running flawlessly now, few minor issues
http://forum.xda-developers.com/showthread.php?t=1686320

Thinking about porting this..

I am ported it to HTC Desire HD..
http://forum.xda-developers.com/showthread.php?p=26929079
Sent from my Desire HD using Tapatalk 2

JamieD81 said:
mole: ive got my port on i717 almost running flawlessly now, few minor issues
http://forum.xda-developers.com/showthread.php?t=1686320
Click to expand...
Click to collapse
need your problems here dude, thats why i opened the topic.
if somethings not working post logcats, etc.

@molesarecoming
I totally forgot my skills of compiling kangs, can you guide me a bit through pm... Wifi Tethering is not fully working....
My computer specs, already had external HDD to compile...
-Intel i7-2760qm (8 cores, 2.4ghz)
-8 GB Ram
-1 TB HDD SATA (Internal HDD)
-500 GB HDD 3x faster writing...

DaXmax said:
@molesarecoming
I totally forgot my skills of compiling kangs, can you guide me a bit through pm... Wifi Tethering is not fully working....
My computer specs, already had external HDD to compile...
-Intel i7-2760qm (8 cores, 2.4ghz)
-8 GB Ram
-1 TB HDD SATA (Internal HDD)
-500 GB HDD 3x faster writing...
Click to expand...
Click to collapse
what i do is mostly hacking. i have never ported a rom before. i guess what i would do is taking a nightly or compiling a build, test if everything works and then add pa's additions. i cant remember all components but from mind they are: framework.jar, framework-res.apk, android.policy.jar, services.jar, maybe core.jar. the apps are not so important, you can compile our trebuchet fork from source, try making settings.apk run, if not i think that ones coming out today and if not today than very soon.
it would be cool if one of the guys who's made it writes a small rundown and i would put it up.

[REQ][DISCUSSION]Auto Brightness fix for Roms

Hello all!...As you know, Jeffsf fixed our Auto Brightness issue for the source codes of Team Acid's ICS roms, and I, based on his changes to write a guide for fixing it on some ports using Compile/decompile method for instant fixing...anw, as some of people don't know how to do it or can't wait blah blah for that feature fixed for ur rom...so, I can do that for you...
All I need is your Roms' /system/framework/framework-res.apk (with the Rom name) and testers for them (to know if it would boot fine or not - usually fine)...
We can also discuss bout what values are great for Auto Brightness (like for battery friendly or bla bla) BECAUSE I know some of the roms don't support Custom Auto Brightness values (MiUI for instance)...
And yeah, that's that, just upload the framework-res.apk, pm me w the rom's name and I will update it here...
Notice: I will include in the normal kernel (not KOD version) by default and you can always flash the KOD if u want ...
My suggestion default Values (read in the code block, not the picture, the pic is just for illustration):
{
"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"
}
​
Code:
<integer-array name="config_autoBrightnessLevels">
<item>500</item>
<item>1000</item>
<item>4000</item>
<item>7000</item>
<item>10000</item>
</integer-array>
<integer-array name="config_autoBrightnessLcdBacklightValues">
<item>1</item>
<item>30</item>
<item>60</item>
<item>90</item>
<item>150</item>
<item>255</item>
</integer-array>
<integer-array name="config_autoBrightnessButtonBacklightValues">
<item>0</item>
<item>0</item>
<item>0</item>
<item>0</item>
<item>0</item>
<item>0</item>
</integer-array>
"config_autoBrightnessLevels" are the left column (used for sensor filter values).
"config_autoBrightnessLcdBacklightValues" are the center column (for the screen brightness).
"config_autoBrightnessButtonBacklightValues" are the right column (used for buttons brightness).
As if your roms support custom values edit then u can make changes afterward...otherwise, I will use this 6 steps on Brightness changing.
P/s: If you found this thread nonsense, PLEASE REPORT IT RATHER THAN LEAVING BAD COMMENTS...thanks ...And I will spend the next 3 days for requests...otherwise (u pm me 3 days later), I will do it the next Mon, Wed and Fri til weekend...

Here is the package, not much work cause I am very busy w the mid-term tests...So, this package is no more than just AOKP's kernel plus sensor lib...so, this will make your rom has auto brightness with default settings...
For those who r on CM9 (already fixed), AOKP (already fixed), Unknown CM9, Resurrection Remix, Codename, RemICS, Paranoid Android, Audiophile, F4k, Provision, Slim, Gummy, Stock IMM76L, Galaxy beam, AOKPCB...you will have this fixed plus customizable settings via settings app...
for those who r on cMiUI...or properly MiUI. u will have this fix but NOT customizable settings, mean, it will work w default values and it may be negative to battery or whatever, if u like, pm me your ideal values (I repeat) lol...have fun
DOWNLOAD HERE
Sent from my SGH-T959V using xda premium

I'll test one for your Remics, do I need to upload that framework for you? lol. I tried doing it myself but got all kinds of errors with apktool about the "9" files not being right, etc, so I stepped away, slowly. lol.

I hope you know what you're getting into!
I think it would also be helpful when people post settings to also post some "reference" levels of brightness (from the configure auto-brightness settings page, shown in the first post), since it seems some people's settings have much, much higher levels than others. The sensor seems to be pretty directional; a range of values is fine. The ROM in use (and if it has an updated-for-auto-brightness libsensors) also would be valuable.
The touchkey backlight settings are really only "off" (0) and "on" (anything except zero) and the keyboard settings don't apply. For example, a touchkey backlight setting of "1" is no different to the hardware than "20" or "150" or "255"
I'm running self-built versions of CM9 and AOKP, with updated kernel and libsensors. My settings are
(0) -- 1
50 -- 32
75 -- 45
150 -- 64
600 -- 128
1750 -- 180
5000 -- 255
My reference brightness levels are
Home lighting -- 100-400
Diffuse office lighting -- 500-750
Overcast day or outside in the shadows ~ 2000
Other than finding the lowest level the phone will dim to still too bright for at-night use, the main place I have problems is when I'm in the car and it is reasonably bright outside, but the phone's face is in the shade. I get the 180 from the 1750-5000 lux band. I keep "0%" and "100%" as well as auto on my CM9 toggles for brightness levels. I seem to remember using the Brightness Level widget on AOKP, and certainly was very happy with it on GB.

jeffsf said:
I hope you know what you're getting into!
I think it would also be helpful when people post settings to also post some "reference" levels of brightness (from the configure auto-brightness settings page, shown in the first post), since it seems some people's settings have much, much higher levels than others. The sensor seems to be pretty directional; a range of values is fine. The ROM in use (and if it has an updated-for-auto-brightness libsensors) also would be valuable.
The touchkey backlight settings are really only "off" (0) and "on" (anything except zero) and the keyboard settings don't apply. For example, a touchkey backlight setting of "1" is no different to the hardware than "20" or "150" or "255"
Click to expand...
Click to collapse
Yup ...anw, I tested those settings and they were ideal for me but mayb not for others, so I think they should (if can, test, too) give their ideal values and I will compare the values, and compare to your ref for values and choose best match...and btw, that softkey values are just for joking hehe (like they can think it will turn off the softkey backlight at first lol) ^^...and thanks for your ref man
P/s: for others users (than CM9 and AOKP of team Acid of course -cause they were fixed lol), if u like/want the fix for your rom, just send that framework-res.apk to me...don't need to ask lol cause I'm serving you lmao

Or just wait for aries. We're hot on the trail of the SoD, and other then having to update the overrides for lux values, the rest should work fine.

Can you do one for Remics? Since you made it, you don't need the framework file do you? lol.

Link is in 2nd post...READ IT CARFULLY CAUSE I THINK U SHOULD THANK TEAM ACID FOR THEIR WORK THAT I JUST ZIP-ED IT FOR YO LOL

daothanhduy1996 said:
Link is in 2nd post...READ IT CARFULLY CAUSE I THINK U SHOULD THANK TEAM ACID FOR THEIR WORK THAT I JUST ZIP-ED IT FOR YO LOL
Click to expand...
Click to collapse
Killed wifi. lol.

getochkn said:
Killed wifi. lol.
Click to expand...
Click to collapse
Flash it again or mayb twice (cause I am using it w wifi on)
Sent from my SGH-T959V using xda premium

daothanhduy1996 said:
Flash it again or mayb twice (cause I am using it w wifi on)
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
Flashed again on Remics. Fixed Wifi but no customizable values. I enter a screen value and it doesn't even change, nevermind give me the option to save. I tried your instructions before on decompiliing the framwork, etc but got all kinds of errors with the "9" files and gave up at that point. lol.
EDIT:
I can set any value for the values except the first "SCREEN" value. I can set it to 20 but anything under 20 won't even register and stay saved. I like the one value from Jeff's defaults but it won't save that value for the first setting only for some reason. I can try setting the "10" for the first screen value to anything under 20 and it doesn't stay. Anything over 20 and it does no problem. I even tried adding a level from 0-1 and then trying to make one from 1-49 and set the screen value and it will not take any values under 20. I can set 20 and above no problem but nothing under 20 at all.

getochkn said:
Flashed again on Remics. Fixed Wifi but no customizable values. I enter a screen value and it doesn't even change.
EDIT:
I can set any value for the values except the first "SCREEN" value. I can set it to 20 but anything under 20 won't even register and stay saved. I like the one value from Jeff's defaults but it won't save that value for the first setting only for some reason. I can try setting the "10" for the first screen value to anything under 20 and it doesn't stay. Anything over 20 and it does no problem. I even tried adding a level from 0-1 and then trying to make one from 1-49 and set the screen value and it will not take any values under 20. I can set 20 and above no problem but nothing under 20 at all.
Click to expand...
Click to collapse
Ya, Ihave seen that bug in some roms and believe me, even in aokp that I had that...but somehow, try to modify it to 'n'(1, 2, 3,... that different frim default) level steps and apply and then re setting values again ^^
Sent from my SGH-T959V using xda premium

daothanhduy1996 said:
Ya, Ihave seen that bug in some roms and believe me, even in aokp that I had that...but somehow, try to modify it to 'n'(1, 2, 3,... that different frim default) level steps and apply and then re setting values again ^^
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
Ok, I'll try playing around adding/removing levels and see what happens. In FB's latest AOKP, it stays set at 1.
Thanks for the work though on this and the time. Hope mid-terms are going well.
EDIT:
Nope, I tried setting 16 levels, 2 levels, 5 levels, not one of them will let me set anything below 20. lol. Not sure what FB did to his framework or what.

Ah so its weird cause Icould use that trick anw, it wasnt fb or teamacid fault, just mine ^^ as jeffsf pointed me out, I will dig into it again later...btw, that 9.png error is nothig, just proceed to the next step I wrote
Sent from my SGH-T959V using xda premium

daothanhduy1996 said:
Ah so its weird cause Icould use that trick anw, it wasnt fb or teamacid fault, just mine ^^ as jeffsf pointed me out, I will dig into it again later...btw, that 9.png error is nothig, just proceed to the next step I wrote
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
apktool b framework-res gives me a ton of errors after decompiling the Remics and just changing the array values. Here's a pastebin.
http://pastebin.com/tizyvfyk

AFAIK, you can't set a value below that which is set for "Screen dim level" -- while I have mine set for "1" instead of the default "20" value, I can't tell a difference with my eyeballs between "1" and "20" (It makes me feel good, even if it doesn't do anything.)
I'll look at the pastebin in a bit. Edit -- looks like a single line (79) with a problem that is repeated in each language. Apparently their build chain is more forgiving than apktool is for unmatched XML tags.

jeffsf said:
AFAIK, you can't set a value below that which is set for "Screen dim level" -- while I have mine set for "1" instead of the default "20" value, I can't tell a difference with my eyeballs between "1" and "20"
I'll look at the pastebin in a bit. Edit -- looks like a single line (79) with a problem that is repeated in each language.
Click to expand...
Click to collapse
THANKS JEFF. Setting the dim level was the problem. Set that to 1, I can set it to 1 and set whatever levels I want now.
---------- Post added at 01:24 PM ---------- Previous post was at 01:14 PM ----------
daothanhduy1996: What Kernel is the one in your package based on? I was reading that Hefe's Kernel fixes the voodoo sound issue, and since Remics uses Voodoo, I would like to use that but I don't think Hefe's 0.81 has auto-brightness fixed.

getochkn said:
I don't think Hefe's 0.81 has auto-brightness fixed.
Click to expand...
Click to collapse
That's correct, v0.8.1 does not have the auto-brightness-related patches to the light-sensor driver.
I've got to get back to Herring and get some builds up, it seems

jeffsf said:
That's correct, v0.8.1 does not have the auto-brightness-related patches to the light-sensor driver.
I've got to get back to Herring and get some builds up, it seems
Click to expand...
Click to collapse
But KOD is based off Heff's with auto-brightness and the touchbutton light off feature right?

getochkn said:
But KOD is based off Heff's with auto-brightness and the touchbutton light off feature right?
Click to expand...
Click to collapse
Correct; it has the kernel changes for both the light sensor, as well as turning off the touchkey backlight when a touchkey is "released."

[apk][mod] Lcamera with longer exposure times for crazy night pictures

Hey everyone!
As some of you might know, the nexus 5x and nexus 6p cameras have a maximum exposure time in manual mode of 1/4.3 seconds, which is a real shame. Somebody suggested that Google made this choice because of the bigger size of the pixels, nonetheless the resulting pictures in very low light are not satisfying and none of the apps on the play store overrides the limit of 1/4.3 seconds.
So, I managed to unlock longer exposure times (up to 5 seconds) on the nexus 5x camera to take some truly unbelievable night pictures. Since the sensor is the same, this app should work also on the nexus 6p and it might work even on other devices with at least android 5.0. It also probably works on the nexus 5, but doesn't appear to be working on the nexus 6.
A big thank to PkmX for developing the original app Lcamera and to CazeW for his suggestions.
Notice that the photos will be upside down, because the sensor is mounted upside down (at least in the nexus 5x). Just rotate them with your favorite photos editor. Also notice that the "screen refresh time" is the one of the exposure, so when you set an exposure of e.g. 3 seconds, the app will look like if it's stuck and refresh every 3s.
I am not responsible for any damage that your phone might report. I've been using this app for a long time and everything works fine.
You can download the .apk file and the source code at the bottom. To install the app you only need the .apk file, the source code is for developers who wish to improve the code.
Check the difference between a manual camera downloaded from the play store and my app (the pics are resized here).
Click on the images to enlarge.
{
"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"
}
How did I do it?
I exploited the fact that the older versions of Lcamera by PkmX allowed up to 1/1.2 seconds of exposure time (probably because the nexus 5x wasn't supported yet), so I downloaded the source of lcamera 0.3 by PkmX, modified a few lines of code and compiled it.
The exposure times of my modded app are: 5s, 4s, 3s, 2s, 1.5s, 1s, 0.5s, 0.23 s, ... and so on, up to 1/120000 s (the default minimum value) and you can change them in the settings of the app.
Why not more than 5 seconds?
Because the app gets really unstable, since those exposure times are not officially "hardware" supported.
EDIT: a user suggested here that the app might be stable for even longer exposures with a longer kernel readahead.
Beware that the app can be unstable even with exposure times longer than 3 seconds: if it starts crashing, just terminate it in the settings. I usually set the exposure time back to 1/10 s every time I close the app, otherwise the following times it might just crash when entering in it.
Therefore, with this app you can get some beautiful night pictures, the drawback is that sometimes it might be unstable (because those exposures are not hardware supported).
What did I modify?
In src/pkmx/lcamera/MainActivity.scala I've modified lines 417, 419, 693 and deleted the line 1083. You can download my source code at the bottom, the original source code from github and compare them, to see in more detail which are the differences.
I've also modified the app icon with one that I've personally designed.
Thank you and have fun

The first one is Google camera and the second is from your app

TW1ST3D1NS4N3 said:
The first one is Google camera and the second is from your app
Click to expand...
Click to collapse
In my app, tap on the magenta settings button, then on exposure and then de-select "Auto Exposure" and decrease the value of shooting time from 1/10 to something like 1-2, you will see what a difference.

Thanks for this.
Is it possible to force ISO to a lower value than 60?
Sent from my Nexus 5X using Tapatalk

oldskuler said:
Thanks for this.
Is it possible to force ISO to a lower value than 60?
Sent from my Nexus 5X using Tapatalk
Click to expand...
Click to collapse
Well, in the app the lowest possible iso is set to 40, but the camera doesn't go below 60, so I think it's not possible. Anyway 60 is already very low and the noise shouldn't be much, so I don't know if an even lower iso would actually bring some benefits.

Good job. Some questions and tips for your code. Haven't tried the app though as my phone is getting repaired.
Why use a base of 60s? Wouldn't it have been easier to just use a 10s base instead of 60s for val exposureTime? Then you would only have needed to multiply the values by 10 in exposureTimeMap instead of 60 (and also add your values, 2 for 5s, 2.5 for 4s and so on). You also seem to be missing the base 1/60s exposure, don't know if that matters though.
Remove the line prefs.exposureTimeIndex = exposureTimeIndex() from onStop(), this will stop the manual exposure getting saved when closing the app (hence you don't need to change it back before closing).
Try replacing the line (not sure if this code will work but you probably notice what I'm trying to do)
Code:
observe { exposureTimeIndex foreach { v => text = s"60/${new DecimalFormat("#.#").format(exposureTimeMap(v))}" } }
with
Code:
observe { exposureTimeIndex foreach { v => text = if (v > 5) s"1/${new DecimalFormat("#.#").format(exposureTimeMap(v)/60)}" else s"${new DecimalFormat("#.#").format(60/exposureTimeMap(v))}s" } }
for a nicer display of the exposure times. Obviously change the value of 60 if you decide to change the base value.
EDIT: You should also be able to fix the rotation by implementing this commit in your code. Might also know how to "fix" the preview as well so the refresh rate doesn't go below a certain rate, but don't want to take away all the fun from you.

Nice, should be great for shooting auroras.

So flash the source first then install apk? Apk alone would not take a picture.

Travisdroidx2 said:
So flash the source first then install apk? Apk alone would not take a picture.
Click to expand...
Click to collapse
Source is the sourcecode of the apk...
You don't have to flash anything,

CazeW said:
Why use a base of 60s? Wouldn't it have been easier to just use a 10s base instead of 60s for val exposureTime? Then you would only have needed to multiply the values by 10 in exposureTimeMap instead of 60 (and also add your values, 2 for 5s, 2.5 for 4s and so on). You also seem to be missing the base 1/60s exposure, don't know if that matters though.
Remove the line prefs.exposureTimeIndex = exposureTimeIndex() from onStop(), this will stop the manual exposure getting saved when closing the app (hence you don't need to change it back before closing).
Try replacing the line (not sure if this code will work but you probably notice what I'm trying to do)
Code:
observe { exposureTimeIndex foreach { v => text = s"60/${new DecimalFormat("#.#").format(exposureTimeMap(v))}" } }
with
Code:
observe { exposureTimeIndex foreach { v => text = if (v > 5) s"1/${new DecimalFormat("#.#").format(exposureTimeMap(v)/60)}" else s"${new DecimalFormat("#.#").format(60/exposureTimeMap(v))}s" } }
for a nicer display of the exposure times. Obviously change the value of 60 if you decide to change the base value.
EDIT: You should also be able to fix the rotation by implementing this commit in your code. Might also know how to "fix" the preview as well so the refresh rate doesn't go below a certain rate, but don't want to take away all the fun from you.
Click to expand...
Click to collapse
Thank you for the suggestions! Well I choose a base 60 because it is divisible by 5,4,3,2,1, so I could avoid using "double" values for the exposures and I didn't have to worry about the digit precision, but yes I've modified the code as you suggested to have a better looking exposure time in the app, with some small differences; now it's like 5 s, 4 s, ..., 1/2 s, 1/4.3 s, ... and I've also modified a bit the shorter exposures and added back the 1/60 one.
I've also deleted the line that saves the exposure preference.
I've checked the rotation commit but it is for a newer version of Lcamera, so there are many differences in the code.
Of course any suggestion on how to fix it in my app or how to change the "screen refresh rate" is welcome , as long as it doesn't imply to modify more than a few (let's say 30) lines of code, unless you want to do it yourself.
tauio111 said:
Nice, should be great for shooting auroras.
Click to expand...
Click to collapse
Yes, also to shoot the night sky. Nice picture by the way!
tauio111 said:
Source is the sourcecode of the apk...
You don't have to flash anything,
Click to expand...
Click to collapse
Exactly

enryea123 said:
Thank you for the suggestions! Well I choose a base 60 because it is divisible by 5,4,3,2,1, so I could avoid using "double" values for the exposures and I didn't have to worry about the digit precision, but yes I've modified the code as you suggested to have a better looking exposure time in the app, with some small differences; now it's like 5 s, 4 s, ..., 1/2 s, 1/4.3 s, ... and I've also modified a bit the shorter exposures and added back the 1/60 one.
I've also deleted the line that saves the exposure preference.
I've checked the rotation commit but it is for a newer version of Lcamera, so there are many differences in the code.
Of course any suggestion on how to fix it in my app or how to change the "screen refresh rate" is welcome , as long as it doesn't imply to modify more than a few (let's say 30) lines of code, unless you want to do it yourself.
Click to expand...
Click to collapse
Looked closer at the commit and you're right, would take a bit of work to implement it in the older version.
I'm not sure but this might be the part that handles the refresh rate of the screen.
Code:
val startPreview =
for { (cameraOpt, previewSurfaceOpt, previewSessionOpt, autoFocus, focusDistance, autoExposure, iso, exposureTime, metering)
<- Rx {(this.camera(), this.previewSurface(), this.previewSession(),
this.autoFocus(), this.focusDistance(),
this.autoExposure(), this.iso(), this.exposureTime(), this.metering())}
Inside that for you could put in an if that checks if this.exposureTime() is less than for example 1/5s, then use a constant of 1/5s instead of this.exposureTime().
I also might have found a way to get the newer version to be able to use slower shutter speeds. The problem I think is this code on line 699.
Code:
val validExposureTimes = Rx { lcamera().toList flatMap { camera => exposureTimes filter { camera.exposureTimeRange contains _ }} }
Which is a list of exposure times the sensor supports. Now, if we set this equal to the var exposureTimes, I think we should be able to use the longer exposure times. I don't know if straight val validExposureTimes = exposureTimes works or if you have to convert the Vector to a List first, haven't programmed in scala before. I would try this out myself if I had a phone to test it on.

Thanks for the mod. Here are my results compared to Google's HDR+

CazeW said:
Looked closer at the commit and you're right, would take a bit of work to implement it in the older version.
I'm not sure but this might be the part that handles the refresh rate of the screen.
Code:
val startPreview =
for { (cameraOpt, previewSurfaceOpt, previewSessionOpt, autoFocus, focusDistance, autoExposure, iso, exposureTime, metering)
<- Rx {(this.camera(), this.previewSurface(), this.previewSession(),
this.autoFocus(), this.focusDistance(),
this.autoExposure(), this.iso(), this.exposureTime(), this.metering())}
Inside that for you could put in an if that checks if this.exposureTime() is less than for example 1/5s, then use a constant of 1/5s instead of this.exposureTime().
Click to expand...
Click to collapse
Well, I managed to set the preview to be updated every 1/10s by creating another variable "exposureTimePreview", BUT this way on the screen you don't see the actual brightness that the picture is going to have, but the one that it would have if the exposure time was actually 1/10, so it is not very handy and it's better to just leave it how it is now.
CazeW said:
I also might have found a way to get the newer version to be able to use slower shutter speeds. The problem I think is this code on line 699.
Code:
val validExposureTimes = Rx { lcamera().toList flatMap { camera => exposureTimes filter { camera.exposureTimeRange contains _ }} }
Which is a list of exposure times the sensor supports. Now, if we set this equal to the var exposureTimes, I think we should be able to use the longer exposure times. I don't know if straight val validExposureTimes = exposureTimes works or if you have to convert the Vector to a List first, haven't programmed in scala before. I would try this out myself if I had a phone to test it on.
Click to expand...
Click to collapse
That line of code only exists in the latest source code on github, I'm using an older version, which in fact doesn't have that line (this missing line is probably the reason I could select longer exposures). I can even set exposures longer than 5 seconds, if they are between 6 and 9 the phone is likely to crash, but if they are 10s or longer the camera just seems to get crazy and some weird "moving purple shapes" are displayed on the screen.

Dark Emotion said:
Thanks for the mod. Here are my results compared to Google's HDR+
Click to expand...
Click to collapse
Thanks for the feedback!

enryea123 said:
Well, I managed to set the preview to be updated every 1/10s by creating another variable "exposureTimePreview", BUT this way on the screen you don't see the actual brightness that the picture is going to have, but the one that it would have if the exposure time was actually 1/10, so it is not very handy and it's better to just leave it how it is now.
That line of code only exists in the latest source code on github, I'm using an older version, which in fact doesn't have that line (this missing line is probably the reason I could select longer exposures). I can even set exposures longer than 5 seconds, if they are between 6 and 9 the phone is likely to crash, but if they are 10s or longer the camera just seems to get crazy and some weird "moving purple shapes" are displayed on the screen.
Click to expand...
Click to collapse
That's why I suggested to use an if, so that when the exposure time becomes unreasonably long (like 1s or more) you use a constant refresh rate which would at least help with the framing. When the exposure time is faster, you of course use that as your refresh rate.
EDIT: You could also then bump up the ISO sensitivity for the preview so that you would still see the actual brightness of the picture (or at least close to it). For example, you want to take a picture that uses ISO 100 and 1s exposure. You lock the refresh rate at 1/4s and bump the ISO for the preview to 400 to compensate for the 2 stops slower refresh rate, and you should end up with an equally bright preview as what the picture will look like. (I think this is what most cameras do.)
I know that line of code only exists in the latest source code. What I meant is that if you edit that line, you might be able to use that version for your mod.

CazeW said:
That's why I suggested to use an if, so that when the exposure time becomes unreasonably long (like 1s or more) you use a constant refresh rate which would at least help with the framing. When the exposure time is faster, you of course use that as your refresh rate.
EDIT: You could also then bump up the ISO sensitivity for the preview so that you would still see the actual brightness of the picture (or at least close to it). For example, you want to take a picture that uses ISO 100 and 1s exposure. You lock the refresh rate at 1/4s and bump the ISO for the preview to 400 to compensate for the 2 stops slower refresh rate, and you should end up with an equally bright preview as what the picture will look like. (I think this is what most cameras do.)
I know that line of code only exists in the latest source code. What I meant is that if you edit that line, you might be able to use that version for your mod.
Click to expand...
Click to collapse
Thank you, I didn't understand what you meant. Those are some interesting improvements, I will consider them in the future for sure (right now I don't have much free time to spend on this project).

great job well done i was waiting for this
it would be great to add timer future to this app

enryea123 said:
In my app, tap on the magenta settings button, then on exposure and then de-select "Auto Exposure" and decrease the value of shooting time from 60/1000 to something like 60/60, you will see what a difference.
Click to expand...
Click to collapse
Sorry for the noob question. When turning off auto exposure you have two options to change. The s and iso, what do you recommend for both? I do not get the 60/60. Thank you for the mods. I am sure when I get it set correctly it will work great.

Travisdroidx2 said:
Sorry for the noob question. When turning off auto exposure you have two options to change. The s and iso, what do you recommend for both? I do not get the 60/60. Thank you for the mods. I am sure when I get it set correctly it will work great.
Click to expand...
Click to collapse
Let's first make sure of a couple things: do you have the nexus 5x? have you downloaded the last version of my app? To make sure you did, download it again now. (you get the "60/60" only in the old app, in the new one it is written as "1 s").
The "s" is the exposure time, which is the time the shutter will stay opened to capture the light (in fact the "s" stands for seconds). The iso is the sensitivity of the camera but it is directly related to noise (higher iso = higher noise).
So, I recommend to keep the exposure time as long as possible (like 3-4-5 seconds) and lower the iso until you get the right photo brightess.

enryea123 said:
Let's first make sure of a couple things: do you have the nexus 5x? have you downloaded the last version of my app? To make sure you did, download it again now. (you get the "60/60" only in the old app, in the new one it is written as "1 s").
The "s" is the exposure time, which is the time the shutter will stay opened to capture the light (in fact the "s" stands for seconds). The iso is the sensitivity of the camera but it is directly related to noise (higher iso = higher noise).
So, I recommend to keep the exposure time as long as possible (like 3-4-5 seconds) and lower the iso until you get the right photo brightess.
Click to expand...
Click to collapse
Thank you for explaining this. And yes I have the 5x and it is the new version of the app. Thank you for explaining this!

[MOD][Kernel] K-Lapse : A kernel-level livedisplay module [GPLv2]

{
"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"
}
K-Lapse : A kernel level livedisplay module
​
Intro - What is K-Lapse?
Kernel-based Lapse ("K-Lapse") is a linear RGB scaling module that 'shifts' RGB based on time (of the day/selected by the user), or (since v2.0) brightness. This concept is inspired by LineageOS (formerly known as 'CyanogenMod') ROM's feature "Livedisplay" which also changes the display settings (RGB, hue, temperature, etc) based on time. This is very very similar to f.lux for desktop too.
Why did I decide to make this? (A short story)
I (personally) am a big fan of the Livedisplay feature found on LineageOS. I used it every single day, since Android Lollipop. Starting from Android Nougat, a native night mode solution was added to AOSP and it felt like Livedisplay was still way superior, thanks to its various options (you could say it spoiled me, sure). I also maintained a kernel (Venom kernel) for the device I was using at that time. It was all good until the OEM dropped support for the device at Android M, and XDA being XDA, was already working on N ROMs. The issue was, these ROMs weren't LineageOS or based on it, so Livedisplay was... gone. I decided I'll try to bring that feature to every other ROM. How would I do that? Of course! The kernel! It worked on every single ROM, it was the key! I started to work on it ASAP and here it is, up on GitHub, licensed under GPL (check klapse.c), open to everyone
How does it work?
Think of it like a fancy night mode, but not really. Klapse is dependent on an RGB interface (like Gamma on MTK and KCAL on SD chipsets). In mode 1, it fetches time from the kernel, converts it to local time, and selects and RGB set based on the time. The result is really smooth shifting of RGB over time. Mode 2 uses the current brightness level to scale RGB, with the concept behind it being that lower brightness usually implies a dark environment, so a slight color temperature shift should help with eye strain.
There's also an option for a "brightness factor" that can reduce your brightness down to 80% below the minimum brightness that your phone allows. The catch is, it doesn't actually reduce the brightness, but rather uses a clever trick to fade away the RGB of the screen by the same amount so it "appears" to be lower brightness.
How does it really work (dev)?
Klapse mode 1 (time-based scaling) uses a method void klapse_pulse(unsigned long data) that should ideally be called every minute. This is done using a kernel timer, that is asynchronous so it should be handled with care, which I did. The pulse function fetches the current time and makes calculations based on the current hour and the values of the tunables listed down below.
Klapse mode 2 (brightness-based scaling) uses a method void set_rgb_slider(<type> bl_lvl) where type is the data type of the brightness level used in your kernel source. (OnePlus 6 uses u32 data type for bl_lvl) set_rgb_slider needs to be called/injected inside a function that sets brightness for your device. (OnePlus 6 uses dsi_panel.c for that, check out the diff for that file in op6 branch)
What all stuff can it do?
Emulate night mode with the proper RGB settings
Smoothly scale from one set of RGB to another set of RGB in integral intervals over time.
Reduce perceived brightness using brightness_factor by reducing the amount of color on screen. Allows lower apparent brightness than system permits.
Scale RGB based on brightness of display (low brightness usually implies a dark environment, where yellowness is probably useful).
Automate the perceived brightness independent of whether klapse is enabled, using its own set of start and stop hours.
Theoretically more efficient, faster by residing inside the kernel instead of having to use the HWC HAL like android's night mode. This is unproven and probably has no practical significance.
(On older devices) Reduce stuttering or frame lags caused by native night mode.
An easier solution against overlay-based apps that run as service in userspace/Android and sometimes block apps asking for permissions.
Give you a Livedisplay alternative if it doesn't work in your ROM.
Impress your crush so you can get a date (Hey, don't forget to credit me if it works).
Alright, so this is a replacement for night mode?
NO! Kinda, but no. Lemme explain. One can say this is an alternative for LineageOS' Livedisplay, but inside a kernel. Night mode is a sub-function of both Livedisplay and KLapse. Most comparisons here were made with night mode because that's what an average user uses, and will relate to the most. There is absolutely no reason for your Android kernel to not have KLapse. Go ahead and add it or ask your kernel maintainer to. It's super-easy!
What can it NOT do (yet)?
Calculate scaling to the level of minutes, like "Start from 5:37pm till 7:19am". --TODO
Make coffee for you.
Fly you to the moon.
Get you a monthly subscription of free food, cereal and milk included.
I want more! Tell me what can I customize!
All these following tunables are found in their respective files in /sys/klapse/
Code:
1. enable_klapse : A switch to enable or disable klapse. Values : 0 = off, 1 = on (since v2.0, 2 = brightness-dependent mode)
2. klapse_start_hour : The hour at which klapse should start scaling the RGB values from daytime to target (see next points). Values : 0-23
3. klapse_stop_hour : The hour by which klapse should scale back the RGB values from target to daytime (see next points). Values : 0-23
4. daytime_r,g,b : The RGB set that must be used for all the time outside of start and stop hour range.
5. target_r,g,b : The RGB set that must be scaled towards for all the time inside of start and stop hour range.
6. klapse_scaling_rate : Controls how soon the RGB reaches from daytime to target inside of start and stop hour range. Once target is reached, it remains constant till fadeback_minutes (#13) before stop hour, where target RGB scales back to daytime RGB. (Pre-v4.2 value was a factor, now it is a minute value)
7. brightness_factor : From the name itself, this value has the ability to bend perception and make your display appear as if it is at a lesser brightness level than it actually is at. It works by reducing the RGB values by the same factor. Values : 2-10, (10 means accurate brightness, 5 means 50% of current brightness, you get it)
8. brightness_factor_auto : A switch that allows you to automatically set the brightness factor in a set time range. Value : 0 = off, 1 = on
9. brightness_factor_auto_start_hour : The hour at which brightness_factor should be applied. Works only if #8 is 1. Values : 0-23
10. brightness_factor_auto_stop_hour : The hour at which brightness_factor should be reverted to 10. Works only if #8 is 1. Values : 0-23
11. backlight_range : The brightness range within which klapse should scale from daytime to target_rgb. Works only if #1 is 2. Values : MIN_BRIGHTNESS-MAX_BRIGHTNESS
12. pulse_freq : The amount of milliseconds after which klapse_pulse is called. A more developer-targeted tunable. Only works when one or both of #1 and #8 are 1. Values : 1000-600000 (Represents 1sec to 10 minutes)
13. fadeback_minutes : The number of minutes before klapse_stop_hour when RGB should start going back to daytime_rgb. Only works when #1 is 1. Values : 0-minutes between #2 and #3
Impact on performance or battery...
Fortunately, as per practical testing there is absolutely no negative effect on performance or battery backup!
"I'm a kernel maintainer. How do I add it to my source?"
Note : I'm currently maintaining klapse for OnePlus6 (enchilada), using the snapshot branch.
The klapse.c file is pretty much generic, but depending on your device you may need to change some of the #define values
The klapse.h file should be edited in order to make the K_RED etc. defines point to the correct RGB interface variable. OnePlus 6 simply uses kcal_red, kcal_green and kcal_blue in sde. Some devices have a struct or pointers instead of a variable. Those devices must edit their kcal files to keep a copy of the address that klapse will access. An example of a source with struct-based kcal with klapse support is this: commit (thanks to @rupanshji for this commit)
The KCONFIG is pretty understandable too, but you may wanna remove the "DEPENDS" line for your device.
The Makefile is just one line, and so is enabling klapse in the defconfig.
Now you must change the file that provides the kcal/gamma (mtk) interface. Thanks to other developers, all I had to do on the OnePlus 6 was to remove the keyword "static" from the variable declaration.
Great work! Can I pay for your next meal?
I'm just a university CS student so sure, any amount is much appreciated! You can donate via PayPal here :
Donate
XDA:DevDB Information
K-Lapse, Kernel for all devices (see above for details)
Contributors
tanish2k09
Source Code: https://github.com/tanish2k09/KLapse-Livedisplay
Kernel Special Features: RGB shifting based on a context
Version Information
Status: Stable
Current Stable Version: 4.3
Stable Release Date: 2019-03-02
Created 2019-03-04
Last Updated 2019-03-19

TODO :
Add custom-minute support
Add full-smooth scaling algorithm that actually scales from node to node to make the shift smoother
Add a third "intelligent" mode that uses both time-based and brightness-based values to magically come up with an RGB set that's perfect for that environment
A grayscale feature, that maybe also would support a yellow tint over it, so it's like a grayscale night mode.
Telegram support?
Yeah yeah, I know. Telegram links are common now. In compliance with the xda rule of "Only one TG link per thread" that I saw on some other sub-forums, maybe a link would be fine but mods can remove it per will.
Here's the official klapse telegram group, with commit notifications too:
t.me/klapse or from within telegram you can just join klapse but with an @ in front of it (I didn't use it to prevent an unintended mention to some person)
Notes :
I'm open to any other contructive feedback or suggestions
Klapse doesn't conflict with night mode of Android. They both can work TOGETHER, the result would be an overlap of both their colors.
Credits :
I pretty much wrote all the code for k-lapse myself, but it would be useless without these awesome people who put it to use -
@pappschlumpf for getting k-lapse working for the first time on any snapdragon device, with Smurf kernel for OnePlus 6
@Eliminater74 for tips along the way, very helpful
@HolyAngel for a collab to add support to HolyDragon, and indirectly SkyDragon, and suggesting some tunable structuring
@rupanshji for the commit used for an example of a structured kcal implementation
@flar2 for debugging and adding k-lapse support to his app EX kernel manager, purchase the app here - EXKM
 @franciscofranco for adding k-lapse support to his app Franco Kernel Manager, purchase the app here - FKM

Screenshots
Screenshots from EXKM v4.04, Mixplorer and FKM v4.0 have been attached.
Note that these screenshots were taken while v4.3 was the active version. May change in future.

It's pretty common now
@apophis9283 Seeing you're one of the mods here, would you please be kind enough to delete the other 3 clones of this thread that got created due to XDA request failure?
Also, in case this thread is in the wrong sub-forum, please feel free to move it to the correct one but notify me via PM or email. Many thanks

Been using this on Smurf kernel for awhile now. Absolutely love it. Great job.

Glad your work is posted on XDA now works good in sky dragon.

Great alternative to night mode that does way more than that if you're interested in other features.
It's lightweight and won't bloat your system at all.
Any proper kernel should include this as there are only benefits and no drawbacks. 8)
As a last addition/compliment/support: it's been very well maintained and as you can tell just from reading OP, the dev is friendly and will help you if you have issues with it.

On Smurf kernel on op6. I have the gray scale option on digital wellbeing in the night and after switching on this mod (light mode) it automatically turns off the gray scale. Is it a bug?

akiwiz said:
On Smurf kernel on op6. I have the gray scale option on digital wellbeing in the night and after switching on this mod (light mode) it automatically turns off the grayscale. Is it a bug?
Click to expand...
Click to collapse
It is not a bug, it's actually expected behaviour.
First of all, we both know that the screen can't be both grayscale AND have a yellow tint at the same time, because yellow isn't gray.
Only one of them can stay active. The fact that klapse works from the kernelspace makes klapse more powerful. As soon as klapse refreshes, which happens every 30 seconds by default, the grayscale RGB will be overridden.
It also depends on how digital wellbeing's grayscale option works. I'm assuming it uses the same HWC HAL that android uses, but I have not the slightest clue. In case I'm right, both klapse and grayscale will work together to give you a black-n-white + slight yellow tinted screen.
As an alternative, how about I add grayscale as a feature to klapse itself? I can't add it to klapse right away but I can mark it in my TODO post above. Sounds good? Maybe I can come up with a solution that overlaps the grayscale with the yellow tint to create a grayscale night mode?
I don't know about you but it seems like an amazing idea to me

tanish2k09 said:
It is not a bug, it's actually expected behaviour.
First of all, we both know that the screen can't be both grayscale AND have a yellow tint at the same time, because yellow isn't gray.
Only one of them can stay active. The fact that klapse works from the kernelspace makes klapse more powerful. As soon as klapse refreshes, which happens every 30 seconds by default, the grayscale RGB will be overridden.
It also depends on how digital wellbeing's grayscale option works. I'm assuming it uses the same HWC HAL that android uses, but I have not the slightest clue. In case I'm right, both klapse and grayscale will work together to give you a black-n-white + slight yellow tinted screen.
As an alternative, how about I add grayscale as a feature to klapse itself? I can't add it to klapse right away but I can mark it in my TODO post above. Sounds good? Maybe I can come up with a solution that overlaps the grayscale with the yellow tint to create a grayscale night mode?
I don't know about you but it seems like an amazing idea to me
Click to expand...
Click to collapse
Thank you for the explanation ? is there a way I can switch off klapse at night when grey scale from digital wellbeing kicks in? Also your alternative would be ideal if it's possible in future! Thanks again

akiwiz said:
Thank you for the explanation ? is there a way I can switch off klapse at night when grey scale from digital wellbeing kicks in? Also your alternative would be ideal if it's possible in future! Thanks again
Click to expand...
Click to collapse
A tester just told me that klapse's yellow tint worked on gray-scale too.
But to answer your question, the only possible solution is to either disable Klapse or keep the schedule of start and stop outside the range of grayscale's schedule.
Btw I totally recommend you to use Klapse at night because yellow tint in the dark is better than grayscale to look at

tanish2k09 said:
A tester just told me that klapse's yellow tint worked on gray-scale too.
But to answer your question, the only possible solution is to either disable Klapse or keep the schedule of start and stop outside the range of grayscale's schedule.
Btw I totally recommend you to use Klapse at night because yellow tint in the dark is better than grayscale to look at
Click to expand...
Click to collapse
So I need EXM to set a schedule start?

akiwiz said:
So I need EXM to set a schedule start?
Click to expand...
Click to collapse
EXKM is one way. You can create your own tunables in Franco kernel manager too like. Here's a couple screenshots of an example.
You can use those same paths in kernel adiutor too. I haven't talked to the dev for klapse support yet, maybe I should but next weekend probably.
You can also use a file manager to change those files. Remember that pretty much everything in /sys is rebuilt during each boot so all values reset. That's why an apply-on-boot method is used for fixing values.
Info for which file does what is in OP.

This doesn't seem to work for me. OnePlus 6 with xXx NoLimits and Smurf Kernel. Latest stable versions for all. I have changed settings with EXKM and rebooted multiple times. /sys/klapse files accurately reflect the settings in EXKM. Setting K-Lapse alternately to time and light have failed to demonstrate any color changes as would be expected from the settings. I turned off the phone's night mode so that I can see more purely what K-Lapse does.
Thoughts?

maigre said:
This doesn't seem to work for me. OnePlus 6 with xXx NoLimits and Smurf Kernel. Latest stable versions for all. I have changed settings with EXKM and rebooted multiple times. /sys/klapse files accurately reflect the settings in EXKM. Setting K-Lapse alternately to time and light have failed to demonstrate any color changes as would be expected from the settings. I turned off the phone's night mode so that I can see more purely what K-Lapse does.
Thoughts?
Click to expand...
Click to collapse
I'm guessing you're using the wrong display calibration mode.
On the OnePlus 6 stock ROM it only works with custom and adaptive display modes in settings.

tanish2k09 said:
I'm guessing you're using the wrong display calibration mode.
On the OnePlus 6 stock ROM it only works with custom and adaptive display modes in settings.
Click to expand...
Click to collapse
That was it exactly. Thanks!

I can't find any settings for K-lapse in the latest EX Kernel Manager. I went through every section of the app. No K-lapse settings.

majikfox said:
I can't find any settings for K-lapse in the latest EX Kernel Manager. I went through every section of the app. No K-lapse settings.
Click to expand...
Click to collapse
Tools > Color Control > K-Lapse Settings

maigre said:
Tools > Color Control > K-Lapse Settings
Click to expand...
Click to collapse
Nope. Not there.

majikfox said:
I can't find any settings for K-lapse in the latest EX Kernel Manager. I went through every section of the app. No K-lapse settings.
Click to expand...
Click to collapse
I don't own EX kernel manager yet but I was given a v4.04 build to test, and it was under Graphics > Klapse-settings
They'll obviously only show up if the kernel supports it.
Also, some users reported that the update isn't live for them yet, so you may have to wait. That's not in my control either and flar2 handles EXKM.