Lines Matching full:code
28 All of the debugger support in the VM lives in the <code>dalvik/vm/jdwp</code>
30 <code>dalvik/vm/Debugger.c</code> bridges the gap. The goal in doing so
31 was to make it easier to re-use the JDWP code in other projects.
45 for all applications when the system property <code>ro.debuggable</code>
46 is set to </code>1</code> (use <code>adb shell getprop ro.debuggable</code>
48 manifest, which must include <code>android:debuggable="true"</code> in the
49 <code><application></code> element.
62 to execute code more quickly, and does away with the hardcoded limit
72 <p> Source code debug data, which includes mappings of source code to
75 When <code>dx</code> converts Java bytecode to Dalvik bytecode, it must
78 <code>dx</code> must also ensure that it doesn't perform operations
80 method arguments and the "<code>this</code>" pointer is allowed in
84 this reason, <code>dx</code> generates sub-optimal code in some situations
89 stack traces. This data can be omitted by <code>dx</code> to make the DEX
112 TCP/IP sockets (<code>dt_socket</code>) and connection over USB
113 through ADB (<code>dt_android_adb</code>).
125 before executing application code. When the debugger connects (or
132 <dd>This must be <code>hostname:port</code> when <code>server=n</code>,
133 but can be just <code>port</code> when <code>server=y</code>. This
139 <br>This option has no meaning for <code>transport=dt_android_adb</code>.
161 <code>jdb -attach localhost:8700</code> after selecting it in the app list).
168 and then <code>jdb -attach localhost:8000</code>.
171 type <code>cont</code> to continue.)
173 The DDMS integration makes the <code>dt_android_adb</code> transport much
207 look like the wrong bit of code is being executed. For example:
214 The Dalvik bytecode uses a common <code>return</code> instruction for both
215 <code>return</code> statements, so when <code>i</code> is 1 the debugger
216 will single-step through <code>return 0</code> and then <code>return 1</code>.
221 Instead of marking a method as <code>synchronized</code> and expecting
222 the VM to handle the locks, <code>dx</code> inserts a "lock"
224 synthetic <code>finally</code> block. As a result, when single-stepping
225 a <code>return</code> statement, the "current line" cursor may jump to
231 be considered uncaught, there must be no matching <code>catch</code> block
232 or <code>finally</code> clause between the current point of execution and
235 until the exception is re-thrown from the synthetic <code>finally</code> block.
