commit e7307fa35c0c0a69928b545f6af89447714180ee
author Andy McFadden <fadden@android.com> Mon Jul 06 13:56:24 2009 -0700
committer Andy McFadden <fadden@android.com> Mon Jul 06 13:56:24 2009 -0700
tree f27c0b30410b7a38c5f20f1d66a87431f8e8a386
parent ae6aa7198074f6c2c56119da77e31f8b9777709e

Update notes on JDWP debugger support.

In particular:

 - The app framework uses ro.debuggable, not ro.secure, to decide
   whether or not debuggers are globally allowed.
 - If you have a debugger attached, Thread objects may not be collected.

docs/debugger.html

diff --git a/docs/debugger.html b/docs/debugger.html
index 7d93caf..523c712 100644
--- a/docs/debugger.html
+++ b/docs/debugger.html
@@ -41,11 +41,11 @@
 communication, such as notifying the debugger when the VM has stopped at
 a breakpoint, are sent from the affected thread.
 </p><p>
-When the VM is embedded in the Android framework,
-debugging is enabled in the VM unless the system property
-<code>ro.secure</code> is set to </code>1</code>.  On these
-"secure" devices, debugging is only enabled in app processes whose
-manifest contains <code>android:debuggable="true"</code> in the
+When the VM is started from the Android app framework, debugging is enabled
+for all applications when the system property <code>ro.debuggable</code>
+is set to </code>1</code> (use <code>adb shell getprop ro.debuggable</code>
+to check it).  If it's zero, debugging can be enabled via the application's
+manifest, which must include <code>android:debuggable="true"</code> in the
 <code>&lt;application&gt;</code> element.
 
 </p><p>
@@ -194,7 +194,9 @@
 integrated at present.  The VM currently guarantees that any object the
 debugger is aware of will not be garbage collected until after the
 debugger disconnects.  This can result in a build-up over time while the
-debugger is connected.
+debugger is connected.  For example, if the debugger sees a running
+thread, the associated Thread object will not be collected, even after
+the thread terminates.
 </p><p>
 The situation is exacerbated by a flaw in the exception processing code,
 which results in nearly all exceptions being added to the "do not discard"
@@ -202,6 +204,9 @@
 to a program that throws lots of exceptions can result in out-of-memory
 errors.  This will be fixed in a future release.
 </p><p>
+The only way to "unlock" the references is to detach and reattach the
+debugger.
+</p><p>
 &nbsp;
 </p><p>
 The translation from Java bytecode to Dalvik bytecode may result in