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.
Related
I have the sprint vogue that I ran Android 1.5 from my sd card with sprint network. I updated to eclair on the sd card but find my phone says T-Mobile, don't think its a big deal.When I was running 1.5 I was able to find apps like pandora to down load, know on t-mobile network and eclair a lot of apps are missing? Is their a way to unlock the market.
You need market enabler.
http://code.google.com/p/market-enabler/
Edit: This pretty much just adds paid apps.
skipbarker said:
You need market enabler.
http://code.google.com/p/market-enabler/
Click to expand...
Click to collapse
I don't know if that will work cause he was able to download Pandora before and that's a free app, market enabler just to gives you paid apps
My bad. I misunderstood.
http://forum.xda-developers.com/showthread.php?t=628353
Read #5
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).
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
That is a great idea.
Do you have the capacity to perform the differential on the two directories?
I have deodexed the 1.6 Vending.apk and can post the source for everyone to review. I think the more eyes on this the better.
The only reason I run 320x480 is because I want a full market 100% of the time.
All is working, I used the link that PacyWhitter gave, followed Tatnai directions and know have full market!!!
myn said:
That is a great idea.
Do you have the capacity to perform the differential on the two directories?
I have deodexed the 1.6 Vending.apk and can post the source for everyone to review. I think the more eyes on this the better.
The only reason I run 320x480 is because I want a full market 100% of the time.
Click to expand...
Click to collapse
Yeah, I can do it, though it'd be easier to do it on two data.img files (might have to go back to WinMobile for that). Or I guess I could flash the kernel and wipe my data and export the result each time to a binary file. I'd still be interested in seeing the Vending.apk.
I already know where the Market apk is getting its info from. In android.utils there's a class called DisplayMetrics. The Market apk is likely getting its info from there. It'd be possible to spoof it by recompiling the source with a hardcoded value, but that'd affect applications as well. It'd be much harder to do it for only the Market/Vending apk.
The thing I'm interested in, is that obviously if the "boot up at one resolution, switch back" trick works, then it's not sending the resolution to the server every time. This means it has to be storing the data, or a hash of the data, somewhere.
This guy has a fascinating website on similar subjects:
http://strazzere.com/blog/
There's also a way to use the Market from the emulator:
http://www.anddev.org/viewtopic.php?p=28991
Perhaps I can start there and see if I can reproduce the problem, then produce the solution in a controlled environment.
graphic914 said:
All is working, I used the link that PacyWhitter gave, followed Tatnai directions and know have full market!!!
Click to expand...
Click to collapse
People seem to indicate it resets after a few days, so you will have to redo it until I have time to see if I can fix it.
jnadke said:
This guy has a fascinating website on similar subjects:
http://strazzere.com/blog/
Click to expand...
Click to collapse
That is one of my fav sites for Android dev. Great site .
Started Community Market Project here
I'm not sure if you guys happen to have the same problem as me, but when I go into "adb push" a file into the /system partition I happen to get a "Permission Denied". It made it futile to move the build.prop file In order to change the density as shown in a thread called "[MOD] LCD Density - DIY!" (new user sorry can't post links)
Thanks to looking at this useful thread called "[SCRIPT] Quick Remount of /system in Shell"
I've managed to come up with a way to move the build.prop file without using the ADB push method.
REQUIRES BUSYBOX
1. Move the modified build.prop file into the root of your Internal SD.
2. Now from windows use ADB:
adb shell
su
mount -o rw,remount -t rfs /dev/block/stl9 /system
busybox mv /sdcard/build.prop /system/
remount ro
Ctrl+C and your done
adb push build.prop /sdcard/
? i think it is faster than hitting mount sd, opening folder, etc ?
or adb shell
su
mount -o rw,remount -t rfs /dev/block/stl9 /system
Ctrl + C
adb push build.prop /system/
No real reason but etiquette to remount as ro.
BTW: I'm just posting in this thread for no real reason, just sharing ideas not trying to flame or anything.
edit: also mv should work without busybox
I prefer root explorer. remounts /system as R/W, and has a built in su text editor. Takes all of 30 seconds to open the app, remount, navigate, edit file, save & exit.
Whats a good density to set the phone at? And I'm assuming a hard reset will set it back to the default density.
speoples20 said:
Whats a good density to set the phone at? And I'm assuming a hard reset will set it back to the default density.
Click to expand...
Click to collapse
Or just editing the density back to 240 and repushing. I personally don't like it changed but I have seen a lot of people set it to 200.
I used the LCD density changer and liked the overall smaller home screen, but when I went into the dialer it was offset.
Does this happen with this method also?
Most likely, I found some things to be offset when I changed density, I can't remember if the dialer is one of those things. But it does change this same value so yea...
Im kind of a newbie at this kind of stuff, but whenever I try to adb push i get a "Permissions Denied", any knowledge of how to fix this?
To fix the offset issue dl spare parts from the market and enable compatibility mode....
Sent from my SGH-T959 using XDA App
junkdruggler said:
To fix the offset issue dl spare parts from the market and enable compatibility mode....
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
sick I will try this, thanks!
Regarding those asking about "Permission Denied" errors, the reason is because you are trying to write to a read-only partition. Try running `adb remount` before you push onto /system. This will remount the read-only partitions as read/write without needing to remember the /dev nodes or specific options to `mount`.
For the second part of this, why would you want to change the LCD density of your device? The density setting tells the device how to translate between dips (density independent pixels, which is the native Android system for sizing items on the screen) and real-life pixels. By changing the pixel density, you are messing up the way that Android tells the device to draw things on screen.
It may help to sharpen things on your screen, but you are messing up with the way that things display, and graphics and controls will be confused as to where they really ought to be on the screen.
The only reason to change the LCD density is if you physical replace your LCD panel with one that has a different pixel density.
rpcameron said:
Regarding those asking about "Permission Denied" errors, the reason is because you are trying to write to a read-only partition. Try running `adb remount` before you push onto /system. This will remount the read-only partitions as read/write without needing to remember the /dev nodes or specific options to `mount`.
For the second part of this, why would you want to change the LCD density of your device? The density setting tells the device how to translate between dips (density independent pixels, which is the native Android system for sizing items on the screen) and real-life pixels. By changing the pixel density, you are messing up the way that Android tells the device to draw things on screen.
It may help to sharpen things on your screen, but you are messing up with the way that things display, and graphics and controls will be confused as to where they really ought to be on the screen.
The only reason to change the LCD density is if you physical replace your LCD panel with one that has a different pixel density.
Click to expand...
Click to collapse
I really do disagree, for the VAST majority of apps, it's a seamless change, and allows for more information to be displayed on the screen. Games seem to have the worst time with it, so if you game a lot, probably not recommended. I've used a 200 setting for a couple of weeks now, and I switched it back yesterday (trying to get Abduction 2 to work, lol), and it feels like reading a large print book. It's of course a personal preference, and it does rarely cause problems, but I wouldn't go without it.
siirial said:
I prefer root explorer. remounts /system as R/W, and has a built in su text editor. Takes all of 30 seconds to open the app, remount, navigate, edit file, save & exit.
Click to expand...
Click to collapse
And you'll find the file updated (and the screen automatically stretched) after rebooting????
I have been using the latests builds to see if they mitigate a common problem in our devices (mine is a Polaris). The insufficient memory makes it lag until forever when switching amongst applications, not only the heavy ones, but also the supposed light applications like Messaging, Phone, Contacts, etc.
The system has to work under really hard conditions: 20 - 28 MB when starting up. Every application I run is a fire proof. Applications like Navigation makes our devices literally crawl and bite the dust. Not far away, I was driving and tried to play some music at the same time. It was impossible. The waiting was unbearable and it finally hung like a pro.
My question is: is there any chance to free up memory or use it more efficiently in order to avoid these undesirable situations?
Did polaris get back some memory with Froyo kernel like vogue did? From the video buffer or something... what res do you run at?
I'm running at 240x320 - 120 dpi
I made a screenshot of a "free" command in a terminal (see attachment image).
My kernel is this one (converted with Atools):
http://androidhtc.git.sourceforge.n...=2.6.32/VOGUIMG-320-FROYO-10-4-10.NBH;hb=HEAD
Thanks for your interest!
Im not sure.. but is there a way to use the sd as ram?
I think its not fast enough, but i havent seen any "benchmarks" yet how fast the ram on the polaris works.
Maby its slower but fast enough to work as swap etc?
Enabling compcache will help you.
Still, our little devices cannot multitask very well with Android, but I can navigate and play music at the same time, with compcache.
You will need drivers that match your kernel, in /system/lib/modules. I have packaged some in the first post of this thread that should work for each of the two popular kernel versions.
n2rjt said:
Enabling compcache will help you.
Still, our little devices cannot multitask very well with Android, but I can navigate and play music at the same time, with compcache.
You will need drivers that match your kernel, in /system/lib/modules. I have packaged some in the first post of this thread that should work for each of the two popular kernel versions.
Click to expand...
Click to collapse
Alright, I'm downloading the modules for 2.6.32. After applying the update, what should I do to enable compcache? Some time ago, this setting was in Spare Parts.
SuperJMN said:
Alright, I'm downloading the modules for 2.6.32. After applying the update, what should I do to enable compcache? Some time ago, this setting was in Spare Parts.
Click to expand...
Click to collapse
Open terminal
type: Su
and then
compcache.sh enable
-Arturo- said:
Open terminal
type: Su
and then
compcache.sh enable
Click to expand...
Click to collapse
any way to confirm that it worked?
margosmark said:
any way to confirm that it worked?
Click to expand...
Click to collapse
type FREE in terminal and look under swap if it shows zero then it's not active.
-Arturo- said:
type FREE in terminal and look under swap if it shows zero then it's not active.
Click to expand...
Click to collapse
yea, try doing free from a terminal you should have an amount of memory for the swap row
For testing...
Thank you SuperJMN for this thread : I hope this help us for better use of our phone.
Like you, when I try to use my GPS navigation (Navigon or Igo8) I'm bored that's too slow !! Impossible to change anything if I want...
I try now with Compcache enable, I can see 130024 (total and 104156 used) instead of 104024 : swap = 26000
Cheers.
manu33xtro said:
Thank you SuperJMN for this thread : I hope this help us for better use of our phone.
Like you, when I try to use my GPS navigation (Navigon or Igo8) I'm bored that's too slow !! Impossible to change anything if I want...
I try now with Compcache enable, I can see 130024 (total and 104156 used) instead of 104024 : swap = 26000
Cheers.
Click to expand...
Click to collapse
any better luck with comcache on??
Report
I installed this update for my .32 kernel (dated September, the 30th):
http://forum.xda-developers.com/attachment.php?attachmentid=409422&d=1285714954
My build is the latest: http://sourceforge.net/projects/androidhtc/files/system-froyo-01-10-10_16.tgz/download
When I open a terminal and type
su
compcache.sh enable
it states that compcache will be enable in 120 seconds.
After that time, a free command doesn't reveal any change.
I've also tried typing
su
compcache.sh start
When doing this, it processes the command and after 30 seconds or so, some lines are displayed:
Code:
insmod: can't insert '/system/lib/modules/lzo_compress.ko': File exist
insmod: can't insert '/system/lib/modules/lzo_decompress.ko': File exist
insmod: can't insert '/system/lib/modules/ramzswap_compress.ko': File exist
swapon: /dev/block/ramzswap0: Function not implemented
vm.swappiness = 30
After that, a free command doesn't reveal any change, too.
SuperJMN said:
I installed this update for my .32 kernel (dated September, the 30th):
http://forum.xda-developers.com/attachment.php?attachmentid=409422&d=1285714954
My build is the latest: http://sourceforge.net/projects/androidhtc/files/system-froyo-01-10-10_16.tgz/download
When I open a terminal and type
su
compcache.sh enable
it states that compcache will be enable in 120 seconds.
After that time, a free command doesn't reveal any change.
I've also tried typing
su
compcache.sh start
When doing this, it processes the command and after 30 seconds or so, some lines are displayed:
Code:
insmod: can't insert '/system/lib/modules/lzo_compress.ko': File exist
insmod: can't insert '/system/lib/modules/lzo_decompress.ko': File exist
insmod: can't insert '/system/lib/modules/ramzswap_compress.ko': File exist
swapon: /dev/block/ramzswap0: Function not implemented
vm.swappiness = 30
After that, a free command doesn't reveal any change, too.
Click to expand...
Click to collapse
Try this one
http://dl.dropbox.com/u/7688082/androidupdate.tar
Also is terminal added to the white list in super user app.?
Try with this update...
l1q1d said:
Try with this update...
Click to expand...
Click to collapse
It worked! Thanks!
By the way, the touchscreen behaves erratically with 4-oct NBH. Test with calibration app and tap the screen. You will notice abrupt lines.
Edit: if you want to see which behavior I'm referring to, watch this video: http://www.youtube.com/watch?v=DPLu41BUB1Y
It happened sometime in the past, but with this one it happens the same (although the abruptness is not as much as in this video).
Edit 2: Strangely enough, it is fixed on reboot, but after some time running the touchscreen starts to behave crappy again. It happens with the newest .NBHs made in October.
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.
I'm running CM7 nightlies on my Nook, just wondering what I need to do in order to get the market work the way it's supposed to. (Hidden download buttons, can't update apps, etc)
set lcd density to 160 in build.prop
force stop market, clear cache
brings back functionality for ~ 1 day, clearing the cache again get's you another day, etc.
long term fix...?
NCKevo said:
long term fix...?
Click to expand...
Click to collapse
That's what I'm looking for
NCKevo said:
set lcd density to 160 in build.prop
force stop market, clear cache
brings back functionality for ~ 1 day, clearing the cache again get's you another day, etc.
long term fix...?
Click to expand...
Click to collapse
I've failed at this multiple times
Using ES File Explorer and giving it permissions, I can edit but not save the build.prop file.
Don't know if this matters, but I have CM7 on the sd card (no eMMC install).
Also, I suspect the /system folder is read only?
I thought the solution is
a. Stop (rename or uninstall) the MarketUpdater
b. Clear cache / data on the Market then uninstall "Updates"
Step b. above is a roll-back (old) version of Market (2.6.x.x?)
Step a. above is stopping the Auto Update of the Market.
There's some report of modifying the density to 160 in the build.prop.
you can also use a LCD density changer app from the market. the biggest problem is that none of the fixes are long term. you can change the lcd to 160dpi and clear cache but in a day or two you're back to where you started. the only long term fix for now is to go back to the old market and freeze or delete the updater. or at least until the old market becomes incompatible.
I know this sucks. why are we being CENSORED by google
I uninstalled market update then cleared cache and data, then in root explorer I deleted market updater.apk and now I have old market working just as it should. Thanks for the tip boxcar!
What am I doing wrong? I have cm7 on sandisk sd. Installed the latest nightly and installed gapp file for cm7. Installed lcd density changer app and set to 160. Force stopped market and deleted cache, but still not working right.
I don't understand how to set the market back to the old style.
kingston73 said:
What am I doing wrong? I have cm7 on sandisk sd. Installed the latest nightly and installed gapp file for cm7. Installed lcd density changer app and set to 160. Force stopped market and deleted cache, but still not working right.
I don't understand how to set the market back to the old style.
Click to expand...
Click to collapse
to get the old market back all you have to do is...
1) in settings / applications / manage applications / press all scroll down to market and uninstall updates.
2) with titanium you can freeze the market updater or with some kind of file manager app like astro or root explorer you can delete the updater. if you delete the updater and wish to get it back all you have to do is re-flash gapps
3) now you should have the old market back
4) enjoy
If I set my density to 160 or 240, then force stop & clear data in Market app (after reboot, before connecting to Market), the new market works fine for me. Works fine for many days at 240, seems to work for only a day or so at 160.
I change the density in build.prop using Root Explorer, so it stays that way every time I reboot. Running 177 from sd card.
If I also uninstall updates when I do the above, it reverts to the old market, and that works fine for a day or less.
If Google was really trying to prevent the Nook Colors from accessing the Market, they could probably figure out a more effective way to do it. I think this idea is paranoia, and the cause is just something weird in the rom's details. I could be wrong, though.
lynnji said:
If I set my density to 160 or 240, then force stop & clear data in Market app (after reboot, before connecting to Market), the new market works fine for me. Works fine for many days at 240, seems to work for only a day or so at 160.
I change the density in build.prop using Root Explorer, so it stays that way every time I reboot. Running 177 from sd card.
If I also uninstall updates when I do the above, it reverts to the old market, and that works fine for a day or less.
If Google was really trying to prevent the Nook Colors from accessing the Market, they could probably figure out a more effective way to do it. I think this idea is paranoia, and the cause is just something weird in the rom's details. I could be wrong, though.
Click to expand...
Click to collapse
How do you set the density to 160 or 240 or whatever? I downloaded the ROM toolbox, but I cannot find under which menu this lcd setting is?
Everybody is talking about setting the LCD density as if it is already taught at the kindergarden.
velizet said:
How do you set the density to 160 or 240 or whatever? I downloaded the ROM toolbox, but I cannot find under which menu this lcd setting is?
Everybody is talking about setting the LCD density as if it is already taught at the kindergarden.
Click to expand...
Click to collapse
Ha, that was my reaction too. I had to search a lot to find the procedure. The techies seem to assume that we all know this stuff, and have probably gotten tired of explaining it to every noob (understandable).
You can use the LCDDensity app, it's the easy way. You set the new density, it reboots into what you just set. However, reboots after that seem to go back to the default of 161.
I use the Root Explorer app, which allows you to go into build.prop and change the LCD density there.
Open Root Explorer.
Open 'system'.
At the top you need to change r/o, read only, to r/w, read/write, by pressing the box that says 'Mount R/W'. It'll change to 'Mount R/O'.
Long press 'build.prop'. Choose 'Open in Text Editor'
Scroll to line that says qemu.sf.lcd_density=161
Change 161 to 160 or 240, or whatever
Press menu>Save & Exit
Press 'Mount R/O' to change back to read only.
Voila.
I've had LCD Density at 240 for about 2 weeks now. No problems here with the market. =) Sometimes the apps dont show up in the list but you can still update them by manually searching, which subsequently adds the app to the list.
It's large, but surprisingly, I actually like the largeness.
PoisonWolf said:
I've had LCD Density at 240 for about 2 weeks now. No problems here with the market. =) Sometimes the apps dont show up in the list but you can still update them by manually searching, which subsequently adds the app to the list.
It's large, but surprisingly, I actually like the largeness.
Click to expand...
Click to collapse
The market seems to differentiate between tablet offerings at 160 and phone offerings at 240. In fact, on a freshly refreshed market at 160, you can find a category titled "editors picks for tablets" at the top. No such heading exists when the market is refreshed at 240. But even then, all previously downloaded apps can still be updated.
This is probably why you can't find some apps, but can still update them.
This seemed to work for me in Terminal Emulator:
1 su
2 pm disable com.android.vending.updater
If by chance things go wrong, you can just enable updating.
Axecaster said:
This seemed to work for me in Terminal Emulator:
1 su
2 pm disable com.android.vending.updater
If by chance things go wrong, you can just enable updating.
Click to expand...
Click to collapse
This does work pretty well, thanks
Sent from my NookColor using Tapatalk
Also the blade buddy app in the market has a tool to change LCD density and it holds after reboots.
Axecaster said:
This seemed to work for me in Terminal Emulator:
1 su
2 pm disable com.android.vending.updater
If by chance things go wrong, you can just enable updating.
Click to expand...
Click to collapse
Awesome! Doing that and then uninstalling the updates brought the old market back. Quick question, is this change persistant across reboots?
thereddog said:
I'm running CM7 nightlies on my Nook, just wondering what I need to do in order to get the market work the way it's supposed to. (Hidden download buttons, can't update apps, etc)
Click to expand...
Click to collapse
I had my Nook Color with 1.2 and 1.3 manually nooted go into endless boot cycles after a while because of the Market automatic updates.
I found that the automatic updates in Market screw up the latest manual nooter. Here's how I fixed the problem.
*IMPORTANT* You have to do this before the Market first updates itself resulting in an endless boot cycle. This procedure will unfortunately also stop automatic updates to the Market. However, it also stops the Nook Color going into the endless boot cycle after the first Market update.
1. Wipe the device (8 failed boots) and clean the memory (press and hold n while booting and keeping the power key depressed).
2. Complete the B&N registration process.
3. Upgrade to the latest B&N firmware (I tried 1.2 manually)
4. Use CMW and manual nooter by following this http://forum.xda-developers.com/show...1054027&page=1 to root your Nook Color.
5. Use the Market to download Terminal Emulator (see https://market.android.com/details?i...roidterm&hl=en for details)
6. type
$ su -
# pm disable com.android.vending.updater
Check out
http://forum.oxygen.im/viewtopic.php?id=919 for more on this.
You have to do this before the Market first updates itself resulting in an endless boot cycle. This procedure will unfortunately also stop automatic updates to the Market. However, it also stops the Nook Color going into the endless boot cycle after the first Market update.
So you guys are telling me that you all will have to use the OLD MARKET for the rest of your life?
You guys not gonna tell me that you are waiting for the fix, aren't you?