Bug 6482 - Deploy to device can get frozen when trying to detect packages.
Summary: Deploy to device can get frozen when trying to detect packages.
Status: RESOLVED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 4.2.x
Hardware: PC Mac OS
: --- critical
Target Milestone: ---
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2012-08-08 18:16 UTC by PJ
Modified: 2012-08-31 16:36 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description PJ 2012-08-08 18:16:18 UTC
I can successfully deploy to device a couple of times in a row, but then it gets stuck waiting for the app to die. It doesn't die and it doesn't give any indication on the device that it wants to die. 

http://screencast.com/t/LwdAFa7DaU

Discussion:

[jonp] mhutch: how do we know what it's waiting for?
[mhutch] jonp: it's waiting for the app "Deployer.Deployer" to finish
[mhutch] exit
[jonp] but i don't see a kill message
[jonp] wait, i do
[jonp] so why isn't it dying? :-/
[mhutch] dunno
[jonp] pjbeaman: is there a dialog on your target device asking if you want to kill the process?
[pjbeaman] nope
[mhutch] jonp: SEPPUKU didn't seem entirely reliable in my experience either
[jonp] interesting. :-/


AndroidTools log:
https://gist.github.com/41f2bd908ea535fc1d44
another for fun:
https://gist.github.com/42d988c52b49dab61dbb


Environment:
Mountain Lion
MD 3.0.4.3 a4a635018f425d71a253d39114d945c4d6f7cbdb-dirty
MFA 4.2.5 4.2.5.219693106
Mono 2.10.9_!1

Samsung Galaxy Tab 2 10.1 (4.0.3)
Nexus 7 (4.1)


I was unable to reproduce this issue on:
HTC Flyer (both honeycomb and gingerbread models)
Comment 1 Peter Collins 2012-08-08 18:45:09 UTC
Reproduced this issue on Samsung Galaxy Tab 2 gt p5113 running Android 4.0.3. I deployed the GLCube sample 3 times while it was already running and eventually froze while attempting to detect installed packages.

Environment Details:
OSX Lion 10.7.4
MD 3.0.4.3 a4a635018f425d71a253d39114d945c4d6f7cbdb-dirty
MFA 4.2.5

Samsung Galaxy Tab2 10.1 android version 4.0.3

Unable to reproduce using the Galaxy Tab 7.0 (GT-P6210) android version 3.2
Unable to reproduce using the Acer IconiaTab android version 4.0.3
Comment 2 Mikayla Hutchinson [MSFT] 2012-08-17 11:28:01 UTC
MonoDevelop now reports that it's waiting for the app to terminate, so the user should be able to figure out how to workaround this by manually killing the app when this happens.

I don't know why SUPPUKU only sometimes works. jonp, any ideas?
Comment 3 Jonathan Pryor 2012-08-17 11:42:31 UTC
> I don't know why SUPPUKU only sometimes works. jonp, any ideas?

Uh, Android?

I have no idea why it would only sometimes work; best I can think of is that Android (1) isn't sending the broadcast, or (2) isn't invoking the Seppuku BroadcastReceiver.

The next time you see this, do the following:

1. Open $(ProjectDir)\obj\Debug\android\AndroidManifest.xml and look for:

    <receiver android:name="mono.android.Seppuku">

For example:

    <receiver android:name="mono.android.Seppuku">
      <intent-filter>
        <action android:name="mono.android.intent.action.SEPPUKU" />
        <category android:name="mono.android.intent.category.SEPPUKU.Mono.Samples.HelloTests" />
      </intent-filter>
    </receiver>

2. Run `adb shell am broadcast -a ACTION -c CATEGORY`

ACTION is the //receiver[@android:name='mono.android.Seppuku']/intent-filter/action/@android:name attribute value, and CATEGORY is the //receiver[@android:name='mono.android.Seppuku']/intent-filter/category/@android:name value:

> adb shell am broadcast -a mono.android.intent.action.SEPPUKU -c mono.android.intent.category.SEPPUKU.Mono.Samples.HelloTests

Does the process exit? If it does, curse; this is exactly what MonoDevelop/androidtools is doing now.

3. If (2) doesn't cause the process to exit, append a "component-name" of PACKAGE_NAME/mono.android.Seppuku. PACKAGE_NAME is the AndroidManifest.xml /manifest/@package attribute value:

> adb shell am broadcast -a mono.android.intent.action.SEPPUKU -c mono.android.intent.category.SEPPUKU.Mono.Samples.HelloTests Mono.Samples.HelloTests/mono.android.Seppuku

Does this cause the process to exit?

Note: (3) is only valid on Honeycomb+ targets.

If (3) works, then we'll likely need to update androidtools to use the component-name on Honeycomb+ devices. If (3) still doesn't work, I suggest lots of cursing^Hdrinking^Hfleeing from the vicinity.
Comment 4 Mikayla Hutchinson [MSFT] 2012-08-17 12:05:44 UTC
From what I've seen:

a) MD's broadcast sometimes kills the app, sometimes it doesn't
b) running the exact same broadcast command on the terminal sometimes works, sometimes doesn't
c) using the component makes no difference

Can you repro any of this?

- Michael
Comment 5 Jonathan Pryor 2012-08-17 15:26:00 UTC
Stunning discovery by mhutch: it hangs reliably if the target's screen is locked/off. If it's on, it works.

Workaround: unlock your device.
Comment 6 Jonathan Pryor 2012-08-31 16:36:20 UTC
Background: What the Seppuku BroadcastReceiver does is:

    java.lang.Runtime.getRuntime ().exit (-1);

The intent is to exit the process so that the underlying ("fast deployment") assemblies can be updated so that the correct version will be used.

The problem is that when the screen is locked, the process isn't killed.

Which is a lie; the process IS killed, it's just that Android immediately restarts it:

> I/AndroidRuntime(25947): VM exiting with result code -1, cleanup skipped.
> I/ActivityManager(  306): Process SampleTabs.SampleTabs (pid 25947) has died.
> I/WindowState(  306): WIN DEATH: Window{41d243c8 SampleTabs.SampleTabs/sampletabs.Activity1 paused=false}
> D/dalvikvm(25996): Late-enabling CheckJNI
> I/ActivityManager(  306): Start proc SampleTabs.SampleTabs for activity SampleTabs.SampleTabs/sampletabs.Activity1: pid=25996 uid=10108 gids={3003, 1028}
> D/Zygote  (  124): Process 25947 exited cleanly (255)
> I/ActivityThread(25996): Pub SampleTabs.SampleTabs.mono.MonoRuntimeProvider.__mono_init__: mono.MonoRuntimeProvider
> D/dalvikvm(25996): Trying to load lib /data/data/SampleTabs.SampleTabs/lib/libmonodroid.so 0x417e4f98
> ...

The deployment process, meanwhile, isn't waiting for the process-id to exit, but for the process name to exit. Since Android restarted the process, it never exits, hence the hang.

Furthermore, Android is actually behaving...sanely. http://stackoverflow.com/a/2632649/83444

    System.exit() does not kill your app if you have more than
    one activity on the stack. What actually happens is that
    the process is killed and immediately restarted with one
    fewer activity on the stack.

This apparently isn't entirely true, at least on tested machines, as if your app is unlocked it can exit itself without problem. It's when the screen is locked and the app attempts to exit itself that Android restarts the app...

The solution? Ensure that the app is NOT the topmost activity by launching a new activity: the Home screen.

Fixed in master/94ef061a and monodroid-4.2.5-branch/fbf243f0.