Thank You!

[REAndroid]

Just discovered this gem repo today, you have done an amazing work, even google is struggling to achieve this on R8. I tested in couple of apks and works like a magic.
Unfortunately the original repo looks like abandoned or maybe the owner don't have a time to follow up, I think it's good idea to move it to new repo instead of fork for multiple reasons:

• Peoples was frustrated with past issues and might take it as same thing with minor cosmetics.
• Easier for others to contribute.
• Freedom to make any changes without worrying about merge conflicts.

Question:
How can I change the output of class file version ? I tested with DEX 35, 36, 37 and all producing 50 (6.0). I wanted to make it 52 but I don't have knowledge on java class file structure, will it have side effects ?

[ThexXTURBOXx]

Hello, thank you very much :)
However, most credit goes to pxb1988, still! I have only fixed issues and improved stability overall...

Personally, I am very hesitant to "detach" this repo from the original one by removing the fork-status.
I like everyone to see at first glance that this repo is indeed a fork and not just a new project.
Also, by removing the fork status, my PR over at the original repo (pxb1988#486) would be closed and cannot be reopened again (because this requires my repo to be a fork).
Since most people find my repo through this PR, it is not optional, but rather mandatory for me to do it this way.
I understand your second point, though. Indeed, when creating a PR against my repo, GitHub currently aims at the upstream repo instead for some reason.
But the other two arguments I do not fully comply with:

• If people were frustrated with past issues, they will have found my PR (which is linked in many upstream issues) and hence also this repository. So, it is pretty clear from the get-go that my repo does more than just cosmetic changes
• Merge conflicts are not really a bad thing in this case. In fact, I like the possibility of having a good overview of the upstream changes in order to be always up to date

Now regarding your question: There will probably not be any side effects since the class version is backward-compatible.
However, dex2jar offers the two scripts d2j-class-version-switch.bat and d2j-class-version-switch.sh (which correspond to this Java class), which allow you to change the class version, if needed.
However, please be aware that you could also easily break any Java class file with this approach. Some additional (manual) changes might be needed afterwards!

[REAndroid]

Thank you for your answer,
d2j-class-version-switch is a separate process it will be very convenient if there is some means to write at one pass.

My other thought is on dex2jar what about converting constant integer resource ids to field invoke ? for example:
const v0, 0x7f020001
to
sget v0, Lcom/pkg/R$string;->app_name:I

This helps to produce aar library then aapt can regenerate resource ids. You don't have to expand scope to process resources, the user will pass integer-fieldName map in R.txt or any format convenient for you to parse.

I attempted to do this on DEX side but my challenge was converting array data and switch values which requires adding extra tmp registers (not easy when total registers are > 16).

[ThexXTURBOXx]

d2j-class-version-switch is a separate process it will be very convenient if there is some means to write at one pass.

You are correct. However, this is the only way to accomplish this yet.
Also, reading through your first post again, it is quite odd that DEX version 037 does not give you a major version of 52, because it should. Are you sure that your DEX file is indeed version 037?
Otherwise, there might be a bug hidden in dex2jar somewhere...

My other thought is on dex2jar what about converting constant integer resource ids to field invoke

Would be nice, but infeasible, sadly. There is just no reliable way to determine whether your example instruction const v0, 0x7f020001 wants 0x7f020001 to be a normal integer (it could very well be that some calculation needs exactly this constant) or whether it should be the app_name.
Also, the current structure of dex2jar makes it quite difficult (if not impossible) to access the necessary information for such a conversion.
Your R.txt approach might very well be possible, but still: I would rather not include this directly into dex2jar, but leave this for the user to do so.
There are already many configuration possibilities and various constructors for different configurations. I don't want to make the codebase even more messy

[REAndroid]

Are you sure that your DEX file is indeed version 037?

I did silly mistake (testing same file), I checked again now:

• DEX-35 -> JAVA 50
• DEX-36,37,38,39 -> JAVA 52
• DEX-40 saying Unknown DEX version. Trying anyway... but works fine with JAVA 52

So making DEX != 35 generates JAVA 52, this satisfy my personal needs

it could very well be that some calculation needs exactly this constant

Yes it could be, but almost it never happen in real world. Having this feature worth way much than facing this errors.

I don't want to make the codebase even more messy

Ok lets enjoy the current features for a while, I may come again with more convincing ideas

Another best thing I noticed is: you are handling register value types very well, I was struggling to correct R8 problems for past 3months

.method public static a()Ljava/lang/String;
    .locals 1
    const/4 v0, 0x0

    sput v0, Lcom/Test1;->b:I

    return-object v0   
.end method

Here R8 is fails Unable to constrain primitive type INT by OBJECT, but dex2jar compiles correctly

[ThexXTURBOXx]

DEX-40 saying Unknown DEX version. Trying anyway... but works fine with JAVA 52

Upstream dex2jar will fail with DEX version 040 - I have patched out the exception and just print out a warning instead.
There are still some opcodes in DEX 040, which are not yet supported.

So making DEX != 35 generates JAVA 52, this satisfy my personal needs

Perfect, glad to hear that :)

Yes it could be, but almost it never happen in real world. Having this feature worth way much than facing this errors.

Correct and understandable, but as already said, the current structure of dex2jar sadly makes it very hard - if not impossible - to implement.
JADX has a similar feature, though, IIRC (however JADX is fundamentally different to dex2jar as it does a full decompilation, not a conversion).

Ok lets enjoy the current features for a while, I may come again with more convincing ideas

Of course :)
You might be better off suggesting features in the issues section, though!

Another best thing I noticed is: you are handling register value types very well

Indeed, dex2jar contains a few optimizers for special cases like this!