On Thu, Feb 23, 2023 at 04:18:28PM -0800, Andrii Nakryiko wrote: > On Tue, Feb 21, 2023 at 1:37 PM Daniel Müller <deso@xxxxxxxxxx> wrote: > > > > On Fri, Feb 17, 2023 at 04:32:05PM -0800, Andrii Nakryiko wrote: > > > On Fri, Feb 17, 2023 at 11:19 AM Daniel Müller <deso@xxxxxxxxxx> wrote: > > > > > > > > This change adds support for attaching uprobes to shared objects located > > > > in APKs, which is relevant for Android systems where various libraries > > > > > > Is there a good link with description of APK that we can record > > > somewhere in the comments for future us? > > > > Perhaps > > https://en.wikipedia.org/w/index.php?title=Apk_(file_format)&oldid=1139099120#Package_contents. > > > > Will add it. > > > > > Also, does .apk contains only shared libraries, or it could be also > > > just a binary? > > > > It probably could also be for a binary, judging from applications being > > available for download in the form of APKs. > > > > > > may reside in APKs. To make that happen, we extend the syntax for the > > > > "binary path" argument to attach to with that supported by various > > > > Android tools: > > > > <archive>!/<binary-in-archive> > > > > > > > > For example: > > > > /system/app/test-app/test-app.apk!/lib/arm64-v8a/libc++_shared.so > > > > > > > > APKs need to be specified via full path, i.e., we do not attempt to > > > > resolve mere file names by searching system directories. > > > > > > mere? > > > > Yes? > > I'm just confused what "resolve mere file names" means in this > context. Like, which file names are not "mere"? It's meant to convey the fact that a "mere file name" is not everything we could be dealing with. It could also be a full path. [...] Thanks, Daniel
