Database Users

continous autofocus problem

I wish to turn off continous autofocus when i take videos, the only thing this continously does is - it continoutly ruin my videos with excessive amout of blur that makes it impossible to use in many cases.
Interior videos, even outside it tends to totally mess up any attempts to make a decent video.
I saw some custom roms have a option to disable it in options, but i would like to keep the original rom - Root it and change whatever magic inaccesible settings i need to change (like the silent camera shutter ro.camera.sound.forced=0 setting).
I saw Potatoman's camera.apk mod but that does not have any options regarding video autofocus.

totally useless
i am with you on that problem, i don't even film anymore. all movies with moving objects or even if i move my camera are useless. i don't know why they made it this way. hope for a quick and reliable solution.

Its annoying as hell. I also dont bother recording! . Sad really.
Sent from my porn shoot using GT-I9100.

+1 for this problem.
I saw some custom roms have a option to disable it in options
Click to expand...
Click to collapse
Can you provide a link to a such rom?

It is miui for galaxy s2, i saw this in action and it has a option to disable auto-bluring of videos but i dislike the rest of gui. Plus i lose stuff like usb otg if i put that rom on so i'm searching for another solution:
http://forum.xda-developers.com/showthread.php?t=1130951

No luck Tried the camera apk from miui and it doesn't work on my kf3 stock rom.

I think our best hope is that Potatoman fixes this, i cannot reply in his topic (10 posts limit), but i sent him a private message about this and i hope he reads it.
I looked into disassembly tools for apk files and so far had no success taking apart the camera app myself, otherwise if i had a working way to disassemble and reassemble it i would do this myself (baksmali fails on me with a "Could not find the main class: R:\Internet\baksmali-1.2.7.jar. Program will exit." message).

JernejL said:
I looked into disassembly tools for apk files and so far had no success taking apart the camera app myself, otherwise if i had a working way to disassemble and reassemble it i would do this myself (baksmali fails on me with a "Could not find the main class: R:\Internet\baksmali-1.2.7.jar. Program will exit." message).
Click to expand...
Click to collapse
You should extract the classes.dex file from the Camera.apk (using WinRar) and put it to the same folder with baksmali-1.2.7.jar.

I managed to do that, and found the magic command line parameters for running it, i have the smali files but this looks like one big mess.
I found startTimer in onVideoRecordingStart
and .method public handleMessage(Landroid/os/MessageV in camera main handler, this contains text such as "AF_WAIT_TIMER_EXPIRED" and calls to restartTouchAutoFocus, it could be the timer which continously calls autofocus, but it's not in camcorder classes but the camera class - i am not sure how the classes are interconnected and if this is really what i was looking for, i wish potatoman can help better with this.

I found something else, it looks like continous focus is a camera property - focusing mode:
.method public static getFocusModeString(I)Ljava/lang/String;
it has modes: "auto, fixed, macro, facedetect, continuous-video" and is saved to preferences as "pref_camera_focus_key" (this is my guess based on what i am seeing)
It seems that android api confirms this:
developer.android.com/reference/android/hardware/Camera.Parameters.html#FOCUS_MODE_CONTINUOUS_VIDEO
called with:
developer.android.com/reference/android/hardware/Camera.Parameters.html#setFocusMode%28java.lang.String%29
camcorderengine:
.method public doPrepareVideoRecordingAsync()V
const-string v3, "continuous_af"
this goes into..
const-string v1, "continuous_af"
const/4 v1, 0x0
invoke-virtual {v0, v3, v1}, Lcom/sec/android/seccamera/SecCamera$Parameters;->set(Ljava/lang/String;I)V
useful info here too:
pastebin.com/V94HYCnk
Code:
// Parse continuous autofoucs into a format the driver understands
conAf = pars.get("enable-caf");
if (conAf != 0 && strcmp(conAf, "on") == 0) {
mContinuousAf = true;
}
else {
mContinuousAf = false;
}
pars.set("continuous_af", mContinuousAf ? 1 : 0);
I hope this research opens up the possibility that potatoman fixes this for us, i can barely read this .smali assembly and i'm afraid i'll break everything if i change anything.
note: i had to cripple all the http links because i have too few posts to link to things externally.. :/

Hey guys, just a heads up that I'm working on v2 of my mod now, so while I'm doing that I'll take a look at this too. I don't usually film video though, so just to be clear, do you guys want it to just stop adjusting the focus entirely, or adjust the focus faster so that it isnt blurry for so long (since atm it takes like 5s before refocusing.) Personally I think the best solution would be to refocus on tapping the screen like the camera does, but I'm not sure if that's possible during capture, so I'd have to look into it.
Please post telling me which, so I know what I'm trying to implement here. I don't want to make it worse!

Refocus when tapping the screen will be the best way i think...
Sent from my GT-I9100 using XDA App

Based on the code and documentation that i saw, it's not even possible to adjust the focusing speed.
I would prefer that any automatic focusing is simply disabled during video recording / camcorder mode.
If tap to focus works can be done that would be brilliant, but no automatic adjustments as this ruined every video i took so far.
The phone simply starts refocusing / enters blur mode for no reason while the picture is already totally crisp and then ruins 3-5 seconds of video with blur while it tries to find "focus".

we need touch to focus
is the best solution

today i read online that choosing for a lower resolution then the full had filming wil fix the problem, i havent got any time yet to test it ........

Tap2Focus would be awesome! BUT simple disabling continuous af would be enough for start

I wish the operation is as following:
1, The focus start and lock when I touch the Record icon.
2, The focus is disable and start to record when I release my finger from the Record icon

mrky said:
today i read online that choosing for a lower resolution then the full had filming wil fix the problem, i havent got any time yet to test it ........
Click to expand...
Click to collapse
I tried this - one of first things i tried, it doesn't really help at all in my case (tested this outside in a clear well sun lit scene)

stev2010 said:
I wish the operation is as following:
1, The focus start and lock when I touch the Record icon.
2, The focus is disable and start to record when I release my finger from the Record icon
Click to expand...
Click to collapse
+1 Yes please!
But I would settle for ANYTHING to disable auto-focus because it make videos totally useless.

I actually have no problem with autofocus itself... but my issue is that auto focus does not work at ALL on any resolution lower than 1080... Anyone else have this issue?

Cyanogenmod light sensor code for Vision / G2 needs fixin'

Since I'm not allowed to post in the dev forum, I'll just leave this here:
The light sensor code on the HTC vision is out of date. It can only return 10 light levels, which range from 0..1024. I've been told this is apparently a Froyo standard and that modern phones return from 0..10240.
github dot com/CyanogenMod/android_device_htc_vision/blob/gingerbread/libsensors/LightSensor.cpp
wtf, can't even link to things as a new user?!?
On line 143, you can see the 10 constants that the light sensor code picks between. They are supposed to be in "Lux", but can anyone with a photography rig confirm this? Looking at this chart,
engineeringtoolbox dot com/light-level-rooms-d_708.html
1024 lux is an overcast day. If that's the maximum it can report, that seems like a particularly ****ty light sensor.
Is the hardware that bad, or is the Cyanogenmod code not taking full advantage?
Once we can figure out what the light sensor readings should be, I'll submit a patch to fix the default Automatic Brightness settings (which right now are totally out of sync with the hardware light levels). See line 40 here.
github dot com/CyanogenMod/android_device_htc_vision/blob/gingerbread/overlay/frameworks/base/core/res/res/values/config.xml
Anyhow, only 9 more posts to go before I can participate in the CM9 dev thread

Definitely submit a CM bug report explaining this. Then when you can post links, post a link to the issue thread and everyone will happily plus 1 it.

Hardware is not that bad - this is a CM problem. I've patched mine so it works properly, also, don't use CM. My recommendation.

Thanks for the encouragement. I've filed a bug here. My etiquette may or may not get a warm reception there, so +1s would be appreciated.
code.google [dot] com/p/cyanogenmod/issues/detail?id=4796

I agree with the comment, you should submit it as a patch on gerrit cm review

code.google.com/p/cyanogenmod/issues/detail?id=4796

Alright, installing git now, let's see if I can use it properly.
I might just submit the easy update to the default config.xml AutoBrightness values. My C++ is pretty crap and I doubt I can tell what's going on with the light sensor code.
That seems like an ugly kludge, but it is an open source project after all...
ERROR - JOKES NOT ALLOWED AS NEW USER

What a pain to sync the entire CM source with my crappy internet connection... the 'repo' script recommended in the Gerrit howto hangs overnight.
Code:
repo init -u git://github.com/CyanogenMod/android.git -b gingerbread
repo sync -j16
Killing and restarting the script seems to start again from scratch, so I'm making no forward progress.
I wonder if there's a way to submit patches to gerrit by way of github or some other remote git hosting service?

While setting up git / repo to submit a change to Gerrit, I learned two things - the G2 / Desire Z has a Capella Microsystems CM3602 Light sensor, and the reason the lux values are screwed up - cyanogen did it!
https://github.com/CyanogenMod/andr...mmit/2b53447ec6b2a3fd3e299428d359b3603db19025
Why, I don't understand. The change reason is "Match lightsensor values to kernel". Anyone know more?

Nice, I saw your gerrit submission here http://review.cyanogenmod.com/#change,12845
I hope it gets some good feedback!

Thanks c00ller, I wish I could have added some explanation to the change submission. It would make it a lot easier for a reviewer to figure out what's going on. The real fix would be to change the Vision's lightsensors values to the standard 10..10240 . But without knowing why cyanogenmod reverted them to 1..1024, there's a lot of potential confusion.

The reason for the change is, like the commit message says:
"Match lightsensor values to kernel"
If you look at the kernel source,
Code:
github.com/CyanogenMod/htc-kernel-msm7x30/blob/android-msm-2.6.35/arch/arm/mach-msm/board-vision.c#L317
you can see that these are exactly those levels:
Code:
static struct microp_function_config microp_lightsensor_function = {
.name = "light_sensor",
.category = MICROP_FUNCTION_LSENSOR,
.levels = { 0x1, 0x3, 0x5, 0x13, 0x1A, 0x45, 0xDB, 0x135, 0x1F2, 0x3FF },
.channel = 3,
.int_pin = 1 << 9,
.golden_adc = 0xC0,
.ls_power = capella_cm3602_power,
};
He probably just forgot to adjust the sensor <-> display level mappings in the config.xml (which is what you did in your patch):
Code:
review.cyanogenmod.com/#change,12845
I tried it and it works fine, and I gave it +1

Aha, thanks for the explanation m0viefreak!
I still don't understand exactly where in the code the hardware sensor outputs should be translated into engineering "lux" units. Libsensors seems like the right place to me (naiive non-programmer).
I'd like to advocate for migrating to the gingerbread light sensor standard, since some cyanogenmod auto brightness functionality assumes its 1..10240 lux light sensor range. For example, the "reset threshold".
Is the kernel code using the obsolete 1..1024 range for reverse-compatibility with froyo?

Thanks for bringing this up. I was actually just wondering if the kb backlight issue on Vision keeps coming up because of incorrect light sensor range.
..although this would seem to suggest that the backlight would be on all the time, rather than never on...anyway

I was going to talk to somebody about this but didn't know who to tell about this issue. The brightness can be right at times but the brightness can be changing every few seconds.
Sent from my HTC Vision using xda premium

Any update on the submitted Gerrit change?
Sent from my HTC Vision using Tapatalk 2 Beta-5

azrash said:
Any update on the submitted Gerrit change?
Sent from my HTC Vision using Tapatalk 2 Beta-5
Click to expand...
Click to collapse
Was wondering the same thing.

Same here.

Would anyone be willing to file a glitch/issue in the CM7 github for me?

Any news on this one?
When the light sensor can work properly, than battery life would also get a boost.
Can someone maybe post a link to a (flashable)file to get the right readings from the light sensor? Or tell me if there's a editable file on the system partition I can manually edit?

Do build.prop tweaks actually work? - A guide

While searching deeper into build.prop tweaks, I came across this article. It was originally posted in Jeff Mixon's blog. At the moment the whole site is inaccessible, so it probably is a good idea to have it in full here (thanks to Google cache).
While its focused on ICS, some of the points made are aplicable to GingerBread too.
Examining build.prop tweaks for Android ICS: A comprehensive guide
(from: http://www.jeffmixon.com/examining-build-prop-tweaks-for-android-ics-a-comprehensive-guide-part-1/)
Android devices are great. They can easily be hacked and tweaked to seemingly no end. There’s a lot of great info out there detailing step-by-step instructions on how to perform various enhancements to your particular device. Unfortunately, there is also a fair amount of misinformation being disseminated via forums and blogs that can have a very negative effect on your device. Just because you can change something doesn’t necessarily mean you should. In this guide, I will walk through various common Android build.prop settings and evaluate whether or not you should actually change them on your Android ICS device, MythBusters style.
windowsmgr.max_events_per_sec – BUSTED
As the name implies, this property specifies how quickly the system is allowed to process certain events before throttling occurs. Specifically, this property is used by the InputDispatcher when processing screen touch and movement events. This value will really only come in to play with extremely rapid touch events, such as swiping or scrolling. The default value for this property is 90, and Google explains why:
Code:
// This number equates to the refresh rate * 1.5. The rate should be at least
// equal to the screen refresh rate. We increase the rate by 50% to compensate for
// the discontinuity between the actual rate that events come in at (they do
// not necessarily come in constantly and are not handled synchronously).
// Ideally, we would use Display.getRefreshRate(), but as this does not necessarily
// return a sensible result, we use '60' as our default assumed refresh rate.
result = 90;
Many build.prop tweaks set this value to 300, but it seems this is a bad idea. As Google points out, Android maxes out at 60fps. The default value is already allow for a possible max_events_per_sec of 90. Even if you allow for 300 max_events_per_sec, you’ll only ever see 60 of these events in any given second. Therefore, any value much higher than 90 is unlikely to have any noticeable impact on your experience in general. Additionally, setting this value too high can starve other UI events that need to get processed, viz. touch inputs. You’re not likely to feel like your device is running very smoothly when it is busy processing thousands of scroll events instead of responding immediately to you clicking to try and open a link or an app. There may be some specific scenarios where increasing this value does appear to improve system feedback, but changing this value for all UI events across the board will likely cause more problems than it will solve.
dalvik.vm.heapgrowthlimit and dalvik.vm.heapsize - BUSTED
Android devices are getting buffer every day and along with that, the amount of RAM devices have available has increased significantly. Devices with 1GB of RAM are now common; some are even equipped with 2GB already.
This is one property that has cropped up recently in various build.prop recommendations for ICS. Typical suggested values range from “48m” all the way up to “256m”, likely motivated by the common misconception that more is better. The real purpose of this property is much less obvious than one might initially guess. It is also another one you should probably avoid changing.
In ICS, the dalvik.vm.heapgrowthlimit property takes over as the effective dalvik.vm.heapsize property. Applications will be restricted to the value set by this property by default. Google has this to say about it:
Code:
// The largest size we permit the heap to grow. This value allows
// the user to limit the heap growth below the maximum size. This
// is a work around until we can dynamically set the maximum size.
// This value can range between the starting size and the maximum
// size but should never be set below the current footprint of the
// heap.
An indeed, we can see this enforced in several places in the Heap and HeapSource structures. Including:
Code:
if (overhead + HEAP_MIN_FREE >= hs->maximumSize) {
LOGE_HEAP("No room to create any more heaps "
"(%zd overhead, %zd max)",
overhead, hs->maximumSize);
return false;
}
heap.maximumSize = hs->growthLimit - overhead;
As we see here, the heap’s maximum size is determined by the growthLimit variable on the HeapSource structure. We can also see a check to ensure there is enough total heap space available to begin with before attempting to create the new heap. At first blush, it looks like like growthLimit (dalvik.vm.heapgrowthlimit) is redundant and synonymous with maxiumSize (dalvik.vm.heapsize). It seems that could set the dalvik.vm.heapgrowthlimit to 64M and the dalvik.vm.heapsize to 256M and only the growthLimit value would be used to govern a heap’s maximum size. That’s where this interesting method comes in:
Code:
/*
* Removes any growth limits. Allows the user to allocate up to the
* maximum heap size.
*/
void dvmClearGrowthLimit()
{
...
gHs->growthLimit = gHs->maximumSize;
size_t overhead = oldHeapOverhead(gHs, false);
gHs->heaps[0].maximumSize = gHs->maximumSize - overhead;
gHs->heaps[0].limit = gHs->heaps[0].base + gHs->heaps[0].maximumSize;
...
}
This method effectively removes any limitation set by dalvik.vm.heapgrowthlimit and sets the maximum heap size to the value defined by dalvik.vm.heapsize (or the hard-coded default of 16M). This method is wired up straight to the Dalvik runtime implementation as a native call and we can see it defined here:
Code:
static void Dalvik_dalvik_system_VMRuntime_clearGrowthLimit(const u4* args, JValue* pResult)
{
dvmClearGrowthLimit();
RETURN_VOID();
}
...
const DalvikNativeMethod dvm_dalvik_system_VMRuntime[] = {
...
{ "clearGrowthLimit", "()V",
Dalvik_dalvik_system_VMRuntime_clearGrowthLimit },
...
};
And if we keep chasing this rabbit “up” the rabbit hole, we can see it finally in action here in the ActivityThread Java class:
Code:
if ((data.appInfo.flags&ApplicationInfo.FLAG_LARGE_HEAP) != 0) {
dalvik.system.VMRuntime.getRuntime().clearGrowthLimit();
}
This flag is set by a relatively new attribute (API level 11) which you can add to the application element in an Android application’s manifest file.
So what does this all mean? The dalvik.vm.heapgrowthlimit property limits how large an Android application’s heap can get before garbage collection has to be attempted. The dalvik.vm.heapsize property defines an absolute maximum for the heap size for an application even when the largeHeap flag is set in the manifest. Google’s motivation behind doing this was clearly to limit the heap size to a reasonable amount for most applications, but also give some flexibility to app developers who know they’re going to need the largest heap size possible to run their application.
Should you change this setting? Probably not. The ICS default for a phone with (at least) 1024MB of RAM is 64m. You can check your specific phone’s value as the hardware vendor can override this themselves when they build the ROM. But don’t let the disparity between 1024 and 64 bother you; most mobile apps should not have any problems with 64MB of heap size unless the developers are naughty. When this limit is reached, a garbage collection routine will remove obsolete objects from memory reducing the heap size down considerably in most cases. It is extremely unlikely raising this value to reduce GC routines will have any perceptible effect. If anything, it could cause other apps or the general system to suffer from too many stale objects sulking around in memory. Garbage collection will inevitably occur either way, and when it does, the size of the heap will likely have a direct impact on the cost of the routine.
The point is, it is impossible for a user to optimize for every application using this system-wide setting. This responsibility falls on application developers to optimize their applications, not users. The largeHeap flag was created to allow developers to do just that. If you do feel compelled to experiment with this setting regardless, be mindful that an application could have up to two heaps at once. Thus, the heap growth limit value should always be, at most, a little less than half of the maximum allowable heap size.
debug.performance.tuning – BUSTED
This property doesn’t appear to exist in the ICS code base. Incidentally, I also don’t see it in Gingerbread (2.3.6). It’s possible this value is specific to only certain custom implementations of Android, such as Cyanogenmod, but as far as I can tell, this one does nothing.
video.accelerate.hw – BUSTED
Again, this one appears to do nothing in ICS.
persist.adb.notify – CONFIRMED
This one disable the USB debugging notification when you have your device connected to a computer. We can see this used here:
Code:
private void updateAdbNotification() {
if (mNotificationManager == null) return;
final int id = com.android.internal.R.string.adb_active_notification_title;
if (mAdbEnabled && mConnected) {
if ("0".equals(SystemProperties.get("persist.adb.notify"))) return;
This is a good one to disable (set to “0″) if you want to declutter your notification bar.
persist.sys.purgeable_assets – BUSTED
This one claims to free up memory, however it is nowhere to be found in the Android code base. This one is a patch made to Cyanogenmod 7 to do some Bitmap hackery. It may not even exist in CM9. Unless you are running CM7, or possibly CM9, this property has no effect.
persist.sys.use_dithering – BUSTED
Another Cyanogenmod-specific property. This will have no effect on stock ICS.
dalvik.vm.execution-mode – BUSTED
This property can set the execution mode of the Dalvik VM. The VM can run in three modes: fast, portable, and very likely JIT. It is possible to compile Android without JIT support, but the default is to include it. In general, JIT is the execution mode you are going to want on your device. This is why you will see most build.prop files setting this property to “init:jit”. However, this is unnecessary since the default execution mode is JIT:
Code:
#if defined(WITH_JIT)
gDvm.executionMode = kExecutionModeJit;
#else
...
As I mentioned before, WITH_JIT compiler flag is set by default in ICS, thus there is no need to define this setting in your build.prop. If WITH_JIT flag was set to false, setting the execution mode to JIT would have no effect anyway.
dalvik.vm.dexopt-flags – PLAUSIBLE
This property can set various options that affect how the Dalvik runtime performs optimization and verification. Suggested values range from turning bytecode verification off completely to enabling object registry mapping and precise garbage collection. Setting “v=n” will turn off bytecode verification, which while in all practicality is unlikely to cause any problems directly, it is a severe violation of the whole Java trust and security model.
On the other hand, setting “m=y” will turn on the register map for tracking objects to garbage collect. Incidentally, this also enables “precise” garbage collection, which, as you may have guessed is a slightly more accurate way to track objects for garbage collection. By accurate we mean less likely to falsely identify an object as still in use when in fact it is no longer being used. This would, in theory, be a more efficient mechanism to free up unused objects, and thus increase available memory (RAM).
Enabling precise GC seems like a good idea as long as your device has the muscle to spare, but I can not find enough information to know for sure what the total implication is to using precise GC versus conservative. I suspect it likely a trade-off of more cpu cycles per collection to obtain more free RAM. You will have to decide which one is more important to you based on your device capabilities and personal tolerance levels. This is assuming that the difference will even be perceptible in a real-world environment, which I suspect would be less than profound, if any at all.
ro.media.dec.jpeg.memcap – BUSTED
This property is one of many that promises to make your audio and visual experience better. Unfortunately, not only is it only related to JPEG decompression, it is completely unused in ICS (and Gingerbread for that matter) and has no effect on your device.
At first, it looks kind of promising:
Code:
// Key to lookup the size of memory buffer set in system property
static const char KEY_MEM_CAP[] = "ro.media.dec.jpeg.memcap";
Ok, cool. The property exists at least. However, that’s the only place this is referenced. The KEY_MEM_CAP is never used anywhere. If we look a little closer, we’ll come across this:
Code:
/* Check if the memory cap property is set.
If so, use the memory size for jpeg decode.
*/
static void overwrite_mem_buffer_size(j_decompress_ptr cinfo) {
#ifdef ANDROID_LARGE_MEMORY_DEVICE
cinfo->mem->max_memory_to_use = 30 * 1024 * 1024;
#else
cinfo->mem->max_memory_to_use = 5 * 1024 * 1024;
#endif
}
This looks like exactly where this property should be used, but isn’t. The value is clearly hardcoded here. In fact, if we look up the Skia project source tree on Google code, we can see that the latest version has this variable commented out now with the following comment:
Code:
/* For non-ndk builds we could look at the system's jpeg memory cap and use it
* if it is set. However, for now we will use the NDK compliant hardcoded values
*/
//#include <cutils/properties.h>
//static const char KEY_MEM_CAP[] = "ro.media.dec.jpeg.memcap";
ro.media.enc.hprof.vid.bps – CONFIRMED
This one is generally grouped together as a general “media” enhancement tweak. This particular property controls the “high” bit rate at which videos are encoded using the Android stock camera application. That means if you are using a third party camera app, this setting will have no effect. Let’s take a look at the snippet.
Code:
mVideoBitrate = getInt("ro.media.enc.hprof.vid.bps",
"ro.media.enc.lprof.vid.bps",
360000, 192000);
While the default values may seem very low, these are very unlikely to ever be necessary. When a device manufacturer deploys the production ROM, they will define many properties in a different property file (viz. “system.prop”), which will contain values specific to the hardware. Those values are going to be used instead of the hard coded ones we see here.
For example, if I launch a shell on a Galaxy S3 and run the following command:
Code:
getprop ro.media.enc.hprof.vid.bps
I will get a value back of “12000000″, even though I do not have this property defined in my build.prop. This is because it was defined in the default.prop file by Samsung knowing the capabilities of the device and the camera.
This setting can definitely be useful if these values are important to you, just be sure you’re not setting the value to the same (or worse yet lower!) than what is already defined on your device. While you’re at it, you may want to tweak some of the other values:
Code:
ro.media.enc.hprof.aud.bps
ro.media.enc.hprof.codec.vid
ro.media.enc.hprof.codec.aud
ro.media.enc.hprof.aud.hz
The names are pretty self-explanatory, but you can find out more info about each one with a little bit of Google’ing.
Summary
The build.prop file is a powerful tool for root users to modify the behavior of various aspects of the Android experience. However, there are no secret values here that are going to instantly make your phone run faster, better, smarter, or more efficiently. In fact, if you don’t know what you are doing, you can actually decrease the performance of your device. Over time I will investigate more build.prop properties to determine which ones can actually enhance your Android experience and which ones only create a placebo effect.

Nice But...
We all know the .prop is powerful but certainly it doesn't mean you can't modify strings to get your Rom/phone to run faster, in that case you're busted " Meaning as in by the person who had posted this" Not you xda guy xD.
If you are running ICS or GB try this out : Add it to the bottom of your build.prop string after the last string...
# dalvik props
dalvik.vm.heapstartsize=5m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=128m
windowsmgr.max_events_per_sec=240
debug.enabletr=true
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000
ro.ril.disable.power.collapse=1
ro.telephony.call_ring.delay=0
persist.adb.notify=0
dalvik.vm.dexopt-flags m=y,o=v,u=y
#Render UI with GPU
debug.sf.hw=1
#debug.composition.type=gpu
debug.composition.type=c2d
debug.performance.tuning=1
debug.enabletr=true
debug.qctwa.preservebuf=1
dev.pm.dyn_samplingrate=1
video.accelerate.hw=1
ro.vold.umsdirtyratio=20
debug.overlayui.enable=1
debug.egl.hw=1
ro.fb.mode=1
hw3d.force=1
persist.sys.composition.type=c2d
persist.sys.ui.hw=1
ro.sf.compbypass.enable=0
# persist.sys.shutdown.mode=hibernate
ro.config.hw_quickpoweron=true
ro.lge.proximity.delay=25
mot.proximity.delay=25
ro.mot.buttonlight.timeout=0
If you are running GB : Remove the following strings from above...
#Render UI with GPU
debug.sf.hw=1
Now watch the magic

krishneelg3 said:
We all know the .prop is powerful but certainly it doesn't mean you can't modify strings to get your Rom/phone to run faster, in that case you're busted " Meaning as in by the person who had posted this" Not you xda guy xD.
If you are running ICS or GB try this out : Add it to the bottom of your build.prop string after the last string...
# dalvik props
dalvik.vm.heapstartsize=5m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=128m
windowsmgr.max_events_per_sec=240
debug.enabletr=true
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000
ro.ril.disable.power.collapse=1
ro.telephony.call_ring.delay=0
persist.adb.notify=0
dalvik.vm.dexopt-flags m=y,o=v,u=y
#Render UI with GPU
debug.sf.hw=1
#debug.composition.type=gpu
debug.composition.type=c2d
debug.performance.tuning=1
debug.enabletr=true
debug.qctwa.preservebuf=1
dev.pm.dyn_samplingrate=1
video.accelerate.hw=1
ro.vold.umsdirtyratio=20
debug.overlayui.enable=1
debug.egl.hw=1
ro.fb.mode=1
hw3d.force=1
persist.sys.composition.type=c2d
persist.sys.ui.hw=1
ro.sf.compbypass.enable=0
# persist.sys.shutdown.mode=hibernate
ro.config.hw_quickpoweron=true
ro.lge.proximity.delay=25
mot.proximity.delay=25
ro.mot.buttonlight.timeout=0
If you are running GB : Remove the following strings from above...
#Render UI with GPU
debug.sf.hw=1
Now watch the magic
Click to expand...
Click to collapse
Incresing hp to 128 your battery is going down like a hell
Sent from my E15i using xda premium

It work 200%
If u do it correctly
I increased my GPRS class from 10 to 12
And it work
Tested on mini cm10
if I helped press thanks :thumbup:

ElmirBuljubasic said:
Incresing hp to 128 your battery is going down like a hell
Sent from my E15i using xda premium
Click to expand...
Click to collapse
Elmir what's a good setting 120? 110?
Sent from my Ascend G300 using Tapatalk 2

ro.HOME_APP_ADJ=0 This line sends the settings app to cache and frees some RAM in addition to blocking the Xperia launcher to not restart when leaving a heavy application.
this line works on GB
sorry for my bad English

Nice copy and paste

Great :thumbup:
Sent from my E15i using xda app-developers app

ALSA from chroot -- Audio for the other side

First, a short story
After installing a chroot debian on my s2 I noticed that vlc player isn't working.
Sadly it took me several weeks to notice that sound in general wasn't working at all.
Problem: There was simply nowhere to output the sound.
So I tried to get alsa working from chroot to get some form of audio output.
and here it is.
ALSA ON CHROOT LINUX
The bumpy road to half broken (and therefore other half working) linux audio​
Once you have a working chroot (with correct mounts that is), download and install the following packages:
Code:
alsa-base alsa-oss alsa-utils
Now run
Code:
alsamixer
to open the alsa sound mixer.
There you should unmute
Code:
DL1 MM_EXT DL1 Mixer Multimedia DL1 PDM
Then set
Code:
HS Left
and
Code:
HS Right
to
Code:
HS DAC
This should enable headset output
ALso unmute
Code:
Earphone
to well....use the Earphone speaker.
To enable the Main speaker, unmute
Code:
DL2 Mixer Multimedia DL2 Mono
And set
Code:
HF Right
and
Code:
HF Left
to
Code:
HF DAC
For other devices, this section will be different. Just look through alsamixer and try to make sense of the countless options there.
Finished more or less.
Now you can play audio from chroot.:victory:
Notice: If you run any sound from android or plug the headset in/out, you need to reapply these settings.
To avoid that I run a script that continously re-enables the mentioned settings. (mainly the headset)
It looks something like this
Code:
#!/bin/bash
while true; do
[INDENT]
amixer -c 0 csent numid=74 1
amixer -c 0 csent numid=73 1
amixer -c 0 csent numid=35 1
amixer -c 0 csent numid=52 1
amixer -c 0 csent numid=33 1
sleep 0.5
[/INDENT]
done
This probably isn't the best way of doing it (it might actually be the worst), but it works.
It might put load on the cpu or it might not, but for me, running this decreases my SoD frequency. (idek why)
Also the best way to run the script is a few seconds after the system started using the "nohup" command. That way you can run it and close the terminal and it will still be active. To kill it, search its pid using
Code:
ps -x
and kill it with
Code:
kill (insert pid here)
If you want you can also run it as a start up script.
Though if you do that, you might see that it runs but doesn't do anything.
Don't panic. Or do if you want to.
But just restart the script anyways.
OPTIONAL: (because I force you to use the stuff above)
We can play no more than ONE audio source at a time
Soloution: PulseAudio
(I will fill this shortly....)
(there is also MPD which works...)
So for now we have
Solution 2: Dmixer
Dmixer is what it name sounds like. It downmixes multiple sources into a single audio stream.
And it works (sometimes).
So here is how to.
Simply copy the content of the file below into a new file called .asoundrc in /home/username
Code:
pcm.!default {
type plug
slave.pcm "dmixer"
}
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
}
bindings {
0 0
1 1
}
}
ctl.dmixer {
type hw
card 0
}
This one is mainly pulled directly from the alsa project site and should work most of the time.
hw:0,0 might need changing on different devices. Same with card 0.
run
Code:
aplay -l
and use that to find the correct card and device.
???
The standard: I am not responsible for anything that happens to you, your phone or anything else.
Also I didn't invent any of this stuff myself. All credit goes to the original developers.
I just wrote this guide (if you can call it that)
Oh...and if you can't understand my english, well.... I'm sorry but i can't do better.

ruleh said:
First, a short story
After installing a chroot debian on my s2 I noticed that vlc player isn't working.
Sadly it took me several weeks to notice that sound in general wasn't working at all.
Problem: There was simply nowhere to output the sound.
So I tried to get alsa working from chroot to get some form of audio output.
and here it is.
ALSA ON CHROOT LINUX
The bumpy road to half broken (and therefore other half working) linux audio​
Once you have a working chroot (with correct mounts that is), download and install the following packages:
Code:
alsa-base alsa-oss alsa-utils
Now run
Code:
alsamixer
to open the alsa sound mixer.
There you should unmute
Code:
DL1 MM_EXT DL1 Mixer Multimedia DL1 PDM
Then set
Code:
HS Left
and
Code:
HS Right
to
Code:
HS DAC
This should enable headset output
ALso unmute
Code:
Earphone
to well....use the Earphone speaker.
To enable the Main speaker, unmute
Code:
DL2 Mixer Multimedia DL2 Mono
And set
Code:
HF Right
and
Code:
HF Left
to
Code:
HF DAC
For other devices, this section will be different. Just look through alsamixer and try to make sense of the countless options there.
Finished more or less.
Now you can play audio from chroot.:victory:
Notice: If you run any sound from android or plug the headset in/out, you need to reapply these settings.
To avoid that I run a script that continously re-enables the mentioned settings. (mainly the headset)
It looks something like this
Code:
#!/bin/bash
while true; do
[INDENT]
amixer -c 0 csent numid=74 1
amixer -c 0 csent numid=73 1
amixer -c 0 csent numid=35 1
amixer -c 0 csent numid=52 1
amixer -c 0 csent numid=33 1
sleep 0.5
[/INDENT]
done
This probably isn't the best way of doing it (it might actually be the worst), but it works.
It might put load on the cpu or it might not, but for me, running this decreases my SoD frequency. (idek why)
Also the best way to run the script is a few seconds after the system started using the "nohup" command. That way you can run it and close the terminal and it will still be active. To kill it, search its pid using
Code:
ps -x
and kill it with
Code:
kill (insert pid here)
If you want you can also run it as a start up script.
Though if you do that, you might see that it runs but doesn't do anything.
Don't panic. Or do if you want to.
But just restart the script anyways.
OPTIONAL: (because I force you to use the stuff above)
We can play no more than ONE audio source at a time
Soloution: PulseAudio
Or so I thought... I can't seem to get it working. If someone can, please tell me how to.
So instead we have
Solution 2: Dmixer
Dmixer is what it name sounds like. It downmixes multiple sources into a single audio stream.
And it works (sometimes).
So here is how to.
Simply copy the content of the file below into a new file called .asoundrc in /home/username
Code:
pcm.!default {
type plug
slave.pcm "dmixer"
}
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
}
bindings {
0 0
1 1
}
}
ctl.dmixer {
type hw
card 0
}
This one is mainly pulled directly from the alsa project site and should work most of the time.
hw:0,0 might need changing on different devices. Same with card 0.
run
Code:
aplay -l
and use that to find the correct card and device.
???
The standard: I am not responsible for anything that happens to you, your phone or anything else.
Also I didn't invent any of this stuff myself. All credit goes to the original developers.
I just wrote this guide (if you can call it that)
Oh...and if you can't understand my english, well.... I'm sorry but i can't do better.
Click to expand...
Click to collapse
To use Pulseaudio, I found someone who used the Simple Protocol module to get sound and I'm now able to use MPD + MPDroid to play music from my Arch Linux chroot. Unfortunately, the playback get choppy when I open a on a single core phone with less that 1GB of RAM so if you have a better device, I'm sure the playback will be way better!
The phone I'm using is a Samsung Galaxy Ace II X (GT-S7560M) with LinuxDeploy (and CM11)
http://kaytat.com/blog/?page_id=301

TheST4RL said:
To use Pulseaudio, I found someone you used the Simple Protocol module to get sound and I'm now able to use MPD + MPDroid to play music from my Arch Linux chroot. Unfortunately, the playback get choppy when I open a on a single core phone with less that 1GB of RAM so if you have a better device, I'm sure the playback will be way better!
The phone I'm using is a Samsung Galaxy Ace II X (GT-S7560M) with LinuxDeploy (and CM11)
http://kaytat.com/blog/?page_id=301
Click to expand...
Click to collapse
I wish you would have told me this yesterday.
I spend all of yesterday doing the simple protocol player method. (It works on a quadcore 4gb phone.)
However I still prefer the alsa method on low performance phones because it has nearly no latency and is very smooth.
I will try the MPD method and see how it goes.

ruleh said:
I wish you would have told me this yesterday.
I spend all of yesterday doing the simple protocol player method. (It works on a quadcore 4gb phone.)
However I still prefer the alsa method on low performance phones because it has nearly no latency and is very smooth.
I will try the MPD method and see how it goes.
Click to expand...
Click to collapse
I tried ALSA today and it's working but the playback is super choppy and when I listen to music the audio is slower when compared to the real one. Pulseaudio may have some latency but if you're listening to music, it doesn't really matters.

[32-bit] Google Camera 3.2.045 (HDR+) for stock Albus (MZ2P) v2F [28-Feb-2019]

I based my work on MGC_3.2.045_RazerPhone2_V1 by BSG.
It's a working Modded Google Camera for stock rom (works on custom too) heavily improved.
• Requirements:
Camera2 API enabled.
Click to expand...
Click to collapse
Set: persist.camera.HAL3.enabled 1 into your build.prop or use this Magisk Module.
• Installation:
Install as normal apk, open it, enter to 'resolution & quality' and disable video stabilization. Restart the app (force close it or restart your phone).
Click to expand...
Click to collapse
• Changelog:
Based on MGC_3.2.045_RazerPhone2_V1 by BSG.
Changes by developer (BSG):
- Added custom saturation settings.
- Added custom denoise settings.
- Added option to restrict exposure time.
- Removed flash option due to constants sync issues.
Changes by me (v2F):
- Set default custom denoise parameters for Albus/Potter.
- Tweaked GcammoduleJNI (combined with BSG 6.1.021).
- Took Hot Pixels parameters from BSG 6.1.021.
- Took Spatial Gain Map from BSG 6.1.0.21.
- Fixed gray shutter issue.
- Fixed AF and TF for Albus/Potter.
- Added new round icon.
- Package name changed to avoid conflicts with other GCams.
* When you launch the app for first time,
enter to settings and forceclose the app.
If you don't do it firts shots will have a pixelated process.
Click to expand...
Click to collapse
• Important tips:
- Recommended settings for LOW LIGHT scenes (like night shots):
- Correction of auto-exposure HDR+: Increase exp. to 8 or Min. ISO.
- Restrict correction exposure: 1/4s.
- HDR+ parameters: Super High.
- Recommended settings for GOOD LIGHT scenes:
- Correction of auto-exposure HDR+: Off 8 or Increase exp. to 2.
- Restrict correction exposure: 1/4s.
- HDR+ parameters: Medium/High.
• Download link:
3.2(HDR+)Albus_v2F-Moonlightdrive
Thanks to:
BSG
Credits:
BSG, Moonlightdrive.

Reserved.

Is it for moto z2 play stock ROM ?

thx... first try: only slowmo doenst work...as far as i can see
@C4mine: yes, stock is 32bit!
:cyclops:​

Installed on my z2 play but when I open, after swipe left on the "tutorial", it crashes, giving the message "cannot connect to camera". I tried reinstall, force closing, restart the phone, nothing works.

evandromon said:
Installed on my z2 play but when I open, after swipe left on the "tutorial", it crashes, giving the message "cannot connect to camera". I tried reinstall, force closing, restart the phone, nothing works.
Click to expand...
Click to collapse
You need to enable Camera2 API first, and when in the 'tutorial": rapidly change to photo mode. Don't stand more than a second in video mode cause it will crash/hang because video stabilization is not disabled.

can somebody post examples from this app and stock app, rooting this device is a pure mess, i would like to see is it worth it... thanks in advance

moonlightdrive said:
You need to enable Camera2 API first, and when in the 'tutorial": rapidly change to photo mode. Don't stand more than a second in video mode cause it will crash/hang because video stabilization is not disabled.
Click to expand...
Click to collapse
sorry for the dumb question, but how do I do this?

tried this on my redmi go force close upon clicking settings

samsungics1200 said:
tried this on my redmi go force close upon clicking settings
Click to expand...
Click to collapse
Go cry in the Redmi forum

I just tried it on Potter and focus isn't working on pictures, works on video. Also noticed that since bsg 3.2.045 v3.2 focus isn't working, in previous versions it works.

Fedray said:
I just tried it on Potter and focus isn't working on pictures, works on video. Also noticed that since bsg 3.2.045 v3.2 focus isn't working, in previous versions it works.
Click to expand...
Click to collapse
Can confirm AF and TF do work on Moto G5+ (Potter), my work is shared on Moto G5+ Camera development Telegram group (since Albus and potter shares same camera sensor: IMX362RS), this app was heavily tested by G5+ users (custom and stock users).
Be sure that your device is properly named (inside build.prop and default.prop) as a 'potter', it's needed due to Pixel phones uses different focus parameters, unlike Lenovo which uses ZAF, and modded gcams for these devices (a few others like Xiaomis too) needs to be modified/patched in order to focus.
In this case:
Code:
.method public BadTF()I
.locals 3
const-string v1, "[B]potter[/B]"
invoke-virtual {v1, v0}, Ljava/lang/String;->equals(Ljava/lang/Object;)Z
move-result v2
if-nez v2, :cond_0
const-string v1, "[B]albus[/B]"
invoke-virtual {v1, v0}, Ljava/lang/String;->equals(Ljava/lang/Object;)Z
move-result v2
if-nez v2, :cond_0
const/4 v2, -0x1
:goto_0
return v2
:cond_0
const/4 v2, 0x0
goto :goto_0
.end method
Long story short: if your device is named as 'potter' this must work. Hope it helps.:good:

moonlightdrive said:
Can confirm AF and TF do work on Moto G5+ (Potter), my work is shared on Moto G5+ Camera development Telegram group (since Albus and potter shares same camera sensor: IMX362RS), this app was heavily tested by G5+ users (custom and stock users).
Be sure that your device is properly named (inside build.prop and default.prop) as a 'potter', it's needed due to Pixel phones uses different focus parameters, unlike Lenovo which uses ZAF, and modded gcams for these devices (a few others like Xiaomis too) needs to be modified/patched in order to focus.
In this case:
Long story short: if your device is named as 'potter' this must work. Hope it helps.:good:
Click to expand...
Click to collapse
Can you help me with what lines need to tell potter? I'm on stock 7.0 and like I said it doesn't focus at all, only in videos.
This is what I have found in build.prop
ro.product.model=Moto G (5) Plus
ro.product.brand=motorola
ro.product.name=potter_retail
ro.product.device=potter
Nothing like that in default.prop
Edit: noticed that with hdr off focus works, when I enable it or set to auto then focus stops working

my hdr+ photos turn out purple.
moonlightdrive said:
Reserved.
Click to expand...
Click to collapse
my hdr photos turn out purple. And sometimes it does not work. I use J7 prime, i tested the app to see if my camera2api is enable or not, and this is enabled. You can help me? (Sorry for my bad english)

Abilrifor said:
my hdr photos turn out purple. And sometimes it does not work. I use J7 prime, i tested the app to see if my camera2api is enable or not, and this is enabled. You can help me? (Sorry for my bad english)
Click to expand...
Click to collapse
Go to you J7 prime forum and cry.

Link is down. Any chance we can get a mirror or something?

Confirmed not working properly on US Retail XT1710-01 Android Pie 9.0. Imahe has artifacts, settings crashes app, and video freezes up.

Knuxyl said:
Confirmed not working properly on US Retail XT1710-01 Android Pie 9.0. Imahe has artifacts, settings crashes app, and video freezes up.
Click to expand...
Click to collapse
Installation:
Quote:
Install as normal apk, open it, enter to 'resolution & quality' and disable video stabilization. Restart the app (force close it or restart your phone).
Click to expand...
Click to collapse
Read OP installation instructions first. You must do that (it's mandatory), otherwise you will face those issue you described. This app is widely tested on this device.
Edit: do not forget to enable API2.

Knuxyl said:
Confirmed not working properly on US Retail XT1710-01 Android Pie 9.0. Imahe has artifacts, settings crashes app, and video freezes up.
Click to expand...
Click to collapse
Neither BR Retail Pie, has the same problems as mentioned.

I'm on US retail Pie as well and I get artifacts in the preview and on photographs. Stabilization was disabled from before the upgrade (which was when it worked just fine). I cleared app data, but the artifacts persist and the app crashes when I try to go to settings. Please excuse the fact that I'm uploading screenshots of the photographs; I haven't found a quick way to erase the location metadata from the originals and I figured the screenshots wouldn't have that in the first place. The windowsill photograph was taken before clearing data (i.e. with stabilization disabled) and the one of wood afterwards (i.e. with stabilization enabled).