Hi everyone, a brief update on what we are currently working on:
First, we started working on improving modules (Project-ARTist/meta#3 ). We believe this is a very important feature and also a blocker for many, since developing modules requires to sync and build the full AOSP code first. On the longer term, we envision module packages (module code, codelib, assets, manifest, ...) that can be shared online and easily loaded through, e.g., ArtistGui.
Second, first tests show that ARTist is not only capable of recompiling the Android system server (at first boot), it is stable enough to instrument each(!) single of its methods. In my experiment, I injected a method call to a log function into each single CFG basic block of each method under
com.android.server.*, that is over 23k methods. While, obviously, the system is slow as hell b/c the injected calls write to logcat, the system still runs. Tests were conducted in the x86 emulator btw.
If you are interested in either, drop me a message.
We have more exciting ideas in the pipeline, so stay tuned ;-)
Alright, time for another update. Quite a lot has happened in the past week(s) since we are in the process of upstreaming a lot of improvements we have been working on in different projects.
First, we now officially support systemserver recompilation (cf. Project-ARTist/meta#2). What does that mean? Beside the deployment path of shipping a custom version of dex2oat/ARTist as an asset of the ArtistGui app, you can now include our versions of art/artist in a custom AOSP build and create a ROM where ARTist replaces the system compiler. This means that ARTist compiles (1) the original boot.oat/art files that supersede the Zygote preloaded classes at AOSP build tme(cf. Project-ARTist/meta#2), (2) the systemserver during first boot of you custom ROM, (3) all other java system components/apps that are initialized during first boot and (4) all newly installed regular apps. Is order to achieve that, a few changes had to be landed on the main branches: Our filesystem support is disabled for the compilation as a system compiler because of the strict SELinux policy for dex2oat, we skip modules if their CodeLib was not merged with the target before, we (try to) distinguish between the 4 cases mentioned above, and more. As indicated, you need to take care yourself to merge your CodeLib into your targets before (!) they are compiled. If you, e.g., want to recompile the systemserver, you would need to check out dexterous, build an executable jar and use it to merge your CodeLib into $AOSPOUT/target/product/generic$ARCH/system/framework/services.jar . This will be described in more detail in the new documentation scheduled for the beta launch.
Second, a long awaited feature was recently merged into the projects CodeLib, dexterous and ArtistGui: Selective CodeLib merging. The fact that all methods, type IDs, etc from the CodeLib were merged into target apps prevented us from injecting larger CodeLibs or libraries into target apps that came near the 64k id limit. While those apps were out of reach before, we now have a nice solution for this: In your CodeLib, use the defined annotation to mark methods as an injection target and dexterous will only make those available in the target's dex files. The result is that the app compatibility improved a lot and we can now also instrument larger apps like Twitter, Google Play Store, Reddit, etc.
If you run into problems or have any other questions regarding the new features and changes, do not hesitate to write them to the NeedHelp channel, we are happy to help.
Hope you like the new features =)
(Currently, all above mentioned changes are available for nougat and nougat 7.1. Oreo and marshmallow will hopefully follow soon.)