Open fvrmatteo opened 8 months ago
+1 on this issue. I have a device with Android 13 and com.android.art version 341311100. This means that the code of instrumentArtMethodInvocationFromInterpreter
goes to the second branch (because the API level is 33), but the correct symbol cannot be found, because the signature of DoCall
for art version 34nnnnnnn is:
template<bool is_range>
bool DoCall(ArtMethod* called_method,
Thread* self,
ShadowFrame& shadow_frame,
const Instruction* inst,
uint16_t inst_data,
bool string_init,
JValue* result);
which corresponds to the mangled name _ZN3art11interpreter6DoCallILb[0-1]EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtbPNS_6JValueE
.
If there's no easier way of finding the version of art (one could, for example, process the first bytes of the protobuf-encoded file apex_manifest.pb
but I'm not sure if this is an interesting approach), maybe the solution is to test all the regexes as mentioned previously. In any case, the current code assumes that the version of art is the same as the API level of Android, which isn't always the case.
On my Pixel 5a the version in /apex/com.android.art/apex_manifest.pb
is 350820460, while the Android version is 13 (TQ3A.230805.001). Unfortunately there are no symbols at all anymore, so the DoCall
method cannot be found.
/apex/com.android.art
folder: com.android.art.tar.gz
/data/apex/active/com.android.art@350820460.apex
: com.android.art@350820460.apex.zip
It's unclear whether the symbols are now permanently removed, or only in the APEX OTA updates to reduce bloat.
When running Android 13 (API 33), the instrumentArtMethodInvocationFromInterpreter function sets the
artInterpreterDoCallExportRegex
variable to the second regex (/^_ZN3art11interpreter6DoCallILb[0-1]ELb[0-1]EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE$/
), although on my Pixel 6 running Android 13 I can see that theDoCall
symbols present onlibart.so
would actually match the third regex (/^_ZN3art11interpreter6DoCallILb[0-1]EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtbPNS_6JValueE$/
).It might be that originally the
apiLevel <= 33
condition wasn't a bug, but sincelibart.so
gets updated via APEX, the symbols might have changed in the meantime, making the condition invalid.If the bug is confirmed, an idea could be to match against all the regexes and keep only the discovered symbols, but I cannot comment on the performance impact.