yashsingh1/xdaforums huggingface dataset:
[Off-topic] LaserChicken:
The other day while filling my cats water dish, I spilled some of the water on me. My phone (droid X) was in my pocket, I got slightly wet through my bathing suit. By slightly I mean I still have a nice red x on a white circle. The only place I could see water had hit is on the bottom of the phone where the push button are placed.

I wiped it off and pressed the buttons which gave a funky response and the screen did this jiggy thing. I panicked and pulled the battery, got on then net to look for advice. The best option I found was to place the phone and battery in a bowl of rice. I did so. It has been 2 days in the rices, I tried to boot it once at about 24 hours, and again at approx 48 hours--no dice-nothing, Mercury has more signs of life.

The phone, unlike every other danged thing I own is NOT insured--so that's out the window.

Does anyone have any other suggestions beyond the rice trick?

If not, does anyone know of a good place to buy a used or refurb Droid X?

Thank you for taking your time, any goodhearted direction is appreciated.
[Off-topic] hateem:
I am a student doing an Interdisciplinary project as part of the Scottish Baccalaureate.

The aim of my project is to determine whether mobile application development is a sustainable business.

I will be needing some figures in terms amount of applications sold and the amount of monthly profit, if possible (average).

There will also be a section in my report which includes a detailed comparison between the trends of people buying applications, whether they are more likely to buy or just download the free app, and also the possibility of them buying a PRO version of the app.

All information provided might be used in my report, none will be given to any third parties.

My final report on my project has the possibility of being published in a research journal depending on the quality of it.

Any developer interested in taking part in this, and helping me please send me a message.

Please include your developer name (Android market, or Apple)

The name of your app/s you wish to include in this research

Your name on XDA

Also just send me a message or post here if you have any questions about my project.
[Off-topic] hateem:
bump.........
[Motorola Droid 3] deyna:
i flashed the leaked update the other day and since then i've my phone has been crashing and rebooting on me multiple times an hour. i thought it was the bloat removal script so i undid it but it's still rebooting randomly.

any help is welcome
[Motorola Droid 3] e-drian:
I'd experimented some random reboots but different from you I didn't update, just root my phone.
[Motorola Droid 3] suzook:
Wipe data...reflash. if you still have issues, get an exchange.
[Motorola Droid 3] deyna:
will do.

i got this phone as a gift though so i'm not sure if they'll exchange it.
[HD7 General] mobi:
From searching a little, I think I already know the answer but I'll ask anyway.

Is there any way to backup your live tiles, your texts, your apps and any other little tweaks or is the only way to do it by basically creating an image or backing up through Zune?

Cheers.
[HD7 General] mobi:
I guess by the amount of replies, it doesnt exist...
[Motorola Droid Bionic] dadajack:
I uninstalled the Zumocast app while playing with my new phone. If someone can give me a link to the .apk, that would be awesome. Or, if there was another way to find it, I've already Google'd it, I would love to hear the enterprising soul's method of doing that. Anything to prevent me from running the FXZ so soon. I'm not scared, soft bricked my Dinc a lot when I was learning about it back in the day. Anyway, my bionic is rooted, I just would like to have the zumocast app back. I didn't get to play with it before I inadvertently erased it. Thanks in advance to anyone with some guidance.
[Motorola Droid Bionic] bill1253:
here you go

http://www.mediafire.com/file/nvalpdp23frans7/com.motorola.zumocast-1.apk
[Motorola Droid Bionic] dadajack:
Thanks man. That did the trick. Thread closed, unless anyone else needs this apk.
[Motorola Droid Bionic] raritan01:
where did you find that app?
[Motorola Droid Bionic] Terri M:
The zumocast apk and odex can be found in the /system/app folder.
[Motorola Droid Bionic] dajmanjt:
thanks for this link. i just asked for it in another thread and then stumbled across it here. is this the newest version?
[Motorola Droid Bionic] schneiderman:
Latest version?

ZumoCast updated to version 1.1.1 today(?). It fixed a problem with folders containing a very large number of files. Where can I find the .apk?
[Galaxy S II Original Android Development] ykkfive:
hi all,

first of all, i would like to say that i'm no expert in c, and this post is not intended to blame anyone but want to raise this concern only.

since i started to mod i9000's kernel source code, i found some unneeded conditional statements in the original source and modded OC/UV sections which can be avoided very easily and thus consuming less resources.

let's take a look in this example from the original source:

for (i = 0; i < LOOP_CNT; i++) {
tmp = __raw_readb(iem_base + S5PV310_APC_DBG_DLYCODE);
sum_result += tmp;
hpm[i] = tmp;
}
for (i = 0; i < LOOP_CNT; i++)
printk(KERN_INFO "ASV : hpm[%d] = %d value\n", i, hpm[i]);

the second for loop is definitely unnecessary, and it should be changed to something like:

for (i = 0; i < LOOP_CNT; i++) {
tmp = __raw_readb(iem_base + S5PV310_APC_DBG_DLYCODE);
sum_result += tmp;
hpm[i] = tmp;

printk(KERN_INFO "ASV : hpm[%d] = %d value\n", i, hpm[i]);
}

let's take a look at another extreme case, taken from the OC/UV section:

if (index < L6)
{
if (old_index == L0)
index = L1;
if (old_index == L1)
index = L2;
if (old_index == L2)
index = L3;
if (old_index == L3)
index = L4;
if (old_index == L4)
index = L5;
if (old_index == L5)
index = L6;
}

it is obvious that, if old_index=L0, it has to go thru the remaining 5 if statements which shouldnt be. isnt it be nice and more efficient to chg it to something like below or use switch case instead?

if (index < L6)
{
if (old_index == L0)
index = L1;
else if (old_index == L1)
index = L2;
else if (old_index == L2)
index = L3;
else if (old_index == L3)
index = L4;
...
...
...
...
}

since we all aim at producing better and faster kernels, i think this is a good practice to clean up the codes while we r modding

thx for your kind attention :)
[Galaxy S II Original Android Development] ykkfive:
and this is the most ridiculous part that i've ever seen in my life, which can be found in I9000 source also. if u have 10 frequencies set, then instead of running the loop 10 times, this will run 50 times in total

arch/arm/mach-s5pv310/cpufreq.c, inside static int s5pv310_update_dvfs_table()

for (i = 1; i < CPUFREQ_LEVEL_END; i++) {

s5pv310_freq_table[i-1].index = s5pv310_lookup_freq_table.index - 1;

s5pv310_freq_table[i-1].frequency = s5pv310_lookup_freq_table.frequency;

printk(KERN_INFO "index = %d, frequency = %d\n",

s5pv310_freq_table[i-1].index, s5pv310_freq_table[i-1].frequency);

}

for (i = 1; i < CPUFREQ_LEVEL_END; i++) {

s5pv310_volt_table[i-1].index = s5pv310_lookup_volt_table.index - 1;

s5pv310_volt_table[i-1].arm_volt = s5pv310_lookup_volt_table.arm_volt;

printk(KERN_INFO "index = %d, arm_volt = %d\n",

s5pv310_volt_table[i-1].index, s5pv310_volt_table[i-1].arm_volt);

}

for (i = 1; i < CPUFREQ_LEVEL_END; i++) {

s5pv310_apll_pms_table[i-1] = s5pv310_lookup_apll_pms_table;

printk(KERN_INFO "apll pms_table = 0x%08x\n", s5pv310_apll_pms_table[i-1]);

}

for (i = 1; i < CPUFREQ_LEVEL_END; i++) {

for (j = 0; j < 7; j++) {

clkdiv_cpu0[i-1][j] = clkdiv_cpu0_lookup[j];

printk("%d, ", clkdiv_cpu0[i-1][j]);

}

printk("\n");

}

for (i = 1; i < CPUFREQ_LEVEL_END; i++) {

for (j = 0; j < 2; j++) {

clkdiv_cpu1[i-1][j] = clkdiv_cpu1_lookup[j];

printk("%d, ", clkdiv_cpu1[i-1][j]);

}

printk("\n");

}
[Galaxy S II Original Android Development] KLoNe1:
Interesting...
[Galaxy S II Original Android Development] xan:
This might be right. My C is bad, but some OC/UV patches look really quite 'whatever works' for me. I dont say its bad - having something is better than nothing.

Its always good if some skilled coders do reviews of such patches.
[Galaxy S II Original Android Development] joecisd:
good finding and the samsung programmers are really ............... bad...
[Galaxy S II Original Android Development] ykkfive:
i think it's not samsung's problem, instead, it should be unsolved/overlooked problems brought forward from linux kernel
[Galaxy S II Original Android Development] avetny:
yeaaa Hong Kong :D

Do you want make a kernel for us? ;)

regards
[Galaxy S II Original Android Development] kalpik:
Nice catches :)

Hope most devs are already taking care of this!
[Galaxy S II Original Android Development] ykkfive:
sorry, but maybe u don know me coz i'm a newbie here in the i9100 section

as in the i9000 forum, i usually prefer not to release files, except some quick fixes like sms sent time mod, but i'll tell u guys my findings, dirty tricks, and how to instead

sorry about that
[Galaxy S II Original Android Development] ykkfive:
glad to see that some of you guys already fixed, or started to fix those redundant conditional statements

and ultimately, hope that one day these will be collected as a whole and stored somewhere for everyone like our kernel source code repo here
[Galaxy S II Original Android Development] netchip:
I go try to clean up my code.

I only have a little C++ skills and no C but I give it a try ...
[Galaxy S II Original Android Development] killerjohn:
maybe if you upload the code to somewhere (for example into a wiki, or pastebin???) we can check it. Personally I've 20years of programming exp in 4 languages, and I'm sure a lot of people like me is already here :) We can't make the ROM "a lot faster", but basic structural bugs can be wiped out in a short period of time (like the "if else if else if else" example in the first post).

PS: sry for my english :D
[Galaxy S II Original Android Development] Guiper:
I'm also not an expert in C or kernel development, but i'm quite sure, that gcc is smart enough to check that some code is redundant and do that kind of optimizations in compile time (if you enable the optimize flags).

Feel free to give it a try, i'm also curious, but i think the final assembly code will be pretty much similar.
[Galaxy S II Original Android Development] netchip:
Okay, I go.do.that

Sent from my GT-I9100
[Galaxy S II Original Android Development] ykkfive:
yeah, i know. i was learning from your source in github last nite :P

that's great. yes, most of them are structural problems actually

i know gcc is quite smart but i doubt if it can handle the conditional statements automatically if something like:

if (a is a male) then a is a boy

if (a is a female) then a is a girl

so actually, a should be checked once only coz we all know that in our daily life. but sometimes we need a bit more complicated logics like:

if (a contains red) then color = red

if (a contains green) then color =green

if (a contains blue) then color =blue

if (a contains blue & green & blue) then color = gray/black/white (by assuming the portions of red, green and blue are equal)

perhaps this is not a good example, but i just want to point out that not every set of conditions are redundant sometimes and hence gcc may not be able to handle it, i think (i'm not a gcc expert neither, pls correct me if i'm wrong :D )

but i've modded some smali before and found that even a very simple for loop in java can produce a lot of goto statements in the assembly code which can be clean up also :p
[Windows 8 General] jackrabbit72380:
Ware Can I Find A 24 Inch WideScreen Touch Overlay Kit?

have serched for a couple months now useing bing & google with no luck

I have a 3D LG D2342 24 inch computer moniter i realy want to add a DIY touch

screen kit to!

I want it to use Windows 8! on my desktop pc!
[Windows 8 General] khrisstyan:
You can search on ebay ;)
[Windows 8 General] jackrabbit72380:
i have serched all over ebay and found menny kits but not the right size!
[Windows 8 General] SWEATTAIMI:
simply post this in general section as this has NOTHING to do with windows 8, just saying
[Windows 8 General] jackrabbit72380:
actuly it dose becuae it will allow other 24 inch moniter users totake advantage of windows 8 touch screen capabilitys!
[Windows 8 General] syncron:
I'm actually looking for the exact same thing.
[Galaxy S I9000 Android Development] ragin:
I think you need to put a [MOD] in your title.
[Galaxy S I9000 Android Development] Rootax:
First, thx you for sharing your work !

Your .zip patch the existant ondemand governor, or it is adding a new governor which can be selected via app like voltage control & such ?
[Galaxy S I9000 Android Development] cnn888:
Anyone wanna try this out and share what it does actually? All thoaellse reading above are too technical for most of us I guess. I'd love to try but I'm on JVS now and you said it is for JVR.

Thanks for the share by the way...
[Galaxy S I9000 Android Development] newmail:
Well I'm running the JVS kernel on top of JVR userland+initramfs. It'll run perfectly on JVS but I only posted the source and it'll work for both :)

I'm also a bit annoyed often I see mods and tweaks and I try to search the source and it's not so easy to find it. I'd recommend people to post more source and less binaries.

You just need to ask one kernel builder that ships with the ondemand governor to apply my patch, add those 3 lines to the initramfs/init.rc file and rebuild and it'll work for JVS too. Theoretically it will drain less when the screen is off and it'll be a bit more responsive when screen is on.

---------- Post added at 07:42 PM ---------- Previous post was at 07:36 PM ----------

The whole point of this approach is not having to change governor and to share the ondemand governor which must provide max performance and max responsiveness on laptop and desktops so I don't see the point of creating a new governor when the screen is on, considering the requirements are the same.

I thought lowering voltage was considered risky, I don't want to change voltage but if you want to change the voltage I think the best place to do it is still my two handlers I added in the patch, no new governor required, I doubt you want to change voltage when the screen is on, and when the screen is off I guess you want always the lowest voltage and lowest freq like me.

A new governor is not needed in short, just a few liner patch to set the max freq at the lowest when screen is off is my preference, especially because it's so much simpler :)
[Galaxy S I9000 Android Development] cnn888:
right... and umm... suppose that i want to apply this mod, how do we apply this patch of yours?

i'm sorry but am not really a linux frenzy...

:D
[Galaxy S I9000 Android Development] zacharias.maladroit:
re-build kernel source ;)

great work newmail !

another (non-invasive) approach

would be to use a bare screenstate_scaling (well - not really scaling)

init script and limit the max frequency via that + set those values :)
[Galaxy S I9000 Android Development] newmail:
Thanks.

I figured with csipsimple with the proximity sensor, 100mhz are not enough.... so I'm now decreasing the max frequency to 800mhz when screen is off, and I'm keeping the default sampling_rate to 10000 msec (setting transition_latency to 10000, equivalent to writing 10000 into ondemand/sampling_rate).

I also changed the code a bit to call all notifiers when the max frequency changes from 1ghz to 800mhz.

Now I did quite a bit more tests and something's going wrong when screen goes off in cpufreq. The cpu is idle, but ondemand raises the frequency more than if the screen is on. That is probably why the cpu isn't very idle when the sampling_rate is reduced go give more responsiveness. If I change get_cpu_idle_time_us to return -1 unconditionally, the trans_total are greatly reduced with screen is off and the ondemand stays at the low frequency when screen is off with sampling_rate 10000 too.

I also tried to measure the cost of a frequency switch (including the overhead caused by ondemand sampling at 1khz) and it seems of the order of 38usec.

I'm wondering if there's some bug in the get_cpu_idle_time_us that is causing the jitters in the ondemand governor when screen goes off.
[Galaxy S I9000 Android Development] newmail:
I could upload a .tar file to flash in odin somewhere... but I worry about the redistribution of a zImage with an initramfs including those annoying binary modules that aren't GPLv2 (or we would have the source of those too) and I can't easily get rid of.
[Galaxy S I9000 Android Development] newmail:
Dividing the load by deep_sleep_ratio was too aggressive. I noticed some app was more laggy than with "performance" governor. The better approach to the long deep sleeps is to ignore jitters until the wall_time_delta converges. I added comments on the reason why this is better, and it seems also better to ignore time jitters in both directions (so also to ignore measurement of long wall_time when the wall_time_delta average is short, with screen on). I attached an update, it still avoids the jittering with the screen off and phone idle, and it works better with the phone on.

With this one phone sits at 100mhz with screen off (freq range with screen off 100mhz-800mhz), works fine when doing voip calls with proximity sensor as before. With screen on the freq range is now 200mhz-1ghz, considering that without the patch the phone may never reach 100mhz even with screen off, it is most certainly not going to make a difference and 100mhz is way too slow and we've to run at least 10msec at 100mhz before we can ramp up the freq. So this will double speedup those first 10msec compared to the prev version. The jittering with screen off completely goes away and the phone stays at 200mhz fixed if you disable the rotation sensors, otherwise there are 2 jitters from 200mhz to 1ghz and back per second, which is certainly fine.

I've been using for a while and I'm pretty happy and should work better than the previous version. That app were I noticed an higher lag with previous version, now seem to be as responsive as performance or at least I can't see a difference anymore.

If you test it let me know and please check when screen is off and phone not awake, if the battery is lasting longer or not. By looking the chart I attached (running the sleep2 version in this post) it seems my battery went down 2/3% in 6 hours with this. Frankly I don't remember if it was as good before... all I know for sure is that what happened before with ondemand didn't make much sense: a proper governor allowed to use a range from 100-800mhz must keep the cpu at 100mhz when screen is off and phone is idle, and with the deep sleep detection fix, ondemand finally behaves well, and it works fine with voip with screen off, it doesn't require to rump up the min freq from 100mhz to 200mhz with screen off, and it seems more responsive than before thanks to the 4 times more frequent sampling rate (and maybe also thanks to ignoring the long deep sleep cycles during interactive behavior but that I'm not entirely sure if it helped but it still looks good idea to ignore the infrequent wall_time_delta jitters). It's also likely that the cpu goes into very long deep sleep shutting down the cpu harder and maybe the freq it enters those states don't matter, but at least this should help if you play music in the background with the screen off, it manages to do that now at 100hz without skips.
[Galaxy S I9000 Android Development] pikachu01:
It's certainly refreshing to see good research being done in a consistent manner. Keep up the good work :)
[Galaxy S I9000 Android Development] newmail:
Thanks :) well it all started with my phone being 80% dischared for two mornings in a row and that annoyed me enough to look into this. I was pretty certain it wasn't a kernel problem (I think it was the broken update of the facebook app that has "keep phone awake" privilege and is buggy, I uninstalled it since then) but that still made me look into this... and what I found looking at the cpufreq stats with screen off wasn't too pretty, it just become utterly ugly if I decrease the sampling_rate to 10000, and so I spent the weekend trying to fix it. In any case I'm unlikely to post further updates until next weekend :).

Another possible way to fix this would have been to have the cpuidle governors interacting with the cpufreq governors through some notifier call... but adding a small heuristic to ondemand to detect the wall_time_delta jitters was certainly simpler.
[Galaxy S I9000 Android Development] zacharias.maladroit:
well, I don't know how motivated or how much time you want to spend in investigating this

but if want to dedicate some more time

make sure you also take a look how ondemandx works :)

(cpufreq_ondemandx.c in my repo)
[Galaxy S I9000 Android Development] newmail:
Thanks for the pointer! Appreciated :). I won't have much time to look into this until the next weekend (I'll look into it ASAP :), but with the last version I posted in comment #11 (ondemand-deep-sleep2.patch) things are going absolutely great. In fact it works much better with skype than the stock unpatched kernel: when I iconize skype during a call it won't degrade the audio anymore. I'm sure it degraded audio for a little if I iconized skype and started another app during a call. I guess it's the faster sampling rate, or maybe the fact I now ignore the long idle times if the average wall_time is short. Both are good.

The sampling_rate not being constant with long cpuidle times that disregard software timers, really requires this fix to the ondemand to perform great. So I'm super happy about this change so far. 100-800/200-1000mhz also works great. And this change won't have any effect on laptops/workstations where the timers should fire as expected. (I also tried 100-400/400-1000 for a while but there's no point it seems, 100-800/200-1000 is enough so I'm back to the exact values in the last patch I posted)

I doubt it's worth to stop the sampling like interactive governor does while cpu is idle, considering cpuidle will disregard the timers so there's no risk to wakeup too early because of a timer it seems.... I think this changes will improve ondemand in general and it is required fix for these phones IMHO.

The fact background apps like music player with screen off now run 95% of the time at 100mhz also looks great. I didn't have any sign of instability, and I run a lot of load on it (though only for the last few days...). I sent my patch to some samsung engineer who added the SLEEP_FREQ to the cpufreq upstream code (to enter suspend to ram at 800mhz which I didn't alter, that sure is fine change considering the cpu is cut off the power during suspend to ram, it'll speedup suspend to ram too in addition to not crashing phone as described in the patch :). In my patch I only handle the frequency changes right when cpuidle runs for long and I doubt the cpu is cut off the power for only 60msec or 500msec when screen is off, that's too fast to cut the power completely I guess so I think it's worth it. And if it doesn't help to save power when idle, for it sure won't hurt either and the statistics now look sane and this change should help while using the phone too by allowing to lower the sampling_rate and avoiding interactive usage to be fooled by long cpuidle samplings started at high freq that decrease the freq just before the real loads come in and idle is exited (ignoring those long wall_times during interactive usage is also good and should save power too as the load will complete faster and cpu will be allowed to spend more time in idle at low freq then).
[Galaxy S I9000 Android Development] dachau:
Deep Sleep

Hi, you said that you first came to this topic because some app was keeping your CPU from deep sleep, probably FB app. This night I also experienced that the phone did not go into deep sleep, it was awake all the time according the battery status. So is there a way to check, which app causes this behaviour?

See attachment for a screenshot.
[Galaxy S I9000 Android Development] zacharias.maladroit:
newmail, against what kernel base does your patch apply ?

samsung kernel sources JVB & JVH (1st release + 1st update) ?