All,
There seems to be a huge variation in the battery life people are experiencing with the Leo/HD2 in "normal" everyday use, as can be seen in these threads:
http://forum.xda-developers.com/showthread.php?t=585729
http://forum.xda-developers.com/showthread.php?t=583338
While usage definitely varies by for each poster in those threads so does the subjective opinion of battery use over time.
I therefore wrote a very small, simple application that uses the Compact Framework 3.5 State and Notification Broker plus PInvoke calls to monitor various system and battery state notifications.
Using a very simple configuration file (named the same as the 'exe' file), it is possible to make the application record various notifications which it will display on screen and write to a file in the local directory (this is configurable but I haven't tested it yet so its undocumented) named "Monitor [datetime].csv". The default configuration file is as follows:
Code:
<Configuration>
<Monitors>
<BatteryMonitor name="Battery %" interval="60"/>
<SystemMonitor name="Battery Level" property="PowerBatteryStrength" type="BatteryLevel"/>
<SystemMonitor name="Battery State" property="PowerBatteryState" type="BatteryState"/>
<SystemMonitor name="Active Calls" property="PhoneActiveCallCount" type="Integer"/>
<SystemMonitor name="Active Data" property="PhoneActiveDataCall" type="Boolean"/>
</Monitors>
</Configuration>
This sets up battery polling every sixty seconds, registration for battery strength and state notifications along with recording the active calls and whether a data connection is active. This configuration file can be extended to include pretty much any of the state and notification broker properties although my testing of values other than the above has been limited (hey, I wrote this thing in like 3 hours!).
It is envisioned that, once the app has been running for a while, you will be able to load the csv into Excel and chart the power usage of your device.
Attached, I have added a screen shot of the app, a cab file for installing PowerManager (it is unsigned but installs fine on my HD2 after accepting the confirmation) and a zip file containing the source code (note, dependencies are not included - but I imagine the more determined out there will be able to get hold of them ;0).
PREREQUISITES: .net Compact Framework 3.5
USUAL DISCLAIMER: I take no responsibility for any problems you may experience during or subsequent to using this software. It works quite happily on my HD2 and I only post it in case it is of interest to others. You have been warned!
KNOWN ISSUES: The first recorded value for system monitors is always trash for some reason (when using SystemState.CurrentValue). Subsequent changes to these values provide correct values.
Any questions please feel free to ask (although I probably won't get round to checking this thread until tomorrow evening).
Cheers,
Ian
http://forum.xda-developers.com/showthread.php?p=24233846
Just download the attached zip file according to your need, add apps.. flash.. enjoy.. Tested with cwm 5.0.2.7 touch..
********************************************************************************************************************************************************
Editing build.prop.
Even though some of the things are well known for us, some of them are new for me..So im jus posting it.
1.Force launcher into memory
Property
ro.HOME_APP_ADJ = 1
Function
This will force the Default launcher into memory. But your device should be having enough free memory, otherwise you will meet lags and performance will be reduced severely. Use a light weight launcher for this.
Values
0 : Turns off the feature. Frees up memory.
1: Keeps the default launcher in memory .Will have highest priority and Android auto kills it only when it’s really necessary.
2.Improving Camera Image quality
Property
ro.media.enc.jpeg.quality=100
Function
This will force the camera application to use 100% quality setting when saving camera images as JPEG
Values
1-100 : with 1 as the worst quality and 100 as the best quality.
3.Increase resolution of panorama image
Property
ro.media.panorama.defres=3264x1840
ro.media.panorama.frameres=1280x720
Function
This will force the panorama mode in the camera app to save the image at a higher resolution. This may not be supported by all phones. And since it is an Android 4.0 feature , you will need that android version as well.
Values
defres: Provide the full panorama image resolution.Consisting of all images.
frameres: Provide the resolution of each frame of panorama.
4.Improve performance in video playback and streaming
Property
media.stagefright.enable-player=true
media.stagefright.enable-meta=true
media.stagefright.enable-scan=true
media.stagefright.enable-http=true
media.stagefright.enable-rtsp=true
media.stagefright.enable-record=true
Function
Android uses the media framework named “Stagefright” from Froyo ( Android 2.2 ) onwards. While Stagefright is more open and simple, it is sometimes buggy compared to the previously used OpenCore framework. However, Google has greatly improved its stability. These values might affect the stability of playback in some devices, if it is ruining your experience , then revert to the original values.
5.Improve touch responsiveness through Hardware Rendering
Property
debug.sf.hw=1
persist.sys.ui.hw=1
debug.performance.tuning=1
video.accelerate.hw=1
debug.egl.profiler=1
debug.egl.hw=1
debug.composition.type=gpu
Function
This will force the system to use GPU for rendering each 2D frame in applications. Since android uses frame by frame rendering of the screen normally, this will offload the rendering to GPU by a huge amount and will make the user experience smoother.
Values
debug.composition.type values : GPU / CPU . GPU will make use of the graphic chip on your device for rendering each frame.
6.Disable Error Profiler
Property
profiler.force_disable_err_rpt=1
profiler.force_disable_ulog=1
Function
These commands enable or disable the error profiler in the android. For most android users, there is no use in having error profiling . however , some applications might make use of this for generating error reports.
Values
0 :Enable the feature. Better to delete the property if you don’t want to disable it.
1: Disables the feature.
7.Modify WiFi network scanning time.
Property
wifi.supplicant_scan_interval=180
Function
This command will be already present in all build.prop files. This controls the number of seconds the device waits before scanning for WiFi networks.
Values
Default value is 180 . It is in seconds . You can increase the value if you want to save more battery and doesn’t use WiFi extensively. Or else , you can decrease it , if you are dropping your WiFi signal often.
8.Disable logcat – Android Logger
Property
logcat.live=disable
Function
This command controls the Android Logcat file generation. This file is mainly used for debugging. Expensive disk reads/writes can be reduced by disabling Android logcat.
Values
disable / enable
9.Improve Voice Call clarity
Property
ro.ril.enable.amr.wideband=1
Function
This command controls the AMR audio codec’s property.AMR codec is used for voice calls.
Values
1 or 0 .
10.Disable Extended JNI Checks
Property
ro.kernel.android.checkjni=0
ro.kernel.checkjni=0
Function
“JNI does very little error checking. Errors usually result in a crash. Android also offers a mode called CheckJNI, where the JavaVM and JNIEnv function table pointers are switched to tables of functions that do an extended series of checks before calling the standard implementation.” . That’s the definition from Android developers documentation. While disabling this may cause some data loss when the application crashes, most applications ,which are popular, have been thoroughly checked and hence will be using precious CPU time for extended checks . Save that time by disabling this.
Values
0 / 1 : disable / enable .
11.Disable Android Device Check In.
Property
ro.config.nocheckin=1
Function
Every Android device checks in at the Google Servers when an internet connection is found, this helps Google in tracking the number of installations and the statistics of different android versions. This can be disabled to save for saving traffic and some CPU time, due to the frequent polling for checking internet connection.
Values
1/0 for disabling and enabling , respectively.
12.Increase Voice Call Audio Adjustment Steps.
Property
ro.config.vc_call_steps=20
Function
By Default, android offers seven audio levels for calls. This can be altered through this command , if you want to fine adjust the volume of your voice calls. This won’t increase the volume if it’s already low. But you can manage it by more precisely.
Values
Number of steps as integers. 7-20 is recommended. 7 is the default.
Editing Build.Prop
For editing build.prop, your device should be rooted. That’s the first requirement.
It is at /system/
If you have Root Explorer / ES File Explorer installed on your device you can edit from the device itself. More easier method is to get he application named build.prop Editor . It can be used to change the values and add new fields.
works only in cm10 based roms.
Souron29 said:
works only in cm10 based roms.
Click to expand...
Click to collapse
Of course
doesn't CM10 Rom for O1 include this? U posted it separately so thought might be working with CM9 or CM7
Souron29 said:
works only in cm10 based roms.
Click to expand...
Click to collapse
Then what is the point?
Sent from my LG-P500
This tread should be named as:[APP][CM10] messaging app with quick reply, popup notifications
Sent from my LG-P500 using xda premium
It has been taken from the latest nightly.. I dono whether our cm10 build by rashed have this..:laugh:
carrthee89 said:
It has been taken from the latest nightly.. I dono whether our cm10 build by rashed have this..:laugh:
Click to expand...
Click to collapse
I think we have this
Sent from my LG-P500 using Tapatalk 2
Bump.Now the thread is usefull
Sent from my LG-P500 using xda premium
Updated with build.prop optimizations
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
Hi there,
I'm developing an app that calculates an algorithm at the background. Since the application starts, till it ends.
This is a tracking algorithm (with now further explanation about the algorithm operation principles).
So the background task need to be calculated at all screens on the app regardless of user actions on app, clicks, wifi communication messages (already done on app) , everything needs to be done while the algorithm is running at the background.
Is it an AsyncTask ?
If not what else?
The application is running and the algorithm is being calculated at a specific screen now, i want to make it a background process with no respect to current application screen.
An example will be appreciated
P.S- Further developing , do not need to be discussed if not needed right now:
1. The next stage is to insert an indication (virtual bulb) that change between to states depends on algorithm result each time.
2. The algorithm is getting data from USB device attached to the phone as the phone is the host using FTDI chip.
Seems like running the algorithm in a classic Service could be a way to go.
Mine are big:7, little:6
The ASV levels determine the quality of your CPU. These numbers are relevant if you want to overclock or undervolt.
How to find out the ASV levels of your phone? Use a root browser and open this file: /sys/kernel/debug/asv_summary or you can check it with Synapse.
Big 10,little 10
Big: 9, little : 8
How do I find this out in android 10? one UI v2? It doesn't show it on the downloader screen, and synapse doesn't work