**** BEGIN LOGGING AT Fri Jan 02 02:59:57 2009 Jan 02 07:17:06 back again Jan 02 11:45:04 hey anyone about? I'm crapping myself here i've bricked my phone :| Jan 02 11:57:43 just for the record he didn't brick his phone Jan 02 12:00:05 yea Jan 02 12:00:16 just crapped myself thinking i did :) Jan 02 14:20:27 re Jan 02 14:35:27 re Jan 02 14:58:55 Hi, I have a class that inherits from MapActivity and now I want to create a new instance of that class when a button is pushed, however, doing this results in errors:: NewMapActivity nta = new NewMapActivity(); Jan 02 15:20:43 where would i find information on setListAdapter? Jan 02 16:27:04 zeroxten, Aside from the reference docs? Jan 02 17:16:22 neat, i just discovered the dump() method of Service Jan 02 17:16:32 it lets you write debug info out to adb shell dumpsys activity.services Jan 02 20:45:29 I'm trying to share a project with a friend, and he is getting this error: An unexpected error has been detected by Java Runtime Environment: Error: ShouldNotReachHere(). Google hasn't turned up anything, has anyone seen this before? Jan 02 20:46:07 he was able to run the project several weeks ago Jan 02 20:51:06 can you be more specific? your friend did what exactly and what gave that error? Jan 02 20:51:31 I sent him the project, he imported it to the eclipse workspace, and tried to run it Jan 02 20:51:49 so Eclipse gave that error? Jan 02 20:51:58 Yes, and it happens with a blank android project as well Jan 02 20:52:07 then tell him to fix eclipse and/or is jre. Jan 02 20:52:09 his* Jan 02 20:52:31 he reinstalled eclipse already, what steps could he take to 'fix' his jre? Jan 02 20:52:37 uninstall/reinstall? Jan 02 20:52:40 marklar, What's around that? Surely that's not all. Jan 02 20:52:59 CardinalFang: not sure what you mean... Jan 02 20:54:20 marklar, JREs are usually a bit better about errors. An exception without any context would be unusual, yes? Jan 02 20:54:24 marklar: i don't think your question is within the scope of this channel, honestly. Jan 02 20:54:45 I didn't think so either, but I doubt I would have gotten a response in #android Jan 02 20:54:50 and it is android development :) Jan 02 20:54:56 it doesn't seem to be related to android at all. Jan 02 20:55:02 from the error, it looks your his JRE is borked somehow. Jan 02 20:55:16 and since its not even your machine you can't give us more information. i don't see how we can help you, sorry. Jan 02 20:55:26 it looks like his*, i meant. Jan 02 20:55:38 yeah, even saying look at the JRE is a help, I'm at a total loss here Jan 02 20:55:39 thanks Jan 02 21:01:42 * jasta looks around for jbq Jan 02 21:01:43 hmm Jan 02 21:06:57 he's probably still on vacation Jan 02 21:07:07 probably Jan 02 21:09:45 <_avatar> woohoo, got my client/server stuff working and authenticating through SSL sockets. :D Jan 02 21:10:01 <_avatar> sorry, i had to comment somewhere, i'm happy it's working. heh Jan 02 21:10:46 romainguy: i'm so confused how the Gtalk service keeps itself alive. Apparently Android is capable of abruptly killing services under normal load. Jan 02 21:11:11 my service just disappears without a call to onDestroy. its like the whole process just crashes. Jan 02 21:11:12 no idea :) Jan 02 21:11:20 <_avatar> there's a special flag, or something, you can set for "long running" services, i think Jan 02 21:11:30 found some other guy complaining about the same thing. jbq confirmed this is androids behaviour... Jan 02 21:11:37 <_avatar> something that hints to the OS not to kill the service unless absolutely necessary Jan 02 21:11:56 _avatar: really? Jan 02 21:12:10 <_avatar> i'd swear i saw it a week or two ago. let me see if i can find it. Jan 02 21:12:11 well i could setForeground, but that doesnt seem right. Jan 02 21:12:18 <_avatar> maybe that's what i'm thinking of. Jan 02 21:12:39 <_avatar> yeah, that's what i saw. "You can set this flag if killing your service would be disruptive to the user: such as if your service is performing background music playback, so the user would notice if their music stopped playing." Jan 02 21:12:58 but that isnt what i want. i dont mind if my service is killed, i'd just like it to do so gracefully and restart it for me. Jan 02 21:13:14 which i had always thought was android's behaviour. i dont quite understand what's going on... Jan 02 21:13:26 :) jasta: http://wiki.linuxquestions.org/wiki/Hack#Robin_Hood_and_Friar_Tuck Jan 02 21:13:41 i wrote some debug code to open a log file during onCreate with a timestamp, and after many days of running my app, several logs are made. Jan 02 21:14:06 during onDestroy, the logs are terminated ("ondestroy called!") and then closed. None of the log files have that line in them though Jan 02 21:14:07 <_avatar> jasta: is onDestroy() when it's killed? Jan 02 21:14:16 <_avatar> oh, hrm Jan 02 21:14:48 all the state is lost. the app is in a very confused position. Jan 02 21:15:02 <_avatar> and you're sure the service isn't crashing? Jan 02 21:15:03 i have a connection thread which when connected opens a notification and sets a keepalive alarm Jan 02 21:15:09 <_avatar> i guess you'd see an exception / stack trace if it was Jan 02 21:15:20 when the connection ends, it unsets those things. but both remain. so my service eventually is restarted by my keepalive alarm. Jan 02 21:15:45 _avatar: no, i can't be sure of that. it takes many hours or days before this condition occurs. Jan 02 21:15:57 so i dont have much logcat backlog to use. Jan 02 21:16:18 oh wait. Jan 02 21:16:38 I/ActivityManager( 57): Process org.devtcg.demo.keepalive (pid 28230) has died. Jan 02 21:16:38 <_avatar> speaking from experience, i've had my service running for days at a time without problems. and onDestroy() is always called as far as i know Jan 02 21:16:40 <_avatar> i'd guess you're crashing Jan 02 21:16:46 but i dont see anything useful about this. Jan 02 21:17:25 I/ActivityManager( 57): Process com.android.email (pid 31045) has died. Jan 02 21:17:25 ? Jan 02 21:17:49 lots of processes died. Jan 02 21:18:25 <_avatar> i wonder what the difference betweeing died and killed is. heh. Jan 02 21:18:41 W/ActivityManager( 57): Scheduling restart of crashed service org.devtcg.demo.keepalive/.KeepAliveService in 5000ms Jan 02 21:18:44 Well, hmm. Jan 02 21:19:10 but lots of apps seem to have crashed... Jan 02 21:19:32 is this really something i'm expected to handle? *sigh* Jan 02 21:21:18 <_avatar> i bet died means a service killed itself, either correctly (stopSelf(), etc), or because it crashed. not because the system had to intervene. Jan 02 21:21:30 <_avatar> so other services died because they finished, you died because you crashed Jan 02 21:21:32 well i dont see why so many apps would die then? Jan 02 21:21:48 mine gets killed in the background all the time... Jan 02 21:21:49 <_avatar> clients disconnect from the service, the service calls stopSelf(), and dies Jan 02 21:21:50 no, i doubt that. i saw like every app on the phone die in the log within a window of an hour Jan 02 21:22:10 including apps i wrote, which i know wouldn't have called stopSelf() then. Jan 02 21:22:20 <_avatar> ah Jan 02 21:22:35 zhobbs: right i had seen this before. i just always thought you got a call to onDestroy? Jan 02 21:23:01 ahhh...I've been assuming that too Jan 02 21:23:17 oh this is interesting. i didn't call through to super.onDestroy()...but i dont see how that could have mattered. Jan 02 21:23:37 <_avatar> what does your onDestroy() do? is it possible that it took too long to complete, the system got impatient, and killed it? Jan 02 21:23:45 that's not the case with an Activity...this is no guarantee that onDestroy() is called... Jan 02 21:24:05 _avatar: that is possible, but unlikely. it does enough work that it could block for a while, but i have not ever seen it do that in practice. Jan 02 21:24:39 _avatar: it halts a blocking thread, then waits for it to die. Jan 02 21:24:40 <_avatar> perhaps put a logcat trace as the first line in your onDestroy(), and on the last line. Jan 02 21:24:44 but it writes the log line before it does anything Jan 02 21:24:48 <_avatar> ah Jan 02 21:24:52 <_avatar> :) Jan 02 21:24:58 and that never shows up in the log so... Jan 02 21:25:05 <_avatar> right Jan 02 21:25:36 i will reposition the code though so that it closes the log before it waits. Jan 02 21:25:42 just to make sure it gets flushed Jan 02 21:31:29 * jasta notices something interesting Jan 02 21:31:39 the gtalk service, which of course must run forever, has this line in dumpsys activity.services: Jan 02 21:31:44 totalRestartCount=17 restartCount=1 restartDelay=5000 restartTime=207955799 nextRestartTime=207955646 Jan 02 21:32:26 perhaps service crashes/restarts are a normal part of the platform? Jan 02 21:32:26 my service has a non-zero restartCount as well. Jan 02 21:33:15 this is so hard to debug with trial and error because it takes hours for the problem to show Jan 02 21:35:13 <_avatar> hmm Jan 02 21:35:16 <_avatar> totalRestartCount=0 restartCount=0 restartDelay=0 restartTime=3772891 nextRestartTime=0 Jan 02 21:35:32 <_avatar> my service that's been running for a long time -- maybe 12+ hours? Jan 02 21:36:08 <_avatar> my background service does very little work 99% of the time though, it basically blocks on a read. maybe it's not a good candidate for the system to kill most of the time Jan 02 21:37:03 mine wouldnt be either. all it does is attempt to hold open a TCP connection forever. Jan 02 21:37:44 <_avatar> same here Jan 02 21:37:46 <_avatar> heh, hmm Jan 02 21:37:47 it has a Notification displayed when connected only. what caused me to notice this behaviour was that the notification would display when no connection was made. Jan 02 21:38:14 the server said nothing was connected, and stopping the service completely didnt have an effect; it definitely was not connected Jan 02 21:38:22 s/service/server/ Jan 02 21:38:49 btw, my code is hosted here if you're curious: Jan 02 21:39:12 http://code.google.com/p/android-random/source/browse/trunk/TestKeepAlive/src/org/devtcg/demo/keepalive/KeepAliveService.java Jan 02 21:40:32 the only thing i can possibly think of is that onDestroy is called but stop() blocks for too long and somehow the log is not being flushed so i _think_ onDestroy wasn't called. Jan 02 21:41:04 _avatar: in practice, i have been running this for days then i just check on it every now and then to find it in a broken/disconnected state. i think it typically takes longer than 24 hours to happen... Jan 02 21:41:26 it deceives me and still shows the notification though, which of course defeats the purpose entirely of what im trying to find out :) Jan 02 21:45:22 <_avatar> so it's join() in ConnectionThread.abort() that could potentially be blocking too long? Jan 02 21:47:11 <_avatar> hmm Jan 02 21:48:37 <_avatar> and the notification is only hidden when the ConnectionThread is finishing. Jan 02 21:49:13 <_avatar> when this happens, can you plug your device into ADB and see if that thread is still running for some reason? Jan 02 21:49:48 <_avatar> er, DDMS rather Jan 02 21:52:09 is there a reason why today, 20:00 is represented by 1230922800000 ? Jan 02 21:52:21 this isn't unixtime? Jan 02 21:56:20 _avatar: i have looked at it extensively with ddms, but only well after the problem has happened. ic ant be monitoring it all day long :) Jan 02 21:57:06 _avatar: logically, yes, wait is the only way it can block. but i doubt very much that it is. i can prove it easily by rearranging the log code so that it closes the log before it calls stop() Jan 02 21:57:26 this way, if the log line is not in the log files, then we know that the log was closed abruptly, and not terminated and closed. Jan 02 21:57:39 but actually, i just think android is plain killing the process and restarting it Jan 02 21:58:02 and actually it seems to only call onCreate, not onStart when it remakes it Jan 02 21:59:07 _avatar: shutting down the socket as i die prior to the join causes the blocking read to abort immediately, and then the thread finishes of course. Jan 02 21:59:21 but that code certainly isnt happening because the notification remains and so does the keep alive alarm Jan 02 22:00:05 i wish i could just leave my phone plugged into adb all day so i could capture an entire days worth of logcat output to analyze Jan 02 22:00:10 but i tend to like...leave the house :) Jan 02 22:03:15 <_avatar> are you sure shutting down the input stream causes the blocking read to abort? i see you're shutting down the input stream, but swallowing any exception that's being thrown. Jan 02 22:03:24 yes, i'm sure. Jan 02 22:03:43 _avatar: that's because an I/O exception is irrelevant. if the socket can't be shutdown, it already broke out of a blocking read too. Jan 02 22:04:02 <_avatar> i actually had a similar problem, but damned if i can remember the details, where my socket read() wasn't finishing when it should. Jan 02 22:04:09 this is actually documented behaviour. it's how HttpClient implements HttpMethod#abort, for instance. Jan 02 22:04:35 and it is also possible to prove this particular code works. there is an activity associated with the service which starts it with ACTION_STOP Jan 02 22:04:46 as you see in onStart(), that causes stop() and then stopSelf(), which complete immediately. Jan 02 22:05:07 <_avatar> yeah, i follow the program logic, and it seems to check out Jan 02 22:05:49 one possibility is that there's just some dumb runtime exception being thrown here and i just dont have long enough logcat output to see what it was? Jan 02 22:06:06 but if that were the case, the phone would throw up an application crashed dialog i'd think. that's what it does in all other circumstances Jan 02 22:06:32 so i really don't know. i feel like jbq should be able to give some useful insight into this. Jan 02 22:12:17 jasta: so have you used your mediaplayer layer to play shoutcast streams? Jan 02 22:13:38 no, havent pointed it at anything but my own streams Jan 02 22:13:48 is shoutcast special somehow? Jan 02 22:14:17 nah, just sends some meta-data ever X bytes if you specify in the HTTP header Jan 02 22:14:22 every* Jan 02 22:15:23 aww im sure that would work just fine with my layer Jan 02 22:15:28 maybe youd need some minor tweaking Jan 02 22:16:19 hehe, unless the license is tweaked I'll be reinventing the wheel :) Jan 02 22:16:26 it won't be :) Jan 02 22:16:54 i'd love to help you out, but i'm just too stubborn to leave the GPL hehe Jan 02 22:17:03 nah, I understand Jan 02 22:22:03 wonder if the MediaPlayer has trouble with remote http dataSources not on port 80 Jan 02 22:22:38 for some reason it won't play a simple mp3 stream: http://cast.voxcdn.net:8000/2917-MP3-RadioIO-Eclectic-128 Jan 02 22:23:40 but if I save some of it and then stick on SD card it plays fine... Jan 02 22:31:02 nm, works fine streaming stuff not on port 80... Jan 02 22:31:35 <_avatar> jasta: if the remote host terminates the socket connection, calling inputStream().close on the client end doesn't call the read() to abort. Jan 02 22:31:44 <_avatar> er, doesn't CAUSE the read() to abort Jan 02 22:31:58 <_avatar> hence your thread run() may never exit, and your notification would never be hidden. Jan 02 22:33:31 <_avatar> jasta: http://files.clangen.org/SocketTest.java ... just a very quick test, but try line 58 commented in and out. Jan 02 22:34:04 <_avatar> heh, obviously not production code Jan 02 22:39:03 <_avatar> i ran into this exact same problem when working on my service Jan 02 22:45:13 _avatar: if the remote host closes the connetion, read will return 0. Jan 02 22:45:44 err, -1 i meant. that's my C background talking :) Jan 02 22:46:44 however, your code has a bug in it. you must instantiate Socket in the constructor, and not in run(). Jan 02 22:46:56 else requestCancel may be called when socket is an inconsistent state :) Jan 02 22:47:09 <_avatar> right, thats why i said its not production code Jan 02 22:47:29 but your code isnt expected to abort the read. Jan 02 22:47:29 <_avatar> regardless, try it. you'll find it doesn't return -1 when the serversocket closes the connection Jan 02 22:47:31 you must shutdown input. Jan 02 22:48:00 some platforms will respond to close(), otherwise will respond to shutdown. both are necessary to portably break a blocking read. Jan 02 22:48:05 others* Jan 02 22:48:21 <_avatar> didn't know that, let me see... Jan 02 22:49:11 you also won't get an exception necessarily. Jan 02 22:49:15 <_avatar> oh, nice. you're right :) Jan 02 22:49:18 the read may return -1 on shutdownInput() Jan 02 22:49:24 <_avatar> yeah, i get it Jan 02 22:49:33 and exit gracefully. this is why you must use a flag variable to know whether you aborted or not Jan 02 22:50:59 <_avatar> btw, did you notice your code never closes the input stream on the socket? it only calls shutdownInput()? Jan 02 22:51:16 <_avatar> i did what you said, called socket.getInputStream().close(), and socket.shutdownInputSteam(), works as expected Jan 02 22:51:22 <_avatar> but if i don't close the input socket it still hangs, the read never returns Jan 02 22:51:41 you shouldn't be closing the input stream. you should close the socket itself. Jan 02 22:52:05 the InputStream and OutputStreams of the socket are merely abstractions that are not understood by any layer beneath the Java one. Jan 02 22:52:15 OutputStream* Jan 02 22:52:22 <_avatar> yeesh, that's what i get for trying to hack an example together really quick Jan 02 22:52:30 <_avatar> yeah, i understand that Jan 02 22:52:32 so closing them doesn't really translate to a syscall that is sufficient to break a blocking I/O operation Jan 02 22:52:45 shutdownInput and sokcet closure, however, do. Jan 02 22:52:58 <_avatar> but, you close the socket in your finally block Jan 02 22:53:12 <_avatar> oh, and in abort() Jan 02 22:53:22 only in the event that mAbort == false, otehrwise abort() closes it. Jan 02 22:53:41 its important to use an abort flag so that you can actually get a sense for what has already happened to the socket. Jan 02 22:53:42 <_avatar> i'm trying to exhaust all possibilties here, this problem you're having concerns me Jan 02 22:53:50 <_avatar> yeah, i understand Jan 02 22:53:58 me too :) Jan 02 22:54:03 bbl, work is harrassing me :) Jan 02 23:01:19 <_avatar> on the plus side, talking through this helped me fix a minor bug in my disconnect code -- I was only calling socket.close() without the shutdownInputStream() and shutdownOutputStream(). every once in a while my read() wouldn't finish, i think this will fix it. :) Jan 02 23:01:50 <_avatar> i'm a complete newbie to socket programming, if that wasn't completely obvious Jan 02 23:02:11 <_avatar> i've always worked at a slightly higher level with networking stuff Jan 02 23:14:33 hehe Jan 02 23:15:24 i wrote Gnapster, and then went on to build my own peer-to-peer network. i have a fair bit of network programming experience ;) Jan 02 23:15:39 <_avatar> ah, cool, i remember gnapster :) Jan 02 23:16:04 it is sometimes a challenge to translate the high-level Java APIs to what the POSIX/BSD layer is doing, but with Apache Harmony source code it has been possible :) Jan 02 23:16:10 <_avatar> i understand the concepts of socket programming fairly well, i think. it's the little implementation details i'm not familiar with (e.g. shutting down an input stream AND calling close, etc) Jan 02 23:18:21 i'm still baffled how my service is getting destroyed though Jan 02 23:18:43 <_avatar> yeah, everything seems to check out Jan 02 23:18:46 im going to move log closure to happen before abort() just to test if there's a bug in there somewhere Jan 02 23:19:07 but the whole point of the join() loop is just to make sure i havent introduced a bug that would cause the socket abort to fail Jan 02 23:35:42 alright, heading home. i am determined to figure out what's going on here :) Jan 02 23:35:54 i restarted the service a few hours ago and of course its been working fine since :) Jan 02 23:35:54 <_avatar> let me know what you find... Jan 02 23:36:01 <_avatar> like i said, this has me slightly concerned as well Jan 03 01:17:20 Hi. I am really new to Java (since getting my phone ... started 2 days ago ;) ), and having trouble getting my head around the paradigm of event programming (rather than perl, python etc). In short, I now have three classes: Jan 03 01:17:42 first: (main) - enable wifi, setup broadcast receiver intent to watch for scanner complete, and start wifi scanning Jan 03 01:17:50 second: the broadcast receiver itself Jan 03 01:18:03 third: a listActivity class, where I want to display all the SSIDs. Jan 03 01:18:28 I want to call from , but I don't know how -- startActivity is unavailable from a BroadcastReceiver. Jan 03 01:18:32 Any ideas ? Jan 03 01:19:27 Is it as simple as publishing an intent? I tried calling a method from within class to display the list, and my program crashes (I suspect because it transitions to ListActivity from Activity ?) Jan 03 01:20:23 and if I do setup an intent - how do I transfer to it without startActivity ? Jan 03 02:30:42 Hi all. I want to query some provider, but I only see a way to do it from a android.app.Activity. Can't I do it from a android.app.Service? Jan 03 02:31:57 Activity has managedQuery() . I don't need the management, though. android.content.ContentResolver has query(), but that's abstract, I guess. Jan 03 02:32:02 "android.content.ContentResolver is abstract; cannot be instantiated" Jan 03 02:32:51 (Which is strange, given that constructor. But, I don't know a lot about Java and I've had some wine.) Jan 03 02:33:39 * CardinalFang stops babbling and waits for response. Jan 03 02:34:02 all you need is a Context Jan 03 02:34:12 Context.getContentResolver().query(...) Jan 03 02:34:18 er Jan 03 02:34:19 sorry Jan 03 02:34:44 ah actually that's right :) Jan 03 02:35:05 Ah, it looks like I can use ContentResolver.query() statically. Jan 03 02:35:22 ...maybe. Jan 03 02:35:28 hmm no Jan 03 02:35:41 just get the content resolver from a Context Jan 03 02:36:26 Perfect. Thanks, romainguy. **** ENDING LOGGING AT Sat Jan 03 02:59:57 2009