Skip to content

Restructure handling of classes and methods in mapper/cache #54

@loewenheim

Description

@loewenheim

Currently, when parsing proguard mapping files, we don't "abstract" classes and methods; we simply take lines of the proguard file as they come. This has some negative consequences. Consider this mapping example:

some.package.Class -> foo.a:
# {"id":"sourceFile", "fileName":"Foobar.kt"}
    4:4:void example.Foo.lambda$main$0():225 -> a
    4:4:void some.package.OtherClass.run(example.Foo):2 -> a
    4:4:void run():3 -> a
    5:5:void run():4 -> a
    # {"id":"com.android.tools.r8.synthesized"}

some.package.OtherClass -> foo.b:
# {"id":"sourceFile", "fileName":"Other.kt"}
    1:10:void run(example.Foo):1:10 -> a
  1. The file name for OtherClass should be Other.kt. When remapping a stack frame for e.g. foo.a.a:4, we just take the file name of the class the method is called in (Foobar.kt), which is incorrect.
  2. With respect to Support synthesized class annotations #48: The 5:5 mapping of Class.run is marked as synthesized. This should affect all mappings for the method, but it currently doesn't because we don't keep track of methods.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions