Database Develop

Txtract...question

its been extracting to HTML to save on my sdcard for the past 20 minutes and it says its still working on it....is it me or is everyone else also its working slow in exporting it to HTML to your sdcard?

hi there,
unless you have 1000000 messages, it should not take that long. it seems like the progress dialog is stuck. Try doing something else on the phone and get back to txtract later on. The progress bar should disappear. In a similar case I came across myself, the file was properly generated but only the progress bar was spinning.
1.5 release of Txtract hit a performance glitch (better coding vs. performance dilemma), and it's already pinpointed and fixed. I'm working on updated version as I type this post. It should be ready shortly.

Log entry: No package identifier when getting value for resource number 0x.....

WARN/ResourceType(153): No package identifier when getting value for resource number 0x7f030004
I get a whole slew of these in my logs. Can anyone tell me what they mean, if (how?) I can get rid of them and/or if they are taking up resources/time?
I've been getting them for a long time, I have a hard-core app addiction (256 last I checked).
I also get "cannot enable wifi" a lot, especiallly shortly after boot, and don't know what that's about? But eventually it seems to resolve itself. If you've got a line in on that q, too, I'd love to know what's up with that.
Thanks.
Edit: If you want an answer to this, too, please bump the thread by saying so.

bump
Anyone? I get tons. Even just a place to look to start cluing myself in would be fantastic.

I wish I knew - I get tons of these too and my G1 is extremely unstable (especially the radio) since a recent CyanogenMod update - the log shows a lot of low memory messages.

Filed as j.mp/8ELTN5 in the cyanogenmod issue tracker (sorry, the spam prevention won't let me turn this into a proper link)

Wipe you Dalvik cache, the do a logcat on reboot. Does this come up as often after the wipe?

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

RAM in Froyo: welcome to Hell

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.

Attempt to reduce Jpeg compression

Having an interest in photography and the want to use my HTC One as my pocket camera when I don't have my DSLR with me, I've noticed on a larger screen the pics aren't as good as I had hoped. My previous phone was an HTC Evo 3D and the Jpeg compression on that phone was pretty high. A kind dev released a mod to improve the camera software and what a difference!
This is not that mod. In fact, I am far from capable of doing any Android mods. Instead, I'm experimenting to see if the HTC One has high Jpeg compression as well. I am using the information on this page to see if there is any improvement on pictures taken with the camera.
As I notice anything, I'll share it.
What I've done so far (which is based on the info in my source link):
1. Backed up my media_profiles.xml file (/system/etc/media_files.xml) -- ROOT REQUIRED
2. Opened my media_profiles.xml file and made the following changes
Changed "<!ATTLIST ImageEncoding quality (90|80|70|60|50|40) #REQUIRED>"
to "<!ATTLIST ImageEncoding quality (100|95|90|85|80|75|70|60|50|40) #REQUIRED>"
Changed TWO sections of
"<ImageEncoding quality="95" />
<ImageEncoding quality="80" />
<ImageEncoding quality="70" />
<ImageDecoding memCap="20000000" />"
to
"<ImageEncoding quality="100" />
<ImageEncoding quality="100" />
<ImageEncoding quality="100" />
<ImageDecoding memCap="20000000" />"
3. Save file as media_profiles.xml in /system/etc/ (I kept the original in a backup folder)
4. Rebooted phone
what this does is force the phone to always use 100 jpeg quality every time, thus reducing the artifacting caused by jpeg compression.
I haven't setup any before/after photos yet, but I plan to compare. I won't have time for about a week to get to that, however.
I'll welcome any additional information to better explain this, additional suggestions, etc. This has been done many time in the past and what I'm doing isn't new. Just sharing it here and experimenting myself.

You're going to have to dig deeper than XML editing to accomplish this. It's in smali also.

SteelH said:
You're going to have to dig deeper than XML editing to accomplish this. It's in smali also.
Click to expand...
Click to collapse
Thanks... Something I don't know how to do nor have the time to learn.
Sent from my HTCONE using xda app-developers app