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.

[REF] Auto-brightness Changes

A long, long time ago, in a land far far away...
...there was a king of an empire on a peninsula near what we today call China. He had great scientists that made devices that let you magically talk with people in other places.
However, one of those devices annoyed the king. The king brought in his chief scientist and said, "How dare you make a magic box like this! Whenever I turn it on, the screen flashes bright when it is dim, or dim when it is bright. What do you have to say about this grave mistake of yours?" The chief scientist began, "Your honor, it is an issue with the start up of the GP2A sensor. You see, during the first 50,000 nanoseconds..." The king grew furious and interrupted him, "I don't want to hear about stinkin' nano-whatevers." He waved the chief scientist off and looked at the court jester. The jester smiled and said, "You could always just turn off auto-brightness." The king laughed and proclaimed, "Bring in my best consultants!"
In came the butcher, the baker, and the candlestick maker.
The king explained the problem to them and each thought carefully before responding.
The butcher said, "I'd just modify the kernel and only have it send out an event when the light level was very stable for 20 seconds."
The baker said, "I'd look at six samples, throw out the high, throw out the low, and return the average of the other four."
The candlestick maker said, "I know a little about light, you see. I'd throw out the first four samples, then just use wide bands so the light doesn't bounce around much."
The king listened to all three and looked at the jester. The jester said, "Don't look at me, it's all gobbledegook, but it all sounds good!"
The king proclaimed, "You heard the jester. Make it so!"
So the butcher hacked the kernel driver, as did the baker, and the candlestick maker hacked libsensors and the framework.
The jester laughed to himself, "What a hack job! Put in all three, that is going to be a mess and a half." Thankfully for the jester, the king didn't hear him.
The people awaited something from the king that would compete with the iPhone (yes, they had Apple Stores back then) and it came forth, named for the stars, the Galaxy S4G. And the people flocked to it. They were frustrated as its auto-brightness didn't work very well. It didn't flash bright and dim, but it took 20 seconds or more to adjust, and sometimes never did. So they took the advice of the jester, they turned auto-brightness off.
Then came the excitement. The pastry chefs were cooking up ice cream sandwiches. But their first results had the same problem as the gingerbread and the frozen yogurt. The people were disappointed. Again, they turned off the auto-brightness.
Thankfully, a magician from another court sent them a message that he had solved their problems. He had a phone that the auto-brightness worked well for him, to the point he forgot that auto-brightness was even on. He checked it for several days and tweaked it a bit for his personal preference.
This is that message.
Source has been committed to the TeamAcid repository that should resolve the auto-brightness issues with the SGS4G. New builds of CM9 and AOKP (and ROMs that use the TeamAcid code base) should soon see these changes after a repo sync is done.
For those assembling ROMs rather than building from scratch, you are likely to need:
Kernel with updated GP2A driver
Updated libsensors
Changes to framework to use the new values to set brightness
I can't say if one of the libsensor objects from one ROM can safely be used in another.
If you want to change the light levels and brightness, CM9 (and perhaps other ROMs) let a user select System settings > Display > Automatic Backlight and adjust the settings by checking "Use custom" and then clicking "Edit other levels..." I did not turn on the "Light Sensor Filter," but did select "Allow light decrease" and set "Decrease hysteresis" to 0%.
{
"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"
}
Edit -- I have since added an intermediate step at 180 brightness starting at 1750 lux to better handle overcast mornings/evenings.
If you're not familiar with lux and perceived brightness, the eye sees a doubling of light level as "one step" in brightness. The difference between "50% gray" and "white" is a doubling of light level. You'll see in the framework that for one of the steps the screen brightness varies by 0.7 -- half a "doubling" step -- to reduce big "jumps" at low brightness levels.
Here are some typical light levels in lux:
9 lux -- lower limit of output of sensor to Android code
50-150 lux -- typical home "living room" illumination
300-500 lux -- typical office illumination, sunrise or sunset
1,000 lux -- overcast day
10,000 lux -- indirect light on a sunny day
100,000 lux -- direct sun
These changes do not, unfortunately, resolve the soft-key light issues, nor do they seem to allow auto-brightness to set the brightness lower than the "20" that seems to be the "dim" level.

Very nice. About the only bug in CM9 that would these phones work. Hope this gets pushed to CM9 for us soon.

Great fix and one of the better reads I've had hear in a while. Oh and here's a log:

hechoen said:
Great fix and one of the better reads I've had hear in a while. Oh and here's a log:
Click to expand...
Click to collapse
Made me lol. I'm submitting the same log I guess

No, you guys are doing it wrong. This is what devs want. Right?

So... can I get an ETA on when jeffsf will be the next official member of Team Acid?
Seriously though, your research and contributions to our community have been amazing. Thanks for all your hard work.

This has been a long standing major issue.
My thanks do not go lightly! I really do appreciate your work on this!

IS there is a way I could rip the files from say the AOKP that has the auto-brightness and try it in another ROM I already have flashed. I could do a backup before in case it mucks something. I just like the look of Remic, the touchwiz, the dialer, all of it. I keep going back to it, but I like auto-brightness. lol.

getochkn said:
IS there is a way I could rip the files from say the AOKP that has the auto-brightness and try it in another ROM
Click to expand...
Click to collapse
Glad you find the auto-brightness changes working for you.
I'm not an expert on assembling a ROM from various bits and pieces, but the changes are detailed in the Team Acid repositories on github.
If I were to guess as to what to try, it would include:
boot.img for the kernel
/system/lib/modules/bcm4329.ko
/system/lib/libsensorservice.so
Changes to framework to provide the new auto-brightness levels in overlay/frameworks/base/core/res/res/values/config.xml
If the ROM in question doesn't use the same "layout" as CM9, then you might need to adjust other things, such as where the WiFi configuration information is found.

Thanks. way over my head. lol. Sure I could figure it out or wait till Remics gets updated.

Is anyone using custom levels? If so what values.
I find that the stock top level being set to 5000 is much to aggressive to be good for battery life.
Here are the values that I am testing now
What are yours?
Edit: these values seem to flicker a little between 3500 and 5000 lux (screen goes to dim before timeout and comes back up). Might need to edit a little or find values that are more exponential than linear
Also auto needs to be off for setting to stick and allow lights to decrease needs to be set to on or the levels will not come down from the highest levels

Note to trolls, this thread does not indicate that you can't post settings here. This feature is still "in development" and this type of feedback is welcome.
As a little help for those trying to come up with "midpoints" between things, if you have a level X and another level Y, the middle for perceived brightness is sqrt( X * Y)
For example, the "middle" of 600 and 5,000 is sqrt( 600 * 5,000 ) ~ 1,732

TrenchKato said:
Also auto needs to be off for setting to stick and brightness moving average filters needs to be set to on or the levels will not come down from the highest levels
Click to expand...
Click to collapse
Hmm, interesting. I don't have "Light Sensor Filter" enabled, but do have "Allow light decrease" set. I also have the "Decrease hysteresis" set to 0%.
I think that it might be the "Decrease hysteresis" setting that may be causing the effect you see. If there is 50% hysteresis on a level of 10240, I am guessing it won't "shift down" until you get to 5120. I haven't checked the code on that.
I'm hardly saying my settings are "optimal" -- I intentionally turned off filtering and hysteresis so that I could get rapid response to see how the various brightness levels "worked" (at least for me) in different lighting conditions.
Edit: Kato, what kind of light levels do you have in, for example, your office or home? Your breakpoints seem very high compared to what I would expect.
I'm running:
(0) - 1
50 - 32
75-45
150 - 64
600 - 128
1750 - 180
5000 - 255

I just realized that it its the light decrease setting that is causing the brightness to stay at high level... and it makes sense that a 50% hysteresis world cause flicker given that 50% world move thru 3 brightness.. I also have my dim set to 1...
I am actually outside... I didn't take that into account... however it is my preference to use the lowest values possible inside... so my values may be biased in that way.. especially when outside lux reads well above 10240 anyway (on AOKP)
That why I'm thinking using exponential set of values would work better in both conditions than just cutting values in half

Ya so thank to Jeffsf that we have Auto Brightness working now...so...not to hhijack this thread but for those who are a zip-jockey like me or who dont want to wait til your rom be updated (miui, remics, cna,...bla bla bla) and wanna do some experiment, here is what to do:
jeffsf said:
Glad you find the auto-brightness changes working for you.
I'm not an expert on assembling a ROM from various bits and pieces, but the changes are detailed in the Team Acid repositories on github.
If I were to guess as to what to try, it would include:
boot.img for the kernel (from AOKP build 5)
/system/lib/modules/bcm4329.ko (from AOKP build 5)
/system/lib/libsensorservice.so (from AOKP build 5)
If the ROM in question doesn't use the same "layout" as CM9, then you might need to adjust other things, such as where the WiFi configuration information is found.
Click to expand...
Click to collapse
Afterward, use apktool (recommend the latest 1.5.0 version) to decompile YOUR rom's framework-res:
Code:
$ apktool if framework-res.apk
$ apktool d framework-res.apk
and looke for the file: /res/values/arrays.xml
Scroll down to this:
Code:
<integer-array name="config_autoBrightnessLevels">
<integer-array name="config_autoBrightnessLcdBacklightValues">
<integer-array name="config_autoBrightnessButtonBacklightValues">
And change whatever values of those to this:
Code:
<integer-array name="config_autoBrightnessLevels">
<item>50</item>
<item>75</item>
<item>150</item>
<item>600</item>
<item>5000</item>
</integer-array>
<integer-array name="config_autoBrightnessLcdBacklightValues">
<item>1</item>
<item>32</item>
<item>45</item>
<item>64</item>
<item>128</item>
<item>255</item>
</integer-array>
<integer-array name="config_autoBrightnessButtonBacklightValues">
<item>255</item>
<item>255</item>
<item>255</item>
<item>0</item>
<item>0</item>
<item>0</item>
</integer-array>
After that, compile back the framework-res.apk
Code:
$ apktool b framework-res
And open the ORIGINAL framework-res and the /dist/framework-res by winrar in Windows or zip manager in ubuntu and copy the resource.arsc from /dist/framework-res to the ORIGINAL one and copy the modified original framework-res.apk back to the zip (that now contains boot.img, /lib/modules/* and /lib/libsensorservice.so) under the path: /framework and ya...flash it ^^ (you can use the hefe 0.8.1 for the package template and replace files under needs)

Hi Dao
Thanks. I tried that on MIUI.
I see the team acid kernel was updated but I don't think auto brightness is working. I see no change when choosing it on quick toggles.
How can I know that it really works?
10x
sent from me

itzik2sh said:
Hi Dao
Thanks. I tried that on MIUI.
I see the team acid kernel was updated but I don't think auto brightness is working. I see no change when choosing it on quick toggles.
How can I know that it really works?
10x
sent from me
Click to expand...
Click to collapse
It works in FB's latest AOKP release, I tried it and saw it work fine, so jeff's changes work. Exactly what needs to be used to bring it to another ROM though, ???

itzik2sh said:
How can I know that [auto-brightness] really works?
Click to expand...
Click to collapse
I don't see any logcat evidence in the version of CM9 I am currently running. Using ddms and watching frameworks/base/services/java/com/android/server/PowerManagerService.java (or its equivalent) would be my suggestion.

Thanks. I had some other non related FCs. Now that they're fixed I can see it is working. Ghanks guys!
Updating HebMIUI ROM.
sent from me

daothanhduy1996 said:
Ya so thank to Jeffsf that we have Auto Brightness working now...so...not to hhijack this thread but for those who are a zip-jockey like me or who dont want to wait til your rom be updated (miui, remics, cna,...bla bla bla) and wanna do some experiment, here is what to do:
Afterward, use apktool (recommend the latest 1.5.0 version) to decompile YOUR rom's framework-res:
Code:
$ apktool if framework-res.apk
$ apktool d framework-res.apk
and looke for the file: /res/values/arrays.xml
Click to expand...
Click to collapse
I tried to do this on your ROM and I get W: Cant find 9patch chunk in file: "drawable-hdpi/switch_thumb_pressed_holo_dark.9.png". Renaming it to *.png.
Not sure I want to continue if I get errors.

[ROM] [4.2.2] [UNOFFICIAL] CyanogenMod 10.1 for ChaCha [a810e / Status] [28.05.2013]

CyanogeMod 10.1 for HTC ChaCha [a810e / Status]​
DISCLAIMER :
Click to expand...
Click to collapse
Code:
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, broken hearts,
* thermonuclear war, you getting fired because the alarm app failed, or
* unfulfilled sexual partners. 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 me
* for messing up your device, I will point that finger back at you and laugh.
* make sure you do a nandroid backup in case your phone blows up in
* your face because your phone cant handle the speed :).
*/
* CREDITS
Click to expand...
Click to collapse
Code:
Google
Android
CyanogenMod
androidarmv6
OWLProject
Andreas Schneider
Special thank to winsuk
Special thank to JDevs (kernel,Device & Vendor,bug fixed,guide,support)
alquez
Droste
pabloPL
WFS: crossfire77 rallapag
ChaCha: adumont (patches Lucas Arran
everyone who's been working on CM10.1
And you!
WORKING
Click to expand...
Click to collapse
Code:
- GSM
- Data (2G/3G)
- SMS / MMS
- GPS ???
- USB
- Bluetooth
- WI-FI
- LED
- Camera
- Photocamera [fully]
- Camcoder (low FPS)
- Panorama mode [figured screen sometimes,It can be fixed easily]
- Video playback [not fully, with the 90º rotation playback,It can be fixed easily]
- YouTube [LQ/HQ/Browser] ???
- FM ???
??? I have not tested them
BUG:
Code:
- Battery drain fast
- Front camera
- USB Tethering
- Wi-Fi-Modem
- A2DP lag
- FM Radio
- in-call screen - caller picture is not in the right place with the right dimensions.It can be fixed easily
KERNEL FEATURES
Click to expand...
Click to collapse
https://github.com/OWLProject/OWL-Predator-KERNEL/blob/master/README.md
NO NEXT
BUT I'll upload my source files and step-by-step guide on my github(https://github.com/luzifer1984). a few days later.
I'm Chinese,so I would not compile next ROM for WWE.
My next build is only support for HTC CN CHS.
You can build a rom from source. plz add zh_CN (Chinese Simplified) support. THX!
cm-10.1-20130528-EXPERIMENTAL-chacha-A1.zip
https://docs.google.com/file/d/0B2l4GSuwT6TKMExrRXpmXzZyb3M/edit
CronMod-INT2EXT
http://forum.xda-developers.com/showthread.php?t=1716124
{
"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"
}

I havent tested this yet - I will this evening. but. if this works.. THANK YOU. I LOVE YOU SO MUCH FOR FIXING THE DIALPAD.
although I still think the "end call" onscreen button is not necessary.
We need to figure out how to map the End Call button(the red physical button) to end the call(if you havent already) and the number keys(physical keys) need to also input on the dialpad just as they do in CM9(again, havent tested yet. if they do, you're amazing. )
The "Call" or Green physical button should call the number onscreen, or from the home screen it should open the recently called list.
If you can fix all this stuff(or have already) I'll give you money. lol

Am I dreaming? This is amazing news! WOW. WOW. Great. Need to test this asap! Hopefully someone build one for us using your source. To who that would make a build for us: do not forget TURKISH language please!
---------- Post added at 06:14 PM ---------- Previous post was at 06:08 PM ----------
By the way, why not you make builds for EU, too? I mean, It shouldn't take some time for you to add a couple of more languages whenever you make a new build.

MD5sum: 5b7ccba99f8b63087696568c85070808
I didn't fix the screen layout of the dialpad. that have been fixed by CM10.1

I want to ask, are you working on front cam? All the problems other than front cam seems solvable to me.

So you have made to first custom kernel for the ChaCha?
Do you intend to work on the kernel? Because even if you don't update the ROM, but you keep the kernel source updated I can build it and make a flashable zip.
The battery life is probably a kernel issue right?
Edit: running it now. The slow wakeup bug from CM10 is fixed. Everything is great, except for battery. I hope there is a breakthrough with that. Thanks for the ROM!

kernel,Device & Vendor
Updated

luzifer1984 said:
kernel,Device & Vendor
Updated
Click to expand...
Click to collapse
So these updates include the fixes that OWLProject offers for Wildfire S? In this build of yours there is lag and now I see it is fixed in wildfire s.

Flashed this rom yesterday, looks some of the issues with CM 10 is fixed with 10.1.
If you are looking for gapps for 10.1, the slim version can be found in http://forum.xda-developers.com/showthread.php?t=2265564
I don’t see major issue with battery drain, it got discharged 25% after 12 hours of usage without wifi or data.
a) Lock screen is completely fixed with CM10.1 and fits wells within the screen
b) In call screen is neatly tailored for landscape
c) Apollo player works in landscape
Some of the things which needs fix
a) Caller id screen is overlapped, and it is very difficult see the caller info
b) Many of the popular application in playstore says ‘This item is not compatible with your device’ example ‘gmail’, ‘apex launcher ‘ etc
c) The proximity sensor is not working.
overall its superb rom, and it alomost complete rom. Thanks bro

ajeevlal said:
b) Many of the popular application in playstore says ‘This item is not compatible with your device’ example ‘gmail’, ‘apex launcher ‘ etc
Click to expand...
Click to collapse
Use any file manager, navigate to /system, look for the build.prop
Thanks to
Furkan DEĞER :
Turns out lcd density is set to 150, which should be 160. I changed it back to 160 and it solved my problem.
Click to expand...
Click to collapse

luzifer1984 said:
Use any file manager, navigate to /system, look for the build.prop
Thanks to
Click to expand...
Click to collapse
i figured that out few min back, i just changed the lcd density in build.prop and cleared the data/cache in playstore and it worked.
Thank you

furkandeger said:
By the way, why not you make builds for EU, too? I mean, It shouldn't take some time for you to add a couple of more languages whenever you make a new build.
Click to expand...
Click to collapse
Because chinese need "Lunar support"
" phoneloc (Chinese phone location) display support "
"Chinese keyboard input support by different kernel"
sorry for my english

luzifer1984 said:
Because chinese need "Lunar support"
" phoneloc (Chinese phone location) display support "
"Chinese keyboard input support by different kernel"
sorry for my english
Click to expand...
Click to collapse
Oh, I see so you have to work on a different kernel. I see. I want to ask something else. There are some lags, especially occuring in lockscreen and also on the system generally. I see in the wildfire s forums, this was a problem with the kernel and it was fixed a couple of days ago. You said you updated, kernel, device and vendor. Does that mean you applied this fix? Because, I'm setting up environment to build from your gits so, when I pulled the repo from you, will this fix be applied on the kernel?

furkandeger said:
Oh, I see so you have to work on a different kernel. I see. I want to ask something else. There are some lags, especially occuring in lockscreen and also on the system generally. I see in the wildfire s forums, this was a problem with the kernel and it was fixed a couple of days ago. You said you updated, kernel, device and vendor. Does that mean you applied this fix? Because, I'm setting up environment to build from your gits so, when I pulled the repo from you, will this fix be applied on the kernel?
Click to expand...
Click to collapse
No. I didn't merge OWL-Predator-KERNEL‘s update.
But you can check https://github.com/Luzifer1984/OWL-Predator-KERNEL/commit/b83a499dcbc60b2a18f917de5845d024d905f3f8
and you will kown how to .
just initial import from chacha-gb-crc-2.6.35-1643b58 (HTCDev.com)

luzifer1984 said:
No. I didn't merge OWL-Predator-KERNEL‘s update.
But you can check https://github.com/Luzifer1984/OWL-Predator-KERNEL/commit/b83a499dcbc60b2a18f917de5845d024d905f3f8
and you will kown how to .
just initial import from chacha-gb-crc-2.6.35-1643b58 (HTCDev.com)
Click to expand...
Click to collapse
OWL-Predator-KERNEL updating too often to catch

I wonder, can we use the kernel from the other CM10 rom? would that fix any performance issues? it would likely result in some of the things fixed to be broken again(camera? I dunno) but in terms of battery life and whatnot, I wonder if it would work
That having been said - I tried out the rom, it's very fast, smooth, it does drain the battery faster, but its not -too- bad. I think this has to do with there being no options for governor(or at least, none that I could find)
The rom has fixed most of the layout issues with the ChaCha. The dial screen is very nice, and the physical keys input once again. The lock screen fits properly now too.
I'll definitely have to do some more testing, but theres a few things that need to be fixed still. One is the LCD density in the build.prop - it causes some issues with certain apps.
EDIT: I also just noticed that while the phone is locked, the cpu must get set to a lower clock speed or something. The phone is very slow to respond when you go to unlock it.

kronflux said:
I wonder, can we use the kernel from the other CM10 rom? would that fix any performance issues? it would likely result in some of the things fixed to be broken again(camera? I dunno) but in terms of battery life and whatnot, I wonder if it would work
That having been said - I tried out the rom, it's very fast, smooth, it does drain the battery faster, but its not -too- bad. I think this has to do with there being no options for governor(or at least, none that I could find)
The rom has fixed most of the layout issues with the ChaCha. The dial screen is very nice, and the physical keys input once again. The lock screen fits properly now too.
I'll definitely have to do some more testing, but theres a few things that need to be fixed still. One is the LCD density in the build.prop - it causes some issues with certain apps.
EDIT: I also just noticed that while the phone is locked, the cpu must get set to a lower clock speed or something. The phone is very slow to respond when you go to unlock it.
Click to expand...
Click to collapse
Using kernel-kitchen you can extract the ramdisk from the CM10 boot.img and then extract the zImage from the CM10.1 boot.img and then combine the resulting zImage and ramdisk. I'm not sure if that makes sense. I'll try it sometime this weekend.

atrix4g18 said:
Using kernel-kitchen you can extract the ramdisk from the CM10 boot.img and then extract the zImage from the CM10.1 boot.img and then combine the resulting zImage and ramdisk. I'm not sure if that makes sense. I'll try it sometime this weekend.
Click to expand...
Click to collapse
well, I can't be positive as of yet, because I just installed it, but I just grabbed the CPU editor thing from here:
http://forum.xda-developers.com/showthread.php?t=1846967
I set it to On-Demand, changed the minimum frequency a tiny bit higher than the default, and set the max to 800. So far it seems like its better on the battery, but again, just installed it like 20 minutes ago, so I'll have to give it some time in testing.

kronflux said:
well, I can't be positive as of yet, because I just installed it, but I just grabbed the CPU editor thing from here:
http://forum.xda-developers.com/showthread.php?t=1846967
I set it to On-Demand, changed the minimum frequency a tiny bit higher than the default, and set the max to 800. So far it seems like its better on the battery, but again, just installed it like 20 minutes ago, so I'll have to give it some time in testing.
Click to expand...
Click to collapse
"Settings"--"About phone" AND press "Build number" 3times to enabled development settings .
then go back "Settings" ,there have show "Performance" .
AND in "Processor" you will see this rom default setting is On-Demand.
CONFIG_MSM_CPU_FREQ_ONDEMAND_MAX=800000
CONFIG_MSM_CPU_FREQ_ONDEMAND_MIN=122880
Yes, you are correct completely.
I also just noticed that while the phone is locked, the cpu must get set to a lower clock speed or something. The phone is very slow to respond when you go to unlock it."
Click to expand...
Click to collapse
that can be save power, I guess

kronflux said:
I wonder, can we use the kernel from the other CM10 rom? would that fix any performance issues? it would likely result in some of the things fixed to be broken again(camera? I dunno) but in terms of battery life and whatnot, I wonder if it would work
That having been said - I tried out the rom, it's very fast, smooth, it does drain the battery faster, but its not -too- bad. I think this has to do with there being no options for governor(or at least, none that I could find)
The rom has fixed most of the layout issues with the ChaCha. The dial screen is very nice, and the physical keys input once again. The lock screen fits properly now too.
I'll definitely have to do some more testing, but theres a few things that need to be fixed still. One is the LCD density in the build.prop - it causes some issues with certain apps.
EDIT: I also just noticed that while the phone is locked, the cpu must get set to a lower clock speed or something. The phone is very slow to respond when you go to unlock it.
Click to expand...
Click to collapse
I don't understand the "very fast, smooth" part. It is not like that for me. Rom is occasionally lagging. When scrolling especially. Sometimes it freezes completely. I believe it's kernel related.

[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!