Hi, I got it!
It is because that ActivityThread.bindApplication() and
ActivityThread.scheduleReceiver
are IBinder.FLAG_ONEWAY，so you know things are* asynchronously*。
On Sunday, July 13, 2014 11:29:09 AM UTC+8, shiqun.shi wrote:
Hello,
In my app, we have a receiver, which listens action
I notice this two methods, handleReceiver() and makeApplication()。
In which case，packageInfo.makeApplication(false, mInstrumentation); was
called and mApplication == null? Which will make a receiver be
instantiated（by cl.loadClass(component).newInstance()）before
As this receiver was loaded and instantiated by the default
PathClassLoader. While in application.onCreate（）,we change the default
PathClassLoader’s parent classloader to another one(a custom
HostClassLoader)。Both PathClassLoader and HostClassLoader are refer to
the same apk file。So，when
On Dalvik you'll get that error if you use a custom ClassLoader that
loads classes from other ClassLoader(s) (eg. the API of a plugin).
If you're using this, you have two options: either dont export the
symbols or remove them at runtime[1] (you'll need to move the class
definitions and zero out
I wondered that why a receiver can be instantiated（by
cl.loadClass(component).newInstance()）before
*packageInfo.makeApplication(false,
mInstrumentation);* and *instrumentation.callApplicationOnCreate(app);*.
Everything works well if *handleBindApplication()* is first called，which
will
I wondered that why a receiver can be instantiated（by
cl.loadClass(component).newInstance()）before
*packageInfo.makeApplication(false,
mInstrumentation);* and *instrumentation.callApplicationOnCreate(app);*.
Everything works well if *handleBindApplication()* is first called，which
will
6 matches
Mail list logo
