How to launch installed application via command line with 'dalvikvm' verbose classloading, etc.

[AKispert]

Hi,

I have searched both on the web and within this and the Android
Developers group and am unable to find an answer. So, any help on
this list would be greatly appreciated.

I have an Android application that is already installed on the
emulator. What I would like to do is to manually launch the
application from within an adb shell on the emulator and specify that
the instance of the dalvikvm running the application should report
classloading being performed by the vm. What I have gleaned from
posts and from running 'dalvikvm -help' on the emulator shell is that
I can specify the '-verbose:class' argument on the command line (like
Java desktop VM's) and specify the '-cp <path to installed apk
file>'. When I do this, the dalvikvm states that I need to specify a
class that contains a 'main' method. I'm fine with this and
understand that it is looking for an entry point with which to run an
application. What I don't understand is what class, or perhaps is
there a different command alltogether, should I be using to achieve
the above?

In summary, I would like to be able to do something like 'dalvikvm -cp
<path to apk file> <class with main>' and have my application (really
a service) launched on the emulator with classloading information
being output to a log, etc.

Thanks in advance.

Andy Kispert

[Dianne Hackborn]

I don't think you can really do this -- you'd need to set this flag for zygote (and thus all java processes), since all app processes are forked from that already running process.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support.  All such questions should be posted on public forums, where I and others can see and answer them.

[AKispert]

Hi Dianne,

Thanks for your response. One thing I tried to do was to use the 'adb
shell setprop dalvik.vm.<reasonable guess for verbose property> class'
followed by an 'adb shell stop; adb shell start' to cause the property
to be picked up by new running applications (via the Zygote process
forking as you mentioned below) but it apparently has no effect.

Would you happen to know whether there is a property (settable by the
'setprop' command) that can permit me to enable verbose classloading
information?

Thanks in advance.

> hack...@android.com

[fadden]

On Mar 27, 1:07 pm, AKispert <AKisp...@gmail.com> wrote:
> Would you happen to know whether there is a property (settable by the
> 'setprop' command) that can permit me to enable verbose classloading
> information?

There is not.

What are you hoping to learn?

[AKispert]

I wanted to confirm how a reference (as a data member of a class) to
another class impacts the loading of the referenced class by the VM.

For example, if I have a service that supports N different calling
API's (each bindable via a different action), then as a part of
starting up my service
I may want to defer the VM's loading of the implementation of the
various API's supported by the service until "bind time". If I refer
to each handler within my service
class via a Java interface rather than as a class extending the aidl
generated 'Stub' class for each API, then when my service class starts
up I shouldn't have the overhead
of loading all the classes implementing the supported API's.

I wanted to confirm when various classes within my service were being
loaded by the VM via the '-verbose:class' option to the VM. The only
two options I saw for doing this would be to either manually start the
application in an adb shell via the 'dalvikvm' command directly, or
set this property via the 'setprop' command and perform a 'stop ;
start' within the shell.

In the meantime, what I have done is defined a boot time intent
receiver that will manually start my service up, but not bind to it.
In my services 'onCreate', I'm listing all the loaded classes via the
'Debug.printLoadedClasses' API call. I was able to learn what I
needed to in this fashion...

[AKispert]

Hi,

Actually, I'm going to recant the above statement regarding utilizing
a Java interface type versus a class implementation type to refer to a
service handler implementation.
The 'onCreate' method in my service was directly instantiating one of
my API classes that extend the AIDL generated stub class. I confirmed
for my own information that I can still directly reference my class
implementation as a data member within my service class, I just need
to ensure that at "bind time" I instantiate my instance of the class
(an IBinder instance) in order to defer loading supporting classes.

So, I was able to determine that I can lazily load supporting classes
to handle various API calls if I instantiate them at "bind time".

[fadden]

You could also set it by attaching a native debugger and setting
gDvm.verboseClass = 1. If you're not set up for native debugging this
might be more trouble than it's worth.

You can get almost what you want by adding a static initializer to
your classes that prints a message to the log file. This will tell
you about class initialization rather than class loading, so it's not
quite right.