Hi, I am totally new to android. Is there a tool which enables to check if a dex file is compatible ...

# android

[robstoll]

Hi, I am totally new to android. Is there a tool which enables to check if a dex file is compatible with a certain API level?

[Casey Brooks]

I’m not sure if this is helpful, but the APK includes an AndroidManifest.xml file which includes the compile and target SDK versions under <uses-sdk ...>. If you can get the .dex, I’d assume you also have access to the entire APK, too

[robstoll]

I actually have *.class files. I figured if I can convert them with d8 to dex then they should be usable for an android developer but as far as I understand now, the resulting dex file might not be usable for certain SDK API levels

[evant]

that'll depend on what minSdkVersion you set when you convert them

[robstoll]

I haven't set it, so it should be 1

[evant]

we normally consume libs with class files directly instead of dex artifacts though

[robstoll]

I would also be happy if I can run a check on class files

[evant]

If you are building an aar, lint will do that for you. Otherwise, you can look into animal sniffer

[robstoll]

my problem is that android supports some jdk8 features but not all. E.g. LocalDateTime was only introduce in API level 26

[robstoll]

or does it support all by now? that would make it easy 🙂

[Casey Brooks]

I’m curious what you’re needing to do this for? There might be a better way to resolve the problem, or it might even be something you shouldn’t need to worry about as the library developer. It’s pretty normal to do runtime SDK-level checks in Android

[Casey Brooks]

Most devs are using a backport library for java.time APIs https://github.com/JakeWharton/ThreeTenABP.

[robstoll]

I see 🤔 that's probably also the reason why dex compiles everything.

[evant]

there's a new fancy feature to backport some of the java api's, but it's not in stable yet https://developer.android.com/studio/preview/features#j8-desugar

[Casey Brooks]

@evant I was just wondering about that. I knew they were doing something for that, but I wasn’t sure if it was ready for use just yet

[robstoll]

There was once an issue reported for atrium, an assertion library I am the author of.
https://github.com/robstoll/atrium/issues/52
The problem was the module-info.class I included in the jar file caused problems during dexing.
That's some time ago and I wanted to check if I can safely ship jdk features > jdk7 in the android jar I am producing.

[robstoll]

so I wanted to have kind of a check to be sure I am not breaking things for android devs

[evant]

I believe the module-info.java bug has been fixed, don't quote me on that though

[robstoll]

another question in this direction. Is there a command line tool to compile *.java files setting the targetSdkVersion as you would do in a android studio project?

[evant]

okhttp uses animal sniffer to do those checks https://github.com/square/okhttp/blob/68241851c197a67cdcdd0e150e239f55d1e556f4/build.gradle#L144 though it seems like it's in maintenance mode so that may be iffy? https://github.com/square/okhttp/issues/5529 You could write some unit tests to run on android, not sure if you want to go down that route?

[robstoll]

If necessary I probably will; I hoped there is a simpler solution

[evant]

you can run d8 directly to compile class files into dex, yes.

[robstoll]

that's what I did

[robstoll]

but it never errors

[robstoll]

which is suspicious

[evant]

yeah I don't think it checks for api usage

[robstoll]

and the dex file has version 35

[robstoll]

hm... that cannot be; I must mistaken on this one

[evant]

one idea is you could try compiling your source code with -Xbootclasspath android.jar , I think that would fail if you include any api's that aren't on that api level.

[robstoll]

good idea

[robstoll]

I'll try that one

[robstoll]

thanks for your time 👍

[robstoll]

@evant the idea of -Xbootclasspath will not work I guess as it only modifies runtime but not compiling

[robstoll]

yet, I can use your idea nonetheless I think. I'll use the android.jar instead of the jdk during dexing. This way I should get at least a warning if a type is missing 🙂