I'm writing a simple app to enable adb over ethernet on startup of the android, with a cancel button to prevent the enabling of the of the adb on the network. When the pop-up for superuser appears, if clicked immediately everything is fine, but if I wait a few seconds and click ok, the display fails to update.
The onCreate uses a mHandler to start a runnable, which is used for the countdown timer. When I used a mHandler.postDelayed to try to delay past the startup process, the display is never updated. When I use mHandler.postAtFrontOfQueue the countdown display functions properly, but following the superuser dialog the screen fails to update.
The countdown timer uses mHandler.postAtTime to repeatedly call the runnable. I'm thinking I need to put something at the start of the runnable to reset the focus, but am still new to the android and not having any luck figuring out what would make it happy.
When the application is run manually, everything is correct. On a second android, everything is correct.
I've found a workaround to the problem by changing from using "android.intent.action.boot_completed" to using "android.intent.action.MEDIA_MOUNTED".
What I observed was that the boot_completed happened before the full boot was complete. Something, not sure exactly what, stepped all over everything. When I tried to sleep or launch the runnable with a timer, if the sleep or timer crossed over the time things went wrong, the sleep and timer would never return, without ever getting into the runnable. By switching to the media_mounted, whatever was stepping on things had already passed.
I had been thinking of using the startup app to execute an init.rc file from the SD, so trigging off the media mount makes sense for that need.
Related
I am writing a simple program in Java, and sometimes it randomly freezes and does not respond. when I try to end it with Ctrl-C instead of quitting, the program springs back to life and starts working fine again. I am not posting my code because I have noticed this behavior with other command line programs on Windows, so it does not appear to be anything specific to my code. The program will eventually be running 24/7 on a headless server, so you can see why it would be a serious issue if it just stopped working every now and then. Thanks in advance. Any help is appreciated.
This sounds a bit like perhaps a selection issue: If you make a selection in the console window, it freezes console output. The next time an application attempts to flush to the console it will stall until the selection is cleared. Pressing ctrl-c will copy the selection and clear it, allowing the flush to complete and the application to continue to run. Any keypress in the console window should clear the selection though, and it sounds like only ctrl-c is working for you.
If that's not what the issue is, your next best bet the next time you see this would be to open up a native debugger (e.g. Windbg) or a java debugger and attach to the process you're running in the console process to see what is doing the waiting. It's likely that something you're calling is triggering a spurious getch / readline / etc. A debugger should make the source of the stall obvious. If you need help deciphering the stack once you have one, I might be able to help. Just paste it into this thread.
Ben
This is my first question in this amazing service.
So this is what i want to do:
I want to start Android Emulator, perform few actions with UI (fill login/password form and click Login button) and then leave it running.
I wrote some automatic tests with Robotium framework before and know how to make a TEST that running an asserting something. The problem is that test will terminate soon or later. But i need to log in through UI and leave emulator running like some kind of homemade system service.
What would you suggest to solve this problem?
Thanks.
I made a java application that saves data to a .data file. I have a Window Listener that listens for the application to close in order to fire the code to save the data to the file. When pressing the dedicated quit button I have, or pressing the red "X" on the window, everything is fine. However, when the user opts for the command + q route things go sour. The application is quit, but the data is not saved. How do I correctly implement apple's handleQuit(Application Event e) method to fix this?
What you want in that case is a shutdown hook. A shutdown hook listens for the OS signal to close the app and is triggered when this signal is sent. A shutdown hook can run pretty much any code.
You can wire your built-in red "X" button to close the app (instead of saving the file), and the shutdown hook will catch the request and take care of saving the file.
The only caveat is that shutdown hooks are supposed to be made up of code that doesn't take very long to execute. So, the save of your file shouldn't take more than a second or two, and you shouldn't use confirmation dialog boxes that the user must acknowledge in a shutdown hook, because it can take an indefinite amount of time before the user recognizes the dialog.
The reason why shutdown hooks should be short lived is that when an application is requested to shutdown, the OS generally expects it to shutdown in a reasonable amount of time. If it doesn't, for example in Windows, the OS might display one of those, "Application isn't responding..." messages.
Finally, and you might run into this question later, you might wonder how to catch a "Force Quit" request from the Task Manager (or "Force Quit Applications" dialog on OS X). Well, you can't catch those, and you shouldn't try! While it is possible to disable things like listing your app in the Force Quit menu, this is a complete hack and should be avoided at all costs. If you're designing your app in a way that tries to circumvent options that should always be available to users and admins then that's a strong indication that your app is poorly designed, and/or a bad actor. Imagine if you installed an app that behaved in this way - wouldn't you think the programmer was being lazy or possibly malicious in trying to give their app un-killable qualities?
Also, force quitting is a forcible (ungraceful) shutdown that should only be used on applications when they are hung and won't quit normally. OSs need to have a force quit kind of option so that a user or admin has a way to kill a runaway or unresponsive app. If your users are force quitting your app they either misunderstand that force quitting isn't desirable, or there's something about the design of your app that makes force quitting more favorable than quitting your app normally. If this is the case (e.g. you hear from users that they force quit for one reason or another), it's usually an indication that portion of your app is poorly designed to match user's expectations.
Apple JVM on various OS X version have apparently been broken in that they do not generate the WindowClosing event when they should (for example if you close an app's main JFrame using by clicking on the close button).
(in the most recent Apple Java updates you can set a property forcing the event to be generated but this is not what I'm looking for)
My problem is simple: I'd like to display a "tip" when the user closes the app. However I cannot (due to the fact that no event is generated) detected that the user closed the window.
So I thought I could use a shutdown hook:
Runtime.getRuntime().addShutdownHook(...)
However apparently creating a JFrame from a shutdown hook seems problematic: it's like if the EDT was already gone once the shutdown hook is called.
I tried several things and nothing really seems to makes sense: like my "Tip" JFrame staying all gray (despite it working fine when called from anywhere but the shutdown hook) or the program exiting immediately. I tried using a latch and waiting on the latch from the shutdown hook but it's as if the EDT wasn't there anymore.
I'm currently seriously considering spawning a second Java app just to display the tooltip as a workaround but I think it's a bit overkill (but at least it would work).
Did anyone ever try to create a window from a shutdown hook and invoke things on the EDT and are there any gotchas to be aware of? (remember that I cannot reliably catch the window closing events on OS X due to known very-longstanding Apple VM bugs).
If the window is actually closing and the application is stopping then something is calling the JFrame.dispose() method. overwrite this, and add your code there.
otherwise you can add a daemon thread that listens to the closed method on the window listener, the daemon can add the tooltip and then dispose of the window. you can delay the dispose until the tooltip is done.
I've never heard of this bug, but things can only get better now that apple isnt releasing its own jdk's.
I have a question about the Android virtual device(avd)... as what you already know, that you can test your android application through avd in eclipse, and i'm getting a boring repeted thing with that.
each time I want to test my application and when I make a small change to my application, I have to run the avd again and wait for a long time till the application run(switch the device on and wait for the system to boot and then wait for the application to start,this takes approx. 15 sec)... as I said, each time I make whatever change to the program I have to go through these boaring time consuming loop :( ...
So, is there is a way to avoid these issue, and makes the avd run only for the first time and any changes can take effect quickly and only needed to restart the application without needed to stop and run the project again ??
I hope there is a way for that.
When you're done with a debug cycle, do you close the AVD? If you keep the AVD running, it should do exactly what you're describing.
If that doesn't work for you, a look at your application manifest may be needed.
Simply don't quit the emulator. Leave it running, hit Run (or Debug) in Eclipse, and if anything changed, the program will be uploaded to the emulator again.
Don't close the emulator. Keep it running and click debug again, it will run fast since it won't reboot. (The emulator will just re-install the app instead).