Database Develop

[PROJECT] Get Full Market In 240x320 Resolution - ** SOLVED **

Lets use our community and collaborate around achieving a solution to a full market with all applications available for download with no restrictions based upon our current resolution.
Spawned from discussion from this thread
A Primer From jnadke
jnadke said:
It's a problem with the Android SDK.
Starting with 1.6, Google introduced screen sizes: Small, Medium, and Large. Our devices have Small Screens (along with the HTC Tattoo). The G1/Dream has a Medium screen, and the Droid/Nexus a Large screen.
The problem is the SDK defaults to Medium and Large screens. It's up to the application developer to test the application for Small screens and proactively add the indicator for Small screen support.
Most developers never bother to indicate the app can run on Small screens, so it gets excluded from your view.
I'm not sure if the small screen thing is linked to the /data or your Google user account. If I knew which, I'd figure out some way to spoof it, so we can get the full market on small screens. If it's on the /data somewhere, then that's a much easier fix.
The fact that clearing your /data and booting up a 480x320 fixes it, seems to indicate it's a value in the /data. It'd be interesting to do a dump of two /data directories with only the market resolution changed and see how they differ on a binary level. Then perhaps we can add a patch to the menu of NoMoRootfs (or a patch that's applied every bootup... or lock down the file that's modified).
If it's on the account, then either you'd have to intercept the Market App's data packet that indicates screen size and modify it proactively, or you'd have to change parts of the SDK to report the screen size as larger than it really is (this would be hard to do because apps use that interface too... you'd have to be able to detect if the request is coming from the Market App).
Click to expand...
Click to collapse
Here is the original 1.6 Vending.apk and de-compiled BakSmali source.
For those not familiar with smali/baksmali here is a short tutorial:
Download the baksmali/smali tools here
Make your changes in the source than recompile the changes back into the Vending.apk by doing the following:
1.) Make changes to files in source and use smali to re-assemble file:
# java -Xmx512M -jar smali.jar -o classes.dex out/*
2.) Then add classes.dex back into the APK with your favorite archive tool (Winzip, Winrar, etc) or via command line like this:
# zip Vending.apk classes.dex
3.) Push the new Vending.apk back out to your device and test out the Vending application.
# adb shell mount -o remount,rw /system
# adb push Vending.apk /system/app
# adb shell mount -o remount,rw /system
Ready set go!
EDIT: This has now been solved by moneytoo in the Tattoo forums
Links:
Link to moneytoo's thread on Tattoo forum
Mirror

myn said:
Lets use our community and collaborate around achieving a solution to a full market with all applications available for download with no restrictions based upon our current resolution.
Spawned from discussion from this thread
A Primer From jnadke
Here is the original 1.6 Vending.apk and de-compiled BakSmali source.
For those not familiar with smali/baksmali here is a short tutorial:
Download the baksmali/smali tools here
Make your changes in the source than recompile the changes back into the Vending.apk by doing the following:
1.) Make changes to files in source and use smali to re-assemble file:
# java -Xmx512M -jar smali.jar -o classes.dex out/*
2.) Then add classes.dex back into the APK with your favorite archive tool (Winzip, Winrar, etc) or via command line like this:
# zip Vending.apk classes.dex
3.) Push the new Vending.apk back out to your device and test out the Vending application.
# adb shell mount -o remount,rw /system
# adb push Vending.apk /system/app
# adb shell mount -o remount,rw /system
Ready set go!
Click to expand...
Click to collapse
Excited to see this solved! I know the brainpower is in this community to do it. Also, if this is solved I bet it could somehow be replicated/ported for tattoo or other qvga androiders and the vogue-android community would get a lot of praise for this.

Before someone chimes in, this is about getting the market to work without the 320x480 trick. The 320x480 trick tends to reset after a few days (which may help debugging if we can figure out why).

Fixing this Market/resolution issue is at the top of my wish.

jnadke said:
Before someone chimes in, this is about getting the market to work without the 320x480 trick. The 320x480 trick tends to reset after a few days (which may help debugging if we can figure out why).
Click to expand...
Click to collapse
interestingly, after using the 320x480 trick about a month ago, my market has not reset. I did it with plemen's evolution donut, an earlier version that had experimental settings in the build.prop which broke google voice (the program would not even run with that build for some reason). been using the same data.img, but various builds since then, and I have FULL market the whole time.

tatnai said:
interestingly, after using the 320x480 trick about a month ago, my market has not reset. I did it with plemen's evolution donut, an earlier version that had experimental settings in the build.prop which broke google voice (the program would not even run with that build for some reason). been using the same data.img, but various builds since then, and I have FULL market the whole time.
Click to expand...
Click to collapse
hrm.. Very interesting indeed..

tatnai said:
interestingly, after using the 320x480 trick about a month ago, my market has not reset. I did it with plemen's evolution donut, an earlier version that had experimental settings in the build.prop which broke google voice (the program would not even run with that build for some reason). been using the same data.img, but various builds since then, and I have FULL market the whole time.
Click to expand...
Click to collapse
Can you post the build.prop?
I was initially unaware of what the "temporary fix" was. It sounds a lot more like it's a server-side account flag that's being set.
I plan on making a temporary solution, until I can figure out what flag is being set and how to fix it.

jnadke said:
Can you post the build.prop?
I was initially unaware of what the "temporary fix" was. It sounds a lot more like it's a server-side account flag that's being set.
I plan on making a temporary solution, until I can figure out what flag is being set and how to fix it.
Click to expand...
Click to collapse
i don't know if the build.prop was the only thing that was changed on that build, but i think so. can't get to it tonight though, work is killing me, gotta dig through my stuff.

Just an FYI for you guys, the market/app size limitation is set by lcd.density.

mssmison said:
Just an FYI for you guys, the market/app size limitation is set by lcd.density.
Click to expand...
Click to collapse
Are you sure? What's your basis for thinking this? If you do a lcd_density of 140 @ 320x480 do the apps go away?
http://d.android.com/guide/practices/screens_support.html
from
http://market.android.com/support/bin/answer.py?hl=en&answer=165590
This page indicates that it's resolution-dependent.
Now, it's possible for certain apps to be missing due to density constraints:
The platform supports a set of resource qualifiers that let you provide size- and density-specific resources, if needed. The qualifiers for size-specific resources are large, normal, and small, and those for density-specific resources are hdpi (high), mdpi (medium), and ldpi (low). The qualifiers correspond to the generalized densities given in Table 1, above.
The platform also provides a <supports-screens> manifest element, whose attributes android:largeScreens, android:normalScreens, and android:smallScreens let you specify what generalized screen sizes your application supports. A fourth attribute, android:anyDensity, lets you indicate whether or not your application includes built-in support for multiple densities.
Click to expand...
Click to collapse
In 320x480 we use a lcd_density of 160.
The rubric says a 320x480 device should be 3.0" to 3.5". That means lcd_density of 164 - 192. You may be missing apps that require "mdpi" (unless the range is a little softer and 160 is in the "mdpi" range).
I could be that changing the density triggers an update to the market. If you cross a density threshold, you might trigger an update from "mdpi" to "ldpi", and it updates resolution as well. Perhaps that's why tatnai's change stuck for so long. He booted up in 320x480 at "ldpi" and when he changed to 240x320 he remained in "ldpi".

mssmison said:
Just an FYI for you guys, the market/app size limitation is set by lcd.density.
Click to expand...
Click to collapse
That actually makes 100% sense.
As most know I've been working on an app to change LCD Density and a few other things. One of the things I've noticed and the the Android SDK makes pretty clear for compatibility sake is the three different types of display targets all of which are linked back to density: http://developer.android.com/guide/practices/screens_support.html
The DisplayMetrics class also reflects this too:
http://developer.android.com/reference/android/util/DisplayMetrics.html
Code:
Constants
public static final int DENSITY_DEFAULT
Since: API Level 4
The reference density used throughout the system.
Constant Value: 160 (0x000000a0)
public static final int DENSITY_HIGH
Since: API Level 4
Standard quantized DPI for high-density screens.
Constant Value: 240 (0x000000f0)
public static final int DENSITY_LOW
Since: API Level 4
Standard quantized DPI for low-density screens.
Constant Value: 120 (0x00000078)
public static final int DENSITY_MEDIUM
Since: API Level 4
Standard quantized DPI for medium-density screens.
Constant Value: 160 (0x000000a0)
I can confirm tonight but if someone wants to now, try running 240x320 in 160 density confirming full market is supported.

I noticed that in 320×480 there are some apps I cannot find. Like an app says there are skins on the market so I click on it and it takes me to the market but it says it cannot be found. Running 320×480 lcd 160, want me to change my density to 164-192. Somewhere in there?

cp0020 said:
I noticed that in 320×480 there are some apparel I cannot find. Like an app says there are skins on the market so I click on it and it takes me to the market but it says it cannot be found. Running 320×480 lcd 160, want me to change my density to 164-192. Somewhere in there?
Click to expand...
Click to collapse
public static final int DENSITY_MEDIUM
Since: API Level 4
Standard quantized DPI for medium-density screens.
Constant Value: 160 (0x000000a0)
Click to expand...
Click to collapse
According to Myn, 160 should work, but you can give it a try.
Keep in mind the skin may be for high-density screens, like the DROID.

Does it matter which one? As long as its 164 and up?

myn said:
That actually makes 100% sense.
As most know I've been working on an app to change LCD Density and a few other things. One of the things I've noticed and the the Android SDK makes pretty clear for compatibility sake is the three different types of display targets all of which are linked back to density:
I can confirm tonight but if someone wants to now, try running 240x320 in 160 density confirming full market is supported.
Click to expand...
Click to collapse
It's linked to density and resolution, in my opinion.
Unfortunately, running 320x240 at 160 doesn't work all that great, I've tried it a long time ago as a test for fixing the market. The home screen gets all bunched up (the applications are all on top of each-other), and there's no app tray.

cp0020 said:
Does it matter which one? As long as its 164 and up?
Click to expand...
Click to collapse
Not really, I'd shoot for somewhere in the middle though, like 176 (I chose that because its divisible by 4, the screen should look better).

Wait, how can it be lcd density controlling the market? For the full market trick when people flash the 320×480 nbh and sign in they are still using there build with lcd density of 110-120. You see what I'm saying? Sorry I might not have a clue what I'm talking about lol

jnadke said:
Not really, I'd shoot for somewhere in the middle though, like 176 (I chose that because its divisible by 4, the screen should look better).
Click to expand...
Click to collapse
OK but just to be on the safe side should I backup my data and start fresh?

cp0020 said:
I noticed that in 320×480 there are some apps I cannot find. Like an app says there are skins on the market so I click on it and it takes me to the market but it says it cannot be found. Running 320×480 lcd 160, want me to change my density to 164-192. Somewhere in there?
Click to expand...
Click to collapse
The applications themselves define in their manifest the supported resolutions:
Code:
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
<supports-screens
android:largeScreens="true"
android:normalScreens="true"
android:smallScreens="true"
android:resizable="true"
android:anyDensity="true" />
</manifest>
With appear to again correspond with the density:
Low density (120), ldpi
Medium density (160), mdpi
High density (240), hdpi

cp0020 said:
OK but just to be on the safe side should I backup my data and start fresh?
Click to expand...
Click to collapse
Ideally fresh data and a virgin gmail. But a non-virgin gmail should be suffice.

[HOWTO] Getting Hero To Run Fast

A lot of people have a tough time with Hero/Sense ROMs. I thought I'd make a guide on what I do to help others out. This is not definitive but it's my personal way of doing things. Comments, tips and suggestions are welcome here. I will update this with some more info as I go along.
I have a MT3G but this is the same for G1.
**Firerat has really comprehensive guides for A2SD and other tweaks. Please check his thread for more info. Also, his post about setcpu profiles is a must read.
First, get a ROM. I'm currently playing with KingKlick's Legend Port and Vegaman's kernel update.zip. This guide applies to any Hero ROM though.
Table of Contents / Overview
First things first
Get your task killers in order (TasKiller, AutoKiller, etc.)
MyBackup Pro or similar if you use them
Autostarts-- one of my favorites. Would love to hear about a free alternative
Droidwall-- free, blocks Internet to apps you choose
Reboot, wipe Dalvik-cache, reboot
Additional steps, Misc, Errata
FIRST:
Partition your SD card. I set a 256MB swap partition and have copious memory left over even under heavy load. EXT2 is better than 3/4.
Flash the ROM, flash the kernel update after. Boot the ROM, go through set up. I always skip signing in at this point as the setup is heavy on the CPU and wait for things to settle before the memory intensive sign in process begins.
SECOND:
Okay, now I see the home screen. Install TasKiller (free/paid) with ADB, MyBackup Pro and kill all the processes except Sense. I highly recommend Autostarts (paid). It handles not only autostart processes but also event listeners and will significantly speed up the ROM. Here are the services I disable:
"After Startup"
Download Manager
My Uploads
Network Location
PC Synchronization
HTC Message Uploader
Peep
HTC Media Uploader
Flickr/FaceBook/MySpace/etc
com.htc.socialnetwork.provider
HTC Widget Download Manager
MyBackup Pro (Uploads your location to their servers at every boot!!)
"Connectivity Changed"
My Uploads
Network Location Service
HTC Message Uploader
HTC Media Uploader
com.htc.socialnetwork.provider
"Application Installed"
PC Synchronization
Pico TTS (why would text-to-speech need to run...)
If you use Slacker.. disable it completely from all "Application Changed/Installed/Removed" categories. No need in them knowing your usage..
"Screen Off"
TasKiller
Notice how (and you can watch with logcat) when an application is modified or installed, it starts up Pico TTS (text-to-speech), synchronization, etc. This is not necessary and a memory hog. You might also be thinking "but I needz muh Facebook" but you don't need it to autostart. These services will load on demand as you use them. Without them, things go a lot quicker.
THIRD: (If you use MyBackup Pro)
Now, I sign into my account with Market, accept the terms and conditions. Once things have settled and I'm able to use the Market I exit the app immediately. I use MyBackup Pro to restore my apps. Version 3 now links apps to Market so they can be updated. Pretty slick despite the fact it logs your location to their servers without your permission. Luckily Autostarts stopped that. Now there's a small catch-- MyBackup messes up the Market database. Easy fix with ADB:
Code:
# cd /data/data/com.android.vending/databases
# ls -l
[I]I summarized the output here for formatting's sake..[/I]
----rwxr-x assets.db
-rw-rw---- billing.db
-rw-rw---- webview.db
-rw-rw---- webviewCache.db
See how assets.db is owned by root and the wrong permissions? This will FC Market 10/10 times. So:
Code:
# cp assets.db BACKUPassets.db
# cp -p billing.db assets.db
# cat BACKUPassets.db | tee assets.db
# rm BACKUPassets.db
Now it will work. The theory is that we can't chown the DB due to an "unknown user" but the other files there have the correct permissions. We use cat and tee to overwrite the clone with the correct contents. It's a hack that works perfectly.
FOURTH:
I then reboot and go to the Market. Install Droidwall (free) and set it to blacklist any app that doesn't need Internet Access. I also install AdFree (free). One site that it doesn't block is flurry.com. This site is used by a lot of applications such as MoreLocale. It uploads personally identifying information about you including your location, phone number, account info, etc. without your permission. I append it to my hosts file afterward. Note that each update with AdFree will erase that entry but I use Autostarts to disable it at boot and never update.
Code:
# mount -o remount,rw /dev/block/mtdblock3 /system
# echo "127.0.0.1 flurry.com" | tee -a /system/etc/hosts
# mount -o remount,ro /dev/block/mtdblock3 /system
FIFTH:
With all the apps now installed that I want to start out with, I go back to Autostarts and disable those I don't want (pretty much all of them). I reboot into recovery mode and wipe Dalvik cache. Reboot, wait for it to cache again and all is well.
Additional Steps
You can easily lock home into memory. *thanks speedysilwady and firerat. Here's how to set this permanently:
Code:
adb pull /init.rc
[I]replace "setprop ro.HOME_APP_MEM ..." with:
[B]setprop ro.HOME_APP_MEM 1536[/B]
[/I]adb push init.rc /sdcard/init.rc
adb shell
# mount -o remount,ro rootfs /
# cat /sdcard/init.rc | tee /init.rc
# mount -o remount,rw rootfs /
# rm /sdcard/init.rc
I will update this as I go. Any comments and tricks like reducing call delays are welcome. Again, this is just how I do things. Hope it helps.

Reserved for the updates....

Reserved for more updates. Just in case.

Don't bother getting kings version just get Vegaman's 0.3 version.
It works a treat and fast as well...
EDIT= and on Vegaman's use EXT2 not EXT4 like you have to do in kings roms. EXT2 is faster then EXT4

Awesome thread! you could also use AutoKiller and Cachemate to keep things smooth as well! =]

Updated OP. I'm looking for the prioritizer script that supposedly gets incoming calls within 1-2 rings... will update when I get it figured out. I have between 40-55MB free memory according to TasKiller when no apps are running.

deuse said:
Don't bother getting kings version just get Vegaman's 0.3 version.
It works a treat and fast as well...
EDIT= and on Vegaman's use EXT2 not EXT4 like you have to do in kings roms. EXT2 is faster then EXT4
Click to expand...
Click to collapse
I agree...and great job thread creater!!!

Interesting! I will try this, how much will the speed increase be?

With what I do, I barely get any slow downs unless I run a lot of apps but I have TasKiller's mini taskbar on one of my home screens and always clear things out before I do something like web browsing, Maps, or games to keep RAM clean.
I'd love an alternative to Autostarts that's free but it is truly great. Blocking listeners causes a huge boost in speed. You will see in logcat when you install an app that all these services start running in the background like Voice Dialer, TTS, etc. That's the reason installing apps seems to peg the phone for a few minutes. Not so when you block those background services.

enatefox said:
Updated OP. I'm looking for the prioritizer script that supposedly gets incoming calls within 1-2 rings... will update when I get it figured out. I have between 40-55MB free memory according to TasKiller when no apps are running.
Click to expand...
Click to collapse
Code:
su
setprop ro.HOME_APP_MEM 1536
this will keep home in memory. I learned that one from Firerat , should make calls come in faster

from what i understand a large swap like that might offer some positive temporary results, but after time clogs up

adelco93 said:
from what i understand a large swap like that might offer some positive temporary results, but after time clogs up
Click to expand...
Click to collapse
It's bad to have a large swap and high swappiness.

I haven't had any issues. The swap partition hasn't clogged up or even gone under 100MB left for me yet. Your mileage may vary but it's what I set it to. What size/swappiness would you recommend then? 96MB is not enough, 128MB seemed like too close to the edge of what I need.
I need to make the OP not look like crap...

It is better for the life of your sdcard to have a large swap....because if you allocate say only 64mb to swap...those blocks on your sdcard are constantly being written/read and the rest isn't....better to have a swap of say 256mb so that you are evening out the stress on the blocks more.
I think Wes G or Chris S said this....but that's my paraphrase of it.
Also no difference in speed between a 32mb swap and a 256mb swap. Just depends on your sdcard's class.

enatefox said:
I haven't had any issues. The swap partition hasn't clogged up or even gone under 100MB left for me yet. Your mileage may vary but it's what I set it to. What size/swappiness would you recommend then? 96MB is not enough, 128MB seemed like too close to the edge of what I need.
I need to make the OP not look like crap...
Click to expand...
Click to collapse
60 at most 80 or 100 is to much
G1ForFun said:
Also no difference in speed between a 32mb swap and a 256mb swap. Just depends on your sdcard's class.
Click to expand...
Click to collapse
If we were talking about computers then swap would be same size as ram, it's better to have no swap at all then to have one
Read some of this:
https://help.ubuntu.com/community/SwapFaq

G1ForFun said:
It is better for the life of your sdcard to have a large swap....because if you allocate say only 64mb to swap...those blocks on your sdcard are constantly being written/read and the rest isn't....better to have a swap of say 256mb so that you are evening out the stress on the blocks more.
I think Wes G or Chris S said this....but that's my paraphrase of it.
Also no difference in speed between a 32mb swap and a 256mb swap. Just depends on your sdcard's class.
Click to expand...
Click to collapse
Try Fireat
But for purposes of speed, a large swap partition will get full eventually, and when it does, have fun trying to use your phone. It gets slower because swap has to "dig" through more files to get what you want, the more files it has to dig through, the slower it is. However, you won't notice this if you reboot often (and I guess 5% of Android users reboot daily)

is there a way to enable compache on any of these hero roms?

speedysilwady said:
is there a way to enable compache on any of these hero roms?
Click to expand...
Click to collapse
The user.conf (if it is activated on the rom)

JAguirre1231 said:
The user.conf (if it is activated on the rom)
Click to expand...
Click to collapse
The thing is im not sure if its activated in any of the newer sense roms, i never heard it mentioned, so i figured id ask. ill go check the user.conf...

speedysilwady said:
The thing is im not sure if its activated in any of the newer sense roms, i never heard it mentioned, so i figured id ask. ill go check the user.conf...
Click to expand...
Click to collapse
None of newer ones use it for a reason, you would use back-swapping instead(Cc+swap)

Lock an App into Memory

I'm a heavy AIM user, among other things on Android. For me, AIM always closes when I minimize it, so I tried alternative apps, like the application Hi AIM, which I personally like a lot too. The good thing about Hi AIM is that it has a constant icon in the notification bar showing that it is active therefore I know whether or not I'm signed in or not/if the app has been dropped from memory. I ran several tests IMing myself from my computer with the app open, it works fine even if i minimize it and navigate around my phone. However, if I open up the browser and start loading a website, the icon disappears, and all subsequent messages sent are dropped. This is a large problem for me and therefore the only solution I can think of is locking the application into memory. According to Advanced Task Manager [which I do not leave on, I only use it to check memory], with my phone on standby I usually have around 19-28MB of free memory. I have the 10MB ram hack, as well as CompCache and 32MB swap. I am running the latest Super D with Dark Star theme. The browser obviously has a large memory load and is causing the AIM app to be dropped in favor of running the browser quickly, is there anyway I can lock the AIM app into memory? I understand there will be a minor general slowdown of the phone overall as a part of the memory is now purely dedicated to that single app, but AIM is something I use a lot.

Yes.
I'ts pretty much this thread: http://forum.xda-developers.com/showthread.php?t=652147
Their solution is to "download the AutoKiller app" and press "keep alive"
hope this helps

You just made my day. Thank you very much haha

Advanced Task Manager also works for what you require.
Been using it for awhile now and am satisfied enough to not use another app for such purposes.

I don't know what/how to change this, but this is the code you need to make the sense home app stay in memory. Perhaps its similar to the way you make any other app stay in memory?
Code:
adb pull /init.rc
replace "setprop ro.HOME_APP_MEM ..." with:
setprop ro.HOME_APP_MEM 1536
adb push init.rc /sdcard/init.rc
adb shell
# mount -o remount,ro rootfs /
# cat /sdcard/init.rc | tee /init.rc
# mount -o remount,rw rootfs /
# rm /sdcard/init.rc

[FIX] Bulletproof Background Apps!

UPDATE: Try BulletProofing Apps with my latest V6 SuperCharger Script! Use the following link OR use the link in my signature
I didn't want to risk making the SuperCharge & Bulletproof thread too confusing so I figured it best to make a "sister" thread.
This is a work in progress.
But if this information is helpful, please click the thanks button
HUGE thanks to Feeyo and Bear in NM for helping me figure out a workable solution on locking a background app in memory on boot up.
Feeyo gave me the gist of it but it wouldn't work on boot.
After posting in this thread at Droid Forums, things got rolling - with alot of help from Bear in NM.
Create a Unix script file with no extension (I named it 97oom) with Notepad++ and put it in your i/system/etc/init.d/ folder and put this inside:
Code:
#!/system/bin/sh
sleep 60
PPID=$(pidof [B]com.estrongs.android.safer[/B])
echo "-17" > /proc/$PPID/oom_adj
Permissions: chmod 755 /system/etc/init.d/97oom (same as 10overclock)
You can also do it on the phone itself:
1. Make a copy of 10overclock
2. Renamed it to 97oom (I have a 98governor and a 99complete so...)
3. Deleted the text and put the text you see above
4. Set permissions
Then reboot to test!
You can check to see if it worked with either Auto Memory Manager (AMM) or AutoKiller Memory Optimizer (AKMO).
The bold text in the above code is the process name of the app that you want to protect!
Note: You can get the process name from most process monitors or with AKMO or AMM.
That command "as is" will give ES Security Manager the highest priority of -17.
AKMO shows it as being ignored by the OOM killer
At first it wasn't working on boot because ES Security was not yet loaded in memory.
The "sleep 60 "command fixes that by waiting 60 seconds to execute the command
You can also do this in GScript Lite with this:
Code:
PPID=$(pidof com.estrongs.android.safer)
echo "-17" > /proc/$PPID/oom_adj
This comes in handy for apps that don't load on bootup - just run a GScript for those apps
I suggest you get Busybox Installer and have it install the latest BusyBox (v1.19).
This ensures GScript doesn't spit out ugly stderr: messages.
GScript Tip: 1. Make a file (with any text editor) with the commands
................. 2. Rename it with an .sh extension (example 97oom.sh)
................. 3. Put it in sdcard/gscript folder
................. 4. Run GScript, Menu key, Add script, and click Load file, select a script and Save (leave SU checked)
Even better, you can make shortcut for any GScript.
Long press desktop > Shortcuts > GScript Lite > Select... BOOYA!
As I said, this is a work in progress.
Taming the OOM Killer explains that an app will be ignored by the OOM killer if it has the -17 priority.
The problem is that Android will still shuffle it's priority downwards like it does with any inactive app.
If that happens, then the app reverts to it's usual priority.
This is why ESS will lose it's -17 after a couple of hours. It just sleeps ALL the time.
My thinking that if a more active background app, such as an SMS app or a music app is given the -17, it won't lose it's priority at all.
Feedback with results is more than welcome!

No need to set a variable, just use back-ticks:
Code:
echo -17 > /proc/`pidof [B]com.estrongs.android.safer[/B]`/oom_adj
Although that may be a little too complicated for some people to type in. Best to keep it simple I suppose...

That's pretty cool.
I figure most people would copy/paste the whole thing and replace the process name.
So maybe the back ticks wouldn't be a big deal.

That is why I try and avoid putting any code I use on forums. Someone who actually knows what they are doing will always come along and whack me ;^)
Seriously, good work Zep.
Craig

I don't mind.
That's all a part of learning so it's always good that there's somebody around that's "smarter" at something than me.
For example... this script I'm trying to get working for supercharging stock phones...
On custom roms, CM and FroyMod at least, I'd modify /system/etc/rootfs/init.mapphone_umts.rc
I flashed stock telus 2.2 and the path seems to be just /init.mapphone_umts.rc
I don't see rootfs anywhere
But there is a rootfs is mounted
To mount as rw, "mount -o remount,rw /system" doesn't work
In gscript, I'm getting "sed not found" errors too.
grrr...

how well do you think this would work with handcent? it's a little laggy to load up on my phone, but i want to try it out more. will keeping handcent in memory eat up ram that i need otherwise? and do you think it will be active enough to keep it's -17 after a few hours? thanks
edit: i was trying it out, it disappeard from processes withing a few minutes. oh well, maybe it doesnt need to be running anyway

Did you check with AMM to see if handcent had the high priority or if it really got killed?

ya, i checked. it was set to -17, then next time it refreshed it was gone. then i opened handcent, went back, and the process had a different pid, not oom level. oh well

damn
Maybe some apps are too prone to get killed off and the only way to keep them alive is with multitasking friendly minfree values

zeppelinrox said:
damn
Maybe some apps are too prone to get killed off and the only way to keep them alive is with multitasking friendly minfree values
Click to expand...
Click to collapse
Yes, I've seen the same happening with the stock SMS app. I did not receive SMS anymore so I decided to look at it a bit closer (using adb logcat). I started the SMS app, noted down the PID and set the oom_adj value to -17 using adb shell. A few seconds later it was killed. Setting the minfree values back to system default allows me to receive SMS again. Also whatsapp, gtalk and push mail now work reliable. With high minfree values I could see in the logs that, when a message arrived the app is started and immediately killed afterwards. So, I was never notivied that a SMS or whatsapp message had arrived. With default minfree values it seems to work more reliable.
But it all depends on how you use your phone, I guess. I'm using it as my communication central and don't want to miss any message. If you use it more as your mobile gaming or surfing device you might still be better off with high minfree values.

I agree.
That's why I made 6 different profiles.
The multitasking and balanced 2 settings, for example, will leave you with more free ram but are actually more background app friendly than stock google/android values.

zeppelinrox said:
I agree.
That's why I made 6 different profiles.
The multitasking and balanced 2 settings, for example, will leave you with more free ram but are actually more background app friendly than stock google/android values.
Click to expand...
Click to collapse
I see. I did not realize that. It seems I've been reading your post too superficially.
I'll give those settings a try. I've just lost another SMS (this time with the default setting)
If I can't get this under control I might go back to CM6. I understand this is not as memory hungry as CM7 is.

Well, handcent is a giant pain in the ass.
I'm running stock telus froyo and the thing doesn't even stay loaded and I'm not even doing anything.
I run it.
Try and bulletproof it with a gscript (and sometimes handcent is even killed off if I take too long opening gscript lol)
The script won't even change the priority of hancent.
It stays at an 9 or 10 in the content provider grouping.
But the thing is a pig anyway.
20+ mb of ram used up and the app itself is close to 5 mb.
Maybe froyo has a reason to not like it? LOL

very very important and informative post!
thank you!
one question: any idea why "Auto Memory Manager" isn't avialable to
milestone according to market?
I can't install it from market site and wasn't able to find it in market application?

zeppelinrox said:
Create a Unix script file with no extension (I named it 97oom) with Notepad++ and put it in your i/system/etc/init.d/ folder and put this inside:
Code:
#!/system/bin/sh
sleep 60
PPID=$(pidof [B]com.estrongs.android.safer[/B])
echo "-17" > /proc/$PPID/oom_adj
Permissions: chmod 755 /system/etc/init.d/97oom (same as 10overclock)
You can also do it on the phone itself:
1. Make a copy of 10overclock
2. Renamed it to 97oom (I have a 98governor and a 99complete so...)
3. Deleted the text and put the text you see above
4. Set permissions
Click to expand...
Click to collapse
I did it, and after reboot stock sms app (com.android.mms) is killed, I cheched in AKMO, and that fix didn`t help, so I set default minfree values in AKMO (although the previous settings weren`t so strict)

Ok, first off, I am a UK Milestone, running Cyanogenmod 7 RC4. I am trying to raise the oom_adj of COM.ANDROID.MMS and I just used the method zeppelinrox posted instead of the proposed alternative (though I did try that too) and the startup command seems to do nothing. So I decided to try the GScript way and I get this:
Code:
stderr:
stderr:
stderr:
stderr:
stderr:
stderr: cannot create /proc//oom_adj: directory nonexistent
stderr:
stderr:
stderr:
I have never used GScript before and maybe I am doing something wrong here, but I am running it the script as superuser, I have exactly what zeppelinrox has (except a change for the messaging app process name) and I am at a total loss here. Other methods worked fine on my RC3 and keep Messaging as a "Foreground Group" app, but in RC4 it is an "Empty" and that means it will likely get killed a lot. I am using stock minfree values, just using AMM to check oom. I don't want to be missing texts, so any help would be greatly appreciated. Let me know if you need anything else.

You get that "directory nonexistent" error because the app was already killed so there is no PID anymore.
I suggest you get Busybox Installer and have it install the latest BusyBox (v1.19).
This ensures GScript doesn't spit out ugly stderr: messages.
I finally installed CM7 for the first time and RC4 at least does have the option to lock messaging app in memory.
It's sitting in the foreground with a 0 priority

I thought that maybe it was killed already also, but I opened Messaging -> checked System Panel to ensure it was running -> ran the GScript (which failed as noted before) -> and checked System Panel once more and it was still running. Maybe I am crazy here..
I am using the "Lock messaging in memory" but "Messaging" process is still killed by the stock manager, is it still alive in some separate process? It certainly is not 0 priority in Foreground, still sitting in "Empty" at something generally over 4 priority.
I will probably just switch back to the previous build as all was well there, though I would like to be able to keep up with the newest features.
Thank you for the Busybox link, I will try that.

That's strange.
Maybe that setting needs a reboot?
I remember seeing messaging in content provider earlier and then I was actually surprised to see it in the foreground.
I actually checked to see if I still had the 97oom file in the init.d folder but it's not there.
But it should be immediate because if I uncheck Lock messaging in memory, it gets instantly killed.
I run it, check lock messaging again, and AMM shows it in the foreground group again.
Stderrs... now I dunno what's going on with that
GScript was working perfectly in stock Telus rom without stderrs after installing busybox (to get certain commands to work).
But in CM7, after updating busybox, stderrs all over the place.
Now I have to figure this out.. those stderrs are annoying as hell

zeppelinrox said:
You get that "directory nonexistent" error because the app was already killed so there is no PID anymore.
I suggest you get Busybox Installer and have it install the latest BusyBox (v1.19).
This ensures GScript doesn't spit out ugly stderr: messages.
I finally installed CM7 for the first time and RC4 at least does have the option to lock messaging app in memory.
It's sitting in the foreground with a 0 priority
Click to expand...
Click to collapse
What am I missing here? I'm looking at my CM7 Milestone right now with the "lock messaging app in memory" selected. And the messaging app is sitting in "background". Then I set the oom_adj value to -17 and a few minutes later messaging is gone. I'm starting to become desperate.

How To Guide (Outdated) How to force HDR and maximum brightness on Samsung flagships

I didn't find any tutorial to do this, so i started searching by myself, i almost fried my S21 Ultra but it was worth it. Now i can provide a working tutorial to everyone. This works on S21s for sure, it should also work on other models
19/11 edit: This method still works but it's outdated​
1 - Forcing HDR: only available on HDR(10+) videos. Now you can force this yellow-ish tint and better color accuracy everywhere (yes, even when gaming)
i strongly recommend you to use FX explorer.
Create a xbin folder in /system (this is important, don't create it elsewhere)
Inside, create an empty file with no extension: hdr
Open it as text, write 1 and save it
Create a second empty file, name it forcehdr (you can name it whatever you want, make sure you'll remember it later)
Open it as text, and write this:
cp /system/xbin/hdr /sys/devices/platform/panel_drv_0/lcd/panel/mdnie
Save it, and give it execute permissions (octal: 0755). Now you can execute it in a terminal or directly from FX explorer (as root of course !)
----------
2 - Maximum brightness: you already know that your screen gets significantly brighter under the sunlight. Now you'll be able to force this level anytime:
Go to /sys/devices/platform/panel_drv_0/backlight/panel
Take a look at the max brightness value of your screen ("max_brightness") mine is 561 (this value may change a little bit depending of your model)
Go to /system/xbin
Like before, create an empty file, you'll call it "brightness"
And an executable file
Repeat the same process: write your max brightness value inside "brightness" file, save it. Open your executable and write this
cp /system/xbin/brightness /sys/devices/platform/panel_drv_0/backlight/panel
Execute it in a terminal or in FX
You can go back to SDR by making another hdr file and executable, but this time, write 0 instead of 1

RangerKevin2 said:
Create a xbin folder in /system (this is important, don't create it elsewhere)
Inside, create an empty file with no extension: hdr
Open it as text, write 1 and save it
Create a second empty file, name it forcehdr (you can name it whatever you want, make sure you'll remember it later)
Open it as text, and write this:
cp /system/xbin/hdr /sys/devices/platform/panel_drv_0/lcd/panel/mdnie
Click to expand...
Click to collapse
I tried to do it on Note 10+ android 12 but stopped at the command. I have a "[email protected]" directory on my device. Your comment doesn't work and changing the command directory to my "[email protected]" also doesn't work.

rogeros123 said:
I tried to do it on Note 10+ android 12 but stopped at the command. I have a "[email protected]" directory on my device. Your comment doesn't work and changing the command directory to my "[email protected]" also doesn't work.
Click to expand...
Click to collapse
That's why i said "it should" (to make people understand that it may not work on their devices)
The Note 10+ is old compared to S21s.
This doesn't surprise me...
Since i don't have a Galaxy N10, i can't make all the work and tell you how to do it, you'll have to search by yourself, like i did, but i can help.
Search manually or automatically in screen related folders (panel-x, panel_xxx_xxx etc...) for HDR related files (basically a boolean). Don't be afraid to do some tests and open files to change a 0 to a 1.
Once you found the correct file which controls HDR, repeat the same process, create an executable, empty file...
But i have one question (i mean two), when you execute yours, do you have an error as output ? If yes, what is it ?

I would like to try this. But this requires root, right?

Paauul said:
I would like to try this. But this requires root, right?
Click to expand...
Click to collapse
Yes it does, but it's not a drama if you root your Samsung !
Most phones have the same rooting procedure, unlock the bootloader, flash the TWRP for your phone model, then magisk

RangerKevin2 said:
Yes it does, but it's not a drama if you root your Samsung !
Most phones have the same rooting procedure, unlock the bootloader, flash the TWRP for your phone model, then magisk
Click to expand...
Click to collapse
I'd root it if i could. The U1 (US Unlocked) Models don't support OEM/Bootloader unlocking sadly.
But achieving higher brightness is only possible with root, right?

Paauul said:
I'd root it if i could. The U1 (US Unlocked) Models don't support OEM/Bootloader unlocking sadly.
But achieving higher brightness is only possible with root, right?
Click to expand...
Click to collapse
Yes unfortunately, there's no way to do this without root

I tried all this but I don't know if really works hdr 10. My max brightness is 561 like you and it goes via Fx, but when I retry to set brightness from the upper slide doesn't arrive at 561 but i think less.
How is it possible fix this? I would like have really maximum brightness
Thank you

Energixia said:
I tried all this but I don't know if really works hdr 10. My max brightness is 561 like you and it goes via Fx, but when I retry to set brightness from the upper slide doesn't arrive at 561 but i think less.
How is it possible fix this? I would like have really maximum brightness
Thank you
Click to expand...
Click to collapse
Yeah, it's normal. The brightness slider only goes from 0 to 255 and is overrode by the light sensor when it's too bright around you
Just before executing the brightness script in FX, click on the 3 dots icon and select "add shortcut". Now you can access it directly from your launcher

Ok thank you, but there is a way to increase that 255 value on the slider? Sorry for the partial OT

Energixia said:
Ok thank you, but there is a way to increase that 255 value on the slider? Sorry for the partial OT
Click to expand...
Click to collapse
Yes, The brightness slider is controlled by Android itself, so i have to make a custom rom... but i can't, I'm not a dev, i hate coding and i'm probably a bit young to learn this x)
If you have skills in programming, maybe you can try to compile a custom rom for the S21 ?

Oh God, i wish it but I'm too much noob to do this sadly. I never did it and perhaps I don't have these skills

Resurrecting an old thread but this still works on s23 ultra however the location has changed for the brightness files its now /sys/class/backlight/panel0-backlight
I was able to get system rw using a new test version of ro2rw from there telegram with support for s23u. I normally use the app called high brightness mode to access the secret hbm mode however this app doesnt work on s23 and hasn't been updated since 2021