3

I am injecting some classes to services.jar in /system/framework. Unfortunately I have always to reboot the device to see the modifications on services.jar in my application. Is there a way to force dalvikvm to reload all framework jars?

joe-jeff
  • 324
  • 1
  • 9
  • 27

2 Answers2

6

Do

adb root
adb shell stop
adb push services.jar system/framework/
adb shell start

Adb stop will stop the system and adb start will force it to restart the dalvik part of it. Doing this is marginally faster than adb reboot it's not possible to force it to reload just services.jar

More info on adb shell stop/start: What does 'adb shell start/stop' do?

Personally I prefer just doing adb reboot.

Community
  • 1
  • 1
JohanShogun
  • 2,956
  • 21
  • 30
  • I think my adb version does not have "stop", running version 1.0.31. What worked for me was a: adb shell pkill zygote, but it is very slow. – joe-jeff Sep 04 '15 at 19:45
  • Sorry should be shell start / stop. I'm not a fan of killing zygote, it runs into problems sometimes when it loads stuff unless you do stop/start. My experience is that reboot is the most reliable. – JohanShogun Sep 04 '15 at 19:47
  • Hm unfortunatelly this does not work, if I start my apk after adb shell start/stop, it still accesses the old services.jar – joe-jeff Sep 04 '15 at 19:53
  • Hmm, make sure you do shell start as well, more info about what the commands do:http://stackoverflow.com/questions/13225817/android-adb-shell-start-stop – JohanShogun Sep 04 '15 at 19:56
  • I do adb shell stop; adb push services.jar system/framework; adb shell start; adb shell am start -n com.example.ex/com.example.ex.MainActivity, then the example crashes since it uses a class in the modified services.jar. – joe-jeff Sep 04 '15 at 19:58
  • you should get the android logo etc when you do shell start? Did you do adb root? – JohanShogun Sep 04 '15 at 20:00
  • 1
    Btw I had also t delete services.odex, then at adb shell start it builded all odex which take some time, any ideas how to prevent? – joe-jeff Sep 04 '15 at 20:04
  • You can try disabling odex stripping, either when you build your apk or when you build your system. But it will still extract the odex file from the apk. – JohanShogun Sep 04 '15 at 20:05
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/88839/discussion-between-joe-jeff-and-johanshogun). – joe-jeff Sep 04 '15 at 20:06
  • @joe-jeff, JohanShogun, did you arrive at a recipe that works? – Don Hatch Jan 05 '18 at 09:31
-1

You can't.

You can't do that without any kind of reboot, because Android keeps running with the .jar files that were there at boot, those are kept in memory (RAM).

Max
  • 348
  • 2
  • 13
  • "Reboot" and "restart" are different things -- the former means the hardware was reset and the Linux kernel was reloaded, the latter means most of the user-space processes were shut down and restarted. You can either reboot or restart after a change to the jar files. – fadden Sep 06 '15 at 04:36
  • @fadden Witg "any kind of reboot" I also meant restarting, because the framework is never released from memory. Only if you do a real reboot. – Max Sep 06 '15 at 04:59
  • I'm not sure why you believe that the jar files are permanently resident. They are not. Portions may live in the file cache, but that doesn't affect the execution of the framework. – fadden Sep 06 '15 at 16:13
  • @fadden Try to replace the services.jar with a different one with a file manager (while having a rooted Android, and a file manager capable of using root access). Replace the services.jar, and see: Nothing happens. Now, if the .jar file would not be kept in RAM there would be some problems. I'm now gonna take a "core.jar" patch as example. If you would patch the core.jar via "Lucky Patcher", it just replaces it. But in order to get things done, it will automatically reboot, or there will nothing being happening. Try it out yourself. – Max Sep 06 '15 at 18:50
  • 1
    I spent several years working on Android. I had a shell alias for `adb shell stop; adb sync; adb shell start`, as did everyone else who worked on the system software. Worked fine. Replacing a jar file without *restarting* has no effect, because the file descriptor for the old file is still open, and the running processes continue to use the old version. Going further and *rebooting* doesn't accomplish anything. In no event are jar files held entirely in RAM -- they're memory-mapped shared read-only, and when the processes die there's nothing left referencing the pages. – fadden Sep 06 '15 at 19:56