yashsingh1/xdaforums huggingface dataset:
[Touch Pro2, Tilt 2 Android Development] highlandsun:
Pretty sure I committed the Sprint MMS fixes to both FRX and GBX last year. That should not be a problem any more.

The facebook app is just atrocious. I uninstalled it and just use x.facebook.com in the browser now. On my rhod210 it made the difference between the phone not lasting 1 day on a single charge, to lasting 3 days (if totally idle).

It is very unrealistic of you to expect this phone with less than 256MB of free RAM to run well with lots of apps loaded. It is very unrealistic of you to expect anybody to be able to identify deep system-level issues if you muddy the picture with random apps. We already know that certain apps break system features (e.g., Pandora breaks Bluetooth). When you add variables to the situation you only make it harder to diagnose issues. When you do so intentionally, you only make developers want to ignore you.
[Touch Pro2, Tilt 2 Android Development] arrrghhh:
Woah woah woah, you also have to realize there's even less actual developers, and you're basically badgering literally one of the last ones we have. I'm not calling you an idiot, and there's probably a pretty big misunderstanding going on here.

If anything, you definitely should be on that page... Hell, you have commit access to most of GIT.

Don't let people sour you. Keep helping, even if it's in the background. It is appreciated. I mean look at what you did with XTRA? Brilliant, even if it was just taking what the Leo guys did and adapting it back to our junk.

This.

I suck at reading logs, and the more junk that is in the way, the more impossible it becomes to make any sense of them. The less apps, the better - if the issue can be recreated with a completely fresh data.img and no apps installed? Then why not provide logs with no apps installed. Keep your old data.img to revert back, but seriously, it helps immensely to see clean logs.
[Touch Pro2, Tilt 2 Android Development] slickdaddy96:
I apologize for any misunderstanding that my posts made. I am just frustrated about the phone. I did a clean data.img and only synced my contacts and installed getlogs.

http://pastebin.com/b55djwvp

Attempted the incoming test 3 or 4 times. Still took between 3-4 rings on the other phone before the UI popped up and I was able to slide to answer.

Outgoing I could not reproduce the problem I was having previously, which does lend me to believe it had to be lack of available memory when placing an outgoing call that was causing slow dialer UI to show up to place the call. I will start adding apps back one by one and try to dial out each time to determine either what app or how many apps have to be loaded before the memory has so much issue that it cause the outgoing failure.

Seems to be that on a clean data.img without anything installed it acts very similar to how FRX07.1 was acting, only having issues with incoming calls basically.

As for goSMS hyc, the 12/30 build of GBX0B did not have your fix in it. I believe that fact was discussed in this thread somewhere. I was unaware that arrrghhh had included the Sprint MMS fix in the 1/18 build, so no more goSMS which is great because I hated that app, but needed MMS since I get them sent to me all the time with kids...
[Touch Pro2, Tilt 2 Android Development] arrrghhh:
Not sure if it's me or what, but this is an empty paste.
[Touch Pro2, Tilt 2 Android Development] slickdaddy96:
Weird it isn't there now. I put the link in the post, and then clicked it to make sure it went to the site correctly and it was all there as of when I made that post. It is now gone. I will have to re-test and resend unless you can tell me if getlogs saved that file somewhere on my phone. About to head out, so if I can't find the file on my phone I will get to it later this afternoon/evening. Although at this point I had already started adding apps one by one back to see what if any app was causing the hang on outgoing calls. So far I haven't found an app that did it. To re-do the test and getlogs I will have to create a new data.img again at this point.
[Touch Pro2, Tilt 2 Android Development] arrrghhh:
Well, AFAIK if you click the "pastebin" button in GetLogs the log is not stored on the device at all...
[Touch Pro2, Tilt 2 Android Development] slickdaddy96:
Here you go. I only did one getlog capture this morning and that is the date on the file so it has to be the right one.

http://db.tt/RlMRuJ6P

Edit:

I have added every app I used (not as many as I had before because some I never used anymore just hadn't uninstalled) except facebook which from my earlier logs seemed like it was giving the most issues usually. Not sure if facebook actually cause the issues or not, but I am not installing it back to figure it out. I was able to put back on my beautifulwidget (clock/weather widget that looks like the sense clock) with no problems other than the original problem I stated on the new data.img which is incoming calls taking 3-4 rings before the UI shows up to answer them, but I am starting to think that might just be a carrier/tower thing routing the call to the phone, because if I remember right back when I used WM 6.5 I had similar incoming call issues sometimes.

So I guess I will chalk my outgoing call issues to either a corrupt data.img file or possibly facebook screwing it up.
[Touch Pro2, Tilt 2 Android Development] arrrghhh:
So this is just the old incoming call issue? That seems to be uniquely CDMA, although I'm not positive. I just haven't seen as many GSM users complain about that. Lately I've seen GSM users complain about a lot of other radio-related insanity...

The facebook app really is truly awful. Look at its rating on the Market... it's bad on native devices, and wreaks utter havoc on ours! The mobile/WAP site works well in a browser...
[Touch Pro2, Tilt 2 Android Development] CodaHighland:
I went and dug up my old log that I posted... and now I'm particularly confused, because I don't actually see any failures in that file. *headscratch, sigh* This is frustrating.
[Touch Pro2, Tilt 2 Android Development] CodaHighland:
New attempt at this.

http://pastebin.com/HkDyN137

Tried to call the local deli. This is visible in the log at line 726 (CALL_PRIVILEGED intent). It appeared to have failed, so I attempted another call, which can be seen on line 732 (just CALL). The in-call screen that opened gave me the option to merge the calls, so I hung up the second one and attempted to resume the first one but I assume the other party had hung up already.

Around line 1998, the RIL is acting a little curious; I don't know if it's relevant that there's ERROR_UNSPECIFIED there.

The kernel log for the calls starts around line 3500, but I don't see anything relevant there.
[Touch Pro2, Tilt 2 Android Development] detule:
726 and 732 are the same call. Your second call is @ 864.

I think the problem is in the radio log, in particular during your call this sequence

03-11 18:56:13.719 D/RILJ ( 1423): [0084]> GET_CURRENT_CALLS
03-11 18:56:13.719 D/RIL ( 1279): onRequest: GET_CURRENT_CALLS (9)
03-11 18:56:13.729 D/AT ( 1279): AT> AT+CLCC
03-11 18:56:14.249 D/AT ( 1279): AT< WCDMA
03-11 18:56:14.249 D/AT ( 1279): AT< 0
03-11 18:56:14.249 D/AT ( 1279): AT< [WCDMA] WAKEUP PDA: U(),T(),R(DS)
03-11 18:56:14.249 I/RIL ( 1279): Calls=0,Valid=0
03-11 18:56:14.249 I/RIL ( 1279): Audio Close
03-11 18:56:14.249 D/RILJ ( 1423): [0084]< GET_CURRENT_CALLS
03-11 18:56:14.249 D/RILJ ( 1423): [0085]> LAST_CALL_FAIL_CAUSE
03-11 18:56:14.259 D/RIL ( 1279): onRequest: LAST_CALL_FAIL_CAUSE (18)
03-11 18:56:14.259 D/RILJ ( 1423): [0085]< LAST_CALL_FAIL_CAUSE {65535}
03-11 18:56:14.269 D/GSM ( 1423): [GSMConn] onDisconnect: cause=ERROR_UNSPECIFIED
03-

CLCC is supposed to return a listing of current calls (in a very specific format). I am not sure what that "AT< WCDMA" that follows is, but it's not the proper response. I think this prompts android to act as if the call has been dropped. That sequence doesn't look correct - the when you tried to dial again, and android tries to poll the current calls (CLCC again):

03-11 18:56:40.942 I/RIL ( 1279): Calls=2,Valid=2

Now it's back to normal - two active calls and this is why it asked you if you wanted to merge the calls.

Of course this is all speculation on my part - hyc is the ril expert and perhaps he can interpret the call sequence better.

You said you are compiling your own gbx? Perhaps turn on all debugging in frameworks/base/telephony/java/com/android/internal/telephony/gsm/GsmCallTracker.java to verify that this is why userland decides to kill the call.
[Touch Pro2, Tilt 2 Android Development] CodaHighland:
Thanks for that, detule. That's the most progress I've gotten on this issue yet, and this may be enough to help me fix it.

No, I said I have an Android build environment set up. I'm using the "official" GBX0B build on my phone. I suppose I could try building my own; are there any patches needed to the stock Android 2.3 sources? Or are we totally stock except for the kernel?

Anyway, that's... curious. Why on earth would the AT command respond like that? (I'm vaguely amused that the RIL is Hayes-compatible. And "Hayes-compatible" is a term I haven't used in YEARS. *laugh* Flashbacks, man.) Is my phone malfunctioning? I wonder if I'd have this same problem in WinMo... it's just too bad it's so flaky; it doesn't happen consistently enough to intentionally test it.
[Touch Pro2, Tilt 2 Android Development] detule:
Can you replace /system/lib/libhtcgeneric-ril.so with this one and reproduce the problem. Then attach GetLogs output -> this lib won't fix the issue I've just added a debugging call to dump the CLCC line.

http://xdandroid.com/wiki/Main_Page (look for Building)
[Touch Pro2, Tilt 2 Android Development] CodaHighland:
Thanks again, detule. I've loaded in your debug version there. Go figure I can't reproduce it when I'm trying. It might be a day or two before I can post a followup.
[Touch Pro2, Tilt 2 Android Development] CodaHighland:
Ugh.

http://pastebin.com/AmQVLWek

The relevant call sequence starts at line 2130, at 17:51:01. The first AT+CLCC worked, but:

This almost looks like a network state change is getting interleaved with the call sequence, and the wrong routine is picking up the wrong data.
[Touch Pro2, Tilt 2 Android Development] highlandsun:
I suspected this was happening. Just not sure why it never happened in FRX.

The modem is spewing out diagnostic info all the time, independent of the current AT command and expected response. One thing you might try is to turn off Data mode, wait 30 seconds, and then try to place a call. By then the WCDMA state changes should have settled down.

I got to this point before, but by then I was too frustrated to continue using the phone...
[Touch Pro2, Tilt 2 Android Development] detule:
Hey, that WCDMA in the channel - would that be handled as unsolicited? We could put some logic in unsolicited to error (generic_failure) out the current calls poll and request a timed repoll. This way we don't send misleading information to userland.
[Touch Pro2, Tilt 2 Android Development] CodaHighland:
I was actually thinking of a solution similar to that -- detect the failure case (unrecognized data between AT+CLCC and the "0" sentinel in the response) and retry the query. But I don't know the Android architecture; your solution may be a lot cleaner.
[Touch Pro2, Tilt 2 Android Development] detule:
Hey can you swing by #xdandroid on Freenode, we could do this more efficiently over there.
[Touch Pro2, Tilt 2 Android Development] yelped:
Thanks for the new build and the hard work that's being put in here daily.

I have quite an interesting issue. The browser only loads one page and then stops loading further pages until you force-close the browser. The browser works (doesn't freeze), it just ignores any command to load a page.

Did anyone see this issue before? If so, please don't flame me. :)

Thanks!
[Touch Pro2, Tilt 2 Android Development] slickdaddy96:
I have never encountered that before to be honest, but recently I started using Opera Mini and it works a lot better than the stock android browser IMHO. I think it hogs less system resources also, or at least that is my experience, so that is a good thing on our phone.
[Touch Pro2, Tilt 2 Android Development] CodaHighland:
Well, detule, your patch you gave me on IRC didn't work. Logs:

http://pastebin.com/Dc7Nqydi

Will analyze later, just swinging by to drop this off.
[Touch Pro2, Tilt 2 Android Development] detule:
Thanks, I see what failed. I'll get you another version tonight. MadBeef you around as well? If we can get couple of people testing at the same time we could perhaps do this more efficiently.
[Touch Pro2, Tilt 2 Android Development] arrrghhh:
I haven't seen it before either, but I also don't use the default browser. Opera Mini was suggested, and is good. I prefer Dolphin Mini myself...

But either way, ditch the stock browser. It's pretty bad.

Thank you for your continued service :D.
[Touch Pro2, Tilt 2 Android Development] detule:
Ha, just keeping busy 's all...
[Touch Pro2, Tilt 2 Android Development] arrrghhh:
Hey, whatever you gotta call it. Would be really nice to get a solid, "final" version of GB out before we lose all our devs...
[Touch Pro2, Tilt 2 Android Development] CodaHighland:
@detule:

Seems to be working! I didn't notice anything, but I checked my logs on a whim. It actually was happening silently, rather than making the call drop, and it failed several times in a row before succeeding but the call never failed.

Truthfully I'm a little bit confused, as I don't see the ATD line in the log. I wonder if it got rotated out; it WAS a long call. This may mean that this was triggered on in-call status polling or something... Does UNSOL_RESPONSE_CALL_STATE_CHANGED trigger when the proximity sensor changes state maybe?

Relevant excerpt: http://pastebin.com/PbU4NxAn

Starting from the UNSOL_RESPONSE_CALL_STATE_CHANGED and going until it actually succeeds. Is this what you expect?
[Touch Pro2, Tilt 2 Android Development] detule:
Oh cool, thanks for the log - the patch it's working as it should. What's a little disconcerting is that it took the radio full 20 seconds to recover and return a proper call listing. I can envision this causing problems were it to happen while dialing out. Perhaps issuing repoll commands every quarter second (on failure) is contributing to the long recovery time -> unfortunately this is controlled in frameworks/base and no convenient way for me to change it and get you an updated build.

If you don't mind continue testing that would be great - and perhaps pull an occasional GetLogs to see what's happening.

Edit: If you run into any problems due to this slow recovery time, I'll just pause the thread for a given time to see if this helps speed up the proper call listing.
[Touch Pro2, Tilt 2 Android Development] CodaHighland:
That's what I was thinking, too.

I definitely want to keep testing. I have no problems watching my logs.
[Touch Pro2, Tilt 2 Android Development] CodaHighland:
D:

http://pastebin.com/Z2r0jcPD

New failure mode: Can't hang up a call! I tried to hang up, it returned to desktop, I went back to the phone app and selected "return to call in progress" and tried to hang it up from there and it wouldn't hang up. I tried to start a second call in hopes of hanging them both up... well, it's all in the logs; needless to say it didn't work.

I had to do the GetLogs while the call was still connected because doing a hard-reset of my phone would have flushed the logs out.
[Touch Pro2, Tilt 2 Android Development] slickdaddy96:
Hey Arrrghhh,

I was going to mention that earlier I patched the rootfs file to fix the Wifi-tethering. I did nothing else with the file, but I saw someone on IRC having problems fixing it. Do you want my patched rootfs so you don't have to fix it yourself, or do you mind if I post it on here? I don't care either way, but I figured it would help people that are either unable to patch a rootfs or just are too lazy to do so! :-)
[Touch Pro2, Tilt 2 Android Development] detule:
so.4:

http://bit.ly/x5ivUD

Hopefully with a longer delay, and a more surgical approach to which clcc responses get discarded.

As always, thanks for testing.
[Touch Pro2, Tilt 2 Android Development] arrrghhh:
What do you mean patched? If you just mean "added the new firmware", then no... I can do that lol.

If there is an actual patch that fixes something I'm not aware of, then I would be interested to see your patch. No use in posting the rootfs tho, that will just confuse peoples.
[Touch Pro2, Tilt 2 Android Development] slickdaddy96:
Phrased it wrong, I just mean the firmware... Still not good enough to do any coding yet. I think the people were already confused, so your right posting it will just make it worse.
[Touch Pro2, Tilt 2 Android Development] arrrghhh:
No worries, I think I can handle adding that firmware ;).
[Touch Pro2, Tilt 2 Android Development] CodaHighland:
Oh by all means. It's my pleasure to test this stuff. It's the least I can do in exchange for you helping me make my phone more usable. Honestly I wish I could do more.

What happened to .so.3? I only have 1, 2, and 4.
[Touch Pro2, Tilt 2 Android Development] highlandsun:
That is definitely weird, and definitely did not happen on my FRX builds. I think we should take a look at the radio log starting from boot time, and compare the Init sequences to the ones used in FRX...
[Touch Pro2, Tilt 2 Android Development] CodaHighland:
detule and I are speculating it may have something to do with the proximity sensor, since each time it toggles it triggers a bunch of AT commands and FRX didn't have proximity sensor support. I was actually wondering about that potentially being the case based on there being call state update notifications in the middle of a call, before I knew FRX didn't have it.

But if you're interested, I still have FRX installed on my SD card and I can switch between them just using different start menu shortcuts in WinMo, so I could make some logs if you think that would help.
[Touch Pro2, Tilt 2 Android Development] slickdaddy96:
Hey Arrrghhh or hyc,

Is it possible to incorporate a clean shutdown on the next build of GBX0B to prevent all those FCS**** files from being put on the sdcard? I know hyc that you had a clean shut down in your own FRX6+ build, I just didn't know how easy it would be to roll that type of patch or code into the GBX0B build.
[Touch Pro2, Tilt 2 Android Development] arrrghhh:
I don't think that 'clean shutdown' was anything related to a patch - it might've been, but wasn't it also mostly because it was put on dedicated partitions...?

Correct me if I'm wrong here.

Why not just delete the files? The *.user.conf file should do it automatically, unless you removed that line.
[Touch Pro2, Tilt 2 Android Development] slickdaddy96:
I am running stock (except for firmware, netloc, and gps fixes) no partition build. I can and do delete them, but I have noticed a non-clean shutdown ends up leading to data.img file corruption eventually where I have to start new again, at least that was my experience on FRX07.1. Is that not the case in GBX0B also? As for the conf file deleting them, as I said I am running stock and have not messed with the conf file, but I am still getting those files and they do not delete on their own. What is the line in the conf file that needs to be there?
[Touch Pro2, Tilt 2 Android Development] fishingmedic:
rm -f /sdcard/fsck*.rec needs to be added to the custom shell commands. I checked and have it in mine and that's from the original build.
[Touch Pro2, Tilt 2 Android Development] highlandsun:
My FRX patches got a *cleaner* shutdown, but if your rootfs is mounted from /sdcard then you can never get a totally clean shutdown. As aaarghhh said, you need to be running completely partitioned for that to be possible. Rootfs has to be mounted from its own partition, otherwise no way, the /sdcard partition will always be unclean and vulnerable to corruption.
[Touch Pro2, Tilt 2 Android Development] nickleby:
I think that's not working with kernel 3.2...I've a lot of .rec files on my SDCard. With the stock kernel (.27) there's no problem but now that I'm using 3.2 those files keep appearing even when that command is on the gingerbread.user.conf file. (Don't know if that is kernel-related, but it started to happen after update to 3.2)
[Touch Pro2, Tilt 2 Android Development] arrrghhh:
IIRC .39+ had issues processing the *.user.conf files.. I never really figured out why, and I don't know if there was any rhyme or reason discovered as to why those newer kernels don't properly process the *.user.conf files, but they do not...
[Touch Pro2, Tilt 2 Android Development] detule:
Case-sensitive -> capitalize.
[Touch Pro2, Tilt 2 Android Development] arrrghhh:
Derp, that was it? Now I feel dumb :o, lol thanks detule.
[Touch Pro2, Tilt 2 Android Development] fishingmedic:
What needs to be capitalized for GB? Or am I missing something?
[Touch Pro2, Tilt 2 Android Development] detule:
rm -f /sdcard/FSCK*.*
[Touch Pro2, Tilt 2 Android Development] krekol:
I can state that this works. The orignal line was rm -f /sdcard /fsck*.rec. I changed it to FSCK*.rec and nothing changed. I tried FSCK*.* and that fixed it. I am enjoying running this version of Android. I am learning as I go. My TP2 is a Sprint running GSM on the AT$T Network. The only real problem I have ran into is sometimes when I get a call or call the dialer closes but the call is still active. To talk or hear the other person the dialer has to be restarted. I can try to get some logs if somebody is interested but remember I am learning so it might take me bit.
[Touch Pro2, Tilt 2 Android Development] detule:
Make sure you have GetLogs installed and know how to use it.

The issue with the outgoing calls on a gsm network seems to be fairly popular. I don't really know what's causing it (someone needs to get boot-up radio logs from froyo vs gbx and smooth-talk hyc into taking a look), but we've been trying a pretty crude patch. The current lib that is in testing can be found here. To install it you need to download the lib to the root of your sdcard, and type something along the following lines inside an adb shell:

mount -o rw,remount /system
cp /system/lib/libhtcgeneric-ril.so /system/lib/libhtcgeneric-ril.so.stock
cp /sdcard/libhtcgeneric-ril.so.4 /system/lib/libhtcgeneric-ril.so

Double check that the correct lib is in place by comparing the md5 hash of the new lib versus the one that is in place in system/lib.

Then reboot.

If/when the issue reappears, post the GetLogs output (pastebin) here.
[Touch Pro2, Tilt 2 Android Development] krekol:
After a crash course in how to install and use abd shell I was able to install the new lib. I checked the md5 hash and it matched the new lib. Getlogs was already installed and I did a test run to see how it worked. I guess my only question over Getlogs is what needed if this happens again? Just the radio logs or everything. Everything makes a huge text file and looks like a pain to go thru.