Detecting that android has booted up over adb - android

I'm trying to detect the successful bootup of an emulated android OS (Google's Android Emulator, sys version 12.0, running on Linux inside Docker) over adb in order to install an app right after boot. I tried the methods mentioned in this thread, but none of them seem to work.
I tried checking for all these props in a loop:
sys.boot_completed
dev.bootcomplete
init.svc.bootanim
service.bootanim.exit
They continue returning 0 even after the device is fully booted up and never return 1.
I also tried adb wait-for-device, but that finished immediately, even though I'm using the "-delay-adb" flag on my emulator (and if I don't use it, the behavior is still the same).
Attempting to install the APK before the boot is finished (right after wait-for-device exits) results in an installation error:
adb: failed to install app.apk: Exception occurred while executing 'install': java.lang.NullPointerException: Attempt to invoke virtual method 'void android.content.pm.PackageManagerInternal.freeStorage(..) on a null object reference'
It I wait for the device to boot and then manually trigger the installation, or if I add a long enough wait time before the installation is attempted, it works without any problems. But I don't want to add an arbitrarily long sleep because this may run on different devices which take different amounts of time to boot up.
Did anybody encounter this behavior?
Do you have any suggestions on how to detect bootup without having to write my own app with a BOOT_COMPLETE listener?
More abstractly, does anybody have a different suggestion on how to install an app in the Android emulator right after boot?

It's a quite an ugly solution, but you could always just attempt to install the application in a loop with some small delay and wait until it succeeds. It's not pretty, but should do the job.
You said that you receive a specific exception when you attempt to install an app during booting. Assuming the same exception is unlikely to happen after booting the phone for some unrelated reason, it should be mostly safe approach to use.
Another thing that comes up to my mind is looking at network traffic, I'd expect android to call home right after booting the system, but that seems much more complicated, and maybe even less reliable, than the "install in a loop" idea.

Related

is it possible to stop the cts and save the current logs

I am running android-cts . The commands I run are mentioned below,
cts-tf
run-cts --plan --cts-camera
It is being running for two days . How do I stop the current task and save the existing logs .
Also it is mentioned in documentation ,that the cts logs will be stored in
CTS_ROOT/android-cts/results/start_time.zip
But I dont see a start_time.zip in the location specified .
There are few ways by which you can stop the CTS invocation and result will be generated of your runs,
Unplug the USB Cables from the devices, this will make tradefed to not detect any device and once timeout occurs, it will generate result on testcases and modules it ran.
Kill command, just write the kill in the tradefed, and it will kill and stop the invocation threads for the runs. once that is done, it will generate the result but make sure not to give kill command more than 1 or else it will exit from tradefed without generating the result.

Remotely debug system framework

I would like to debug a system framework running on an Android device.
In particular, GpsLocationProvider sometimes stops for a while, and I would like to know what it is doing. I found the class contains a android.os.Handler that gets messages posted to it, to communicate between threads. Sometimes it takes minutes between a message is sent, and Handler.handleMessage is called. I interpret that the thread belonging to the Handler's Looper is busy.
I would like to attach a debugger, pause that thread, and see what's currently executing. Alternatively, somehow get a traceback of that thread. Is there any way to do that?
I tried creating an Android Studio project from the source tree with development/tools/idegen/idegen.sh, but I'm not sure how to proceed from there. In case it matters, the (legacy) device is running Android 6.
I've also just discovered debuggerd. I call logcat -s GpsLocationProvider to find the corresponding PID, and feed it to debuggerd, both with and without -b argument. However, this only gives be a backtrace into native code. I don't see any java code there.
If I'm not mistaken, if you have the respective Android API version in your AndroidStudio (installed through SDK Manager), you can install debug variant of your app on the device and then put breakpoints inside Android's code.
This way you can pause the execution of the component's code and see what it's doing.

Running a script as a service from init.rc on Android at boot

In order to execute a script on Android (Samsung Note 10.1 (N8010), 4.4.2) at boot I added the following to the end of the init.rc (unpacking/repacking the boot.img) to have it run as a service:
service test /system/bin/test_script.sh
class main
oneshot
The script looks like this:
#!/system/bin/sh
mkdir /sdcard/test_directory
It is eventually supposed to do something else, but for testing I kept it simple. Permissions are 0755.
The problem though is that the directory /sdcard/test_directory is not being created, which leads me to believe that the service is never being started, i.e, the script is never being executed.
I've already tried numerous things mentioned in other threads.
E.g., adding the line user root to the service, rebooting multiple times (since apparently a service is not being started after booting the device right after flashing the boot.img) or putting the script in different folders like /system/etc/ or /data/local/tmp.
Any idea what could be the problem?
Is it possible to somehow monitor whether the service is actually being started (maybe it is, but the problem lies within the script)?
Is there maybe even a better way to executing a script at boot (device does not have init.d support and I don't want to use an app like Unversal Init.d)?
EDIT:
Don't know why, but it works now.
Moved the script around multiple times, ended up putting it under /data and removing the file extension. Also added some more lines to the script like mkdir /data/local/tmp/test_directory. The directory under /sdcard is not being created though (maybe a permission problem?). Probably the reason, why I thought the script had not been executed, if it has been before.
Question remaining: is there a way to monitor whether a service is actually being started?

Explain behavior of Unix sleep() function executed on Android

I am currently compiling and executing some C++ code on a rooted Android device. I use adb (adb shell). To compile my code, I don't use the NDK, but I cross-compile with CMake
I'm using the function sleep(seconds) of unistd.h.
I've experienced some curious behaviors with that function on Android: Basically, I have a for loop in which I std::cout something and then call sleep(x).
If I call sleep(1), the behavior is the one expected: The program waits 1 second, and then executes the next instructions.
If I call sleep(2), the behavior isn't the one expected. The program gets stuck on that instruction for ever.... until I hit a key on my PC keyboard (not the device's one), and then it gets stuck on the next sleep(2)... until I hit a key, etc...
This behavior happens only when the device screen is off. As soon as I click on the power button to turn the screen on, the program resumes and has the expected behavior.
N.B: The behavior is the same with usleep(useconds)
I have tried to see where the limit is between 1 and 2 seconds:
1.5s, 1.25s, 1.125s -> always stay blocked | 1.0625s -> ~50% chance of staying blocked.
Obviously, there is something that prevents a thread to wake up if it sleeps more than 1 seconds (at least 2).
So my question would be, does anyone have any idea of why this is happening, and has a detailed explanation of the process ?
Thank you !
Android puts applications in the background when they aren't doing any user interaction - unix sleep and java timers etc. won't wake them up. You have to use an android alarm or runnable postDelayed handler.

Trigger io barcode scan doesn't work when it is invoked for the first time

On Android 2.3.1, when you use the trigger.io code below, the trigger framework doesn't scan the bar-code the first time when it is invoked. Actually the camera opens and the bar-code is scanned, however, after the scanning is complete you see the trigger splash page and the success function doesn't get invoked. It starts working like it should when the scan function is called from the second time on-wards.
forge.barcode.scan(function (value) {
alert("You scanned: "+value);
});
This sounds like the app is being forcefully closed when the camera is started, due to device resource constraints.
If you look at the output of "adb logcat" in a terminal, you'll probably see a message about an unhandled intent.
In this case, there's not too much we can do - the Android OS has started killing processes to free up memory. We always keep our wrapper as lightweight as possible, and will continue to look for areas to increase efficiency.
We have only seen this problem occur with any regularity on low-spec devices running later versions of Android. If it's happening a lot for you, check your app's not leaking memory - again, the output of "adb logcat" can show GC activity.

Categories

Resources