Hi, I am totally new to android. Is there a tool w...
# android
r
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?
c
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
r
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
e
that'll depend on what minSdkVersion you set when you convert them
r
I haven't set it, so it should be 1
e
we normally consume libs with class files directly instead of dex artifacts though
r
I would also be happy if I can run a check on class files
e
If you are building an aar, lint will do that for you. Otherwise, you can look into animal sniffer
r
my problem is that android supports some jdk8 features but not all. E.g. LocalDateTime was only introduce in API level 26
or does it support all by now? that would make it easy 🙂
c
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
☝️ 1
Most devs are using a backport library for java.time APIs https://github.com/JakeWharton/ThreeTenABP.
r
I see 🤔 that's probably also the reason why dex compiles everything.
e
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
c
@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
r
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.
so I wanted to have kind of a check to be sure I am not breaking things for android devs
e
I believe the module-info.java bug has been fixed, don't quote me on that though
r
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?
e
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?
r
If necessary I probably will; I hoped there is a simpler solution
e
you can run d8 directly to compile class files into dex, yes.
r
that's what I did
but it never errors
which is suspicious
e
yeah I don't think it checks for api usage
r
and the dex file has version 35
hm... that cannot be; I must mistaken on this one
e
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.
r
good idea
I'll try that one
thanks for your time 👍
@evant the idea of -Xbootclasspath will not work I guess as it only modifies runtime but not compiling
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 🙂