I have coded a BroadcastReceiver to enable the resetting of an alarm if a user has to reboot hid device. Is there any way to test this in the emulator, in other words what sequence of events are required to cause the emulator to kick off the BroadcastReceiver .
Ron
I have not tried it yet, but Dianne Hackborn wrote the following yesterday:
You can also use "adb shell am" to
send a BOOT_COMPLETED broadcast to
your app for quick testing. I can't
remember the exact syntax, but "am
help" will tell you. Be sure to
specific your explicit component name
when doing this, or you will cause all
installed apps to re-run their boot
completed receivers, which may not be
fun. :)
I believe that the only way to do it will be to close the emulation window and start it again. If you are running Eclipse, simply close the emulator and then run/debug your project to start it again.
Related
I have searched this over the web, without an answer. Basically while testing a device, I observe that the display screen fires ON much earlier, while in the logcat the print
Consoleui:bootComplete follows after ~ 8 sec.
Now Device screen is displayed as part of starting Launcher application, so in the natural sequence of events, the system server will ask activitymanager to start launcher in a seperate thread and go on doing more work.
Thus it is only natural that display will come up, but still there might remain some services to be started by activitymanager/systemserver before a BOOT_COMPLETED broadcast can be made.
I have to prove this. In order to do so, I need to know which process tells the activitymanager that now it can broadcast the boot_complete message, if its the system server, please tell me the part of code where it does so. Thanks.
The activity manager service sends the boot complete intent on line 6320 of ActivityManagerService.java.
The activity manager service also starts the launcher using an intent with CATEGORY_HOME on line 3305 of ActivityManagerService.java.
It appears that your original question contains 2 sub-questions:
Q1. Where exactly in the AOSP code is system broadcast Intent BOOT_COMPLETED fired?
Q2. What are all the necessary conditions to trigger the firing of BOOT_COMPLETED?
For Q1, a broad location is in the Activity Manager. In this sense, #Alex Lockwood’s answer is correct. However, I have noticed that the exact location and the way this Intent is fired may change between Android versions. A source code search should be able to lead to the answer. Take AOSP branch “android-8.1.0_r32” as an example. First, find out where file “ActivityManagerService.java” is located using the following shell commands:
$ cd [your AOSP branch’s root directory]
$ find . -name ActivityManagerService.java
Once the file is found, go to its parent directory. For example, in our current case:
$ cd frameworks/base/services/core/java/com/android/server/am
Now perform the following search:
$ grep -rIn ACTION_BOOT_COMPLETED .
The output reveals that the exact location is not in file “ActivityManagerService.java”, but in file “UserController.java”. More exactly, it is in method “UserController.finishUserUnlockedCompleted()”.
For Q2, we can search backwards from the above method. Eventually we may reach method “ActivityManagerService.finishBooting()” where we can see that Boolean “mBootAnimationComplete” must be true. This implies that the boot animation process must be completed in order for BOOT_COMPLETED to be fired, and further implies that while the boot animation process is going on, a lot of system services are being started. For further details, you may refer to some dedicated books that explain which system services must be ready in order for the boot animation process to end.
Since the phone restarts and thus gets disconnected from the Eclipse debugger/LogCat while it's booting up, how do I see where my boot complete broadcast receiver is crashing?
I am performing some actions in the onReceive() of my
public class BootCompleteReceiver extends BroadcastReceiver {
...
}
This is crashing and popping up a force close dialog when the phone boots. How do I debug this and see where the problem is?
The question holds true for debugging any BOOT_COMPLETE broadcast receivers.
Thanks!
EDIT
Yes, we can see the system logs in LogCat as the phone is booting up but my app Log.d(TAG,"Boot completed") has to wait till it (onReceive) gets triggered but by that time the app crashes because the problem is somewhere in the receiver itself. The app crashes before I can log anything. Also, I cannot use "Run in Debug mode" for a phone that's restarting...
As i wrote on another thread:
You can emulate all broadcast actions by connecting via adb to the device and open a device shell.
Here we go:
open console/terminal and navigating to /platform-tools
type "adb shell" or on linux/mac "./adb shell"
in the shell type "am broadcast -a android.intent.action.BOOT_COMPLETED" or whatever action you want to fire.
In this way you should be able to debug.
There are a bunch of nice commands coming with adb or the adb shell. Just try it
Regards Flo
EDIT:
Using the above method will also reboot the device. To prevent the device from rebooting use am broadcast -a android.intent.action.BOOT_COMPLETED com.example.app. Note the suffix with the application package name to which the broadcast goes. This enables you to send the BOOT_COMPLETED intent to ONLY YOUR app for debugging purposes. – Roel van Uden
The receiver is only controlling when your code runs (i.e when the phone starts). Whilst debugging, run the code manually. You can resolve 99% of your issues this way and the remaining ones (if any) you can resolve by writing to LogCat so see what your code is doing.
check your Intent's actions and bundles you are recieving ,they may null and can be a null pointer exception.
Just put to your terminal in Android Studio
adb shell am broadcast -a android.intent.action.BOOT_COMPLETE
is there a simple way to stop a running application using ADB.
Szenario:
Working on App
Have a script which uploads, installs and starts App on change
Problem:
Currently running version gets killed (not shutdown), which make testing cleanup very hard. Option would be to "do cleanup in between", like after a certain time, but I would prefer to do it in the correct location (so like with the OS, as long as the App is still running, so need to save value, as soon as the OS tells me e.g. memory low or calls onDestroy, I want to save stuff)
Chris
I'm not aware of a way to do this. I was hoping there might be a way to send an intent to tell the app to exit using adb shell e.g.
adb shell am start -a [intent] -n [class]
However, I found that somebody asked this question on a Google forum but they haven't got an answer:
http://groups.google.com/group/android-platform/browse_thread/thread/3fd02d01c6c3b41a/56814e518503efd6
Sometimes I see my app in DDMS restart.As I see it's process id changed.(I'm not sure that,because I don't write log for application oncreate.)
That behaviour ofen happened when I mount SDCard to share USB mode.I'd like to see what happend after mount in my application.So I debug my App,but unfortunately.When mount to share USB mode,application's process id changed and debug been auto stopped.
Why?What happened?What's the strategy for android handle application restart?
And there is another question.Why does sometimes an activity occur an error,thrown an exception dialog,and restart it.Sometimes the android platform just kill the activity and exit.
Maybe it's not a very useful question for develop.But I'm really missing,I want to know the answer.Please help me,friends.Thank you very much.
I used to get into similar cases like yours, what I did to handle and detect is like:
1. Check Device: sometimes devices mal-functioning really cause problems, a bad USB cable will really do restart Android/application.
2. Collect Log: after application restarts, just collect the log from system/event/radio/dumpstate... remember the time when app started to restart then check in log files to look for the causes.
Well, that's my experiences and it works, not in all situations but most of the time.
I'm trying to get my Android tests running on headless emulator for future use on CI servers.
But non of the TouchUtils methods, like "clickView()" etc.. seem work this way.
I'm always getting SecurityException:
"Injecting to another application requires INJECT_EVENTS permission".
Looks like it doesn't click the right objects in the first place. In normal GUI mode everything works fine.
Is there any way around this?
If no, which setup would you recommend to run all the tests on remote machines?
Thank you!
The device is probably showing the lock screen. Check it with the hierarchyviewer or screenshot2.
You can unlock the screen by sending a menu button, for instance by using adb:
adb shell input keyevent 82
(The keyevent code can be found in android.view.KeyEvent.)