Tell me, why that if I unzip mylib.aar, the class format of Smeagol.class is of that of Java 8 format. But, if I include this mylib.aar into a freshly created empty activity Android project (latest android studio bumblebee), in build.gradle by implementation ('libs/mylib.aar') , such that I build a signed-released myapp.apk. Then, if I unzip this myapp.apk, the class format of Smeagol.class is now of a Java 6.0. In the fresh generated empty activity in Android studio, it has compilerOptions both in source and target set to VERSION_1_8.
So the bytecode class format, is not fixed in the aar?
PS: I used the opensource tool d2j-dex2jar.sh to convert myapp.apk to myapp.jar and then I unzip myapp.jar, thereby. Is this affecting it?
update: I also notice the presence of Smeagol$$ExternalSyntheticLambda69.class having bytecode format of a Java 6.0. So it seems, the IDE is doing its best to re-encode the lambda portions into Java 6.0 equivalent machine code. I get the point now that aar class bytecode format is not final, and still yet subject for re-encoding by the one who will generate the apk. Can somebody please led me to an explanation of these mysteries. Thanks.
Related
I am attempting to debug my Android app. When the debugger gets to the View.java file, I receive the message, "Source code does not match the bytecode". I can see that the debugger is in the wrong part of the file. Does anyone know how to fix this?
I am debugging on an Android 10 (API 29) device. In the Android Studio Preferences -> Appearance & Behavior -> System Settings -> Android SDK, I've made sure everything is up to date. I've also cleaned and rebuilt multiple times, removed caches, restarted Android Studio and the device, uninstalled/re-installed, updated Android Studio to 4.0.1. In the Module Settings, the "Compile Sdk Version" is 29, and the Target SDK Version and Min SDK Version to 29. Nothing helps or has any effect. Many of these steps were suggested in similar posts.
The View.java file it tries to open is at: ~/Library/Android/sdk/sources/android-29/android/view/View.java. This should be the correct file, yet the debugger is in the wrong part of the file while I get the error message.
Putting on my black hat, let's assume that my laptop's View.java is correct for that API level: could my phone be running non-standard code, and is there any way to detect that or rule it out?
I think I figured out what was happening and I have a solution for this problem when it happens with Android SDK files. Frighteningly, the Android SDK Platform gets updated to Revision 5, but the source package is not updated. It is still on Revision 1! Why this happened, I cannot explain: a reasonable person would expect both to be in sync. This screenshot shows the source code does not match the binary that Android Studio downloaded:
The only way around this is to manually download the files you need and patch them manually in your SDK source directory. It's ugly, it's unnecessary, but if you really want to step through a specific SDK file you have to do it.
Find out what Android build you have. On your device, go to "Settings" -> "About phone" -> "Android version", and note down your "Build number" value. Mine is QQ3A.200805.001.
Find out the Tag corresponding to your Build number using this page: https://source.android.com/setup/start/build-numbers#source-code-tags-and-builds. For my build number, the tag is: android-10.0.0_r41
Download the AOSP source for this tag. This takes a long time if you are doing this for the first time. See https://stackoverflow.com/a/14353644/259718 for an example on how to do that.
Copy the files to overwrite some of the source directories: cp -pr ~/android_src/frameworks/base/core/java/android/* ~/Library/Android/sdk/sources/android-29/android/ (use the correct location for your environment, here I am compiling with android-29)
While not all of the directories in the android sources folder are overwritten, the core android files are overwritten. These comprise the majority of the source material. If you need other directories (e.g. "filterpacks"), you'll have to find that in the other AOSP directories (e.g. frameworks/base/media for "filterpacks").
Here are the steps I followed to get just one individual file:
Find the file you need on https://android.googlesource.com. Using google.com, I found it at: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/View.java
Determine the Android repo your file lives in. Looking at the previous URL, I can deduce it's at: https://android.googlesource.com/platform/frameworks/base/
Grab that repo using your tag. Or grab that tag's most recent revision of that individual file on-line, e.g.: https://android.googlesource.com/platform/frameworks/base/+log/refs/tags/android-10.0.0_r41/core/java/android/view/View.java, revision 18c0fbf.
To download the individual file, add "?format=text" to the URL to get the base64 encoded version. Then decode it: cat file | base64 --decode.
Now you have the file. Go to your SDK directory that contains the errant file: cd ~/Library/Android/sdk/sources/android-29/android/view/
Backup the old file (cp -pr View.java View.java.orig) if you want (you can always re-install the SDK source files if you mess up). Copy in your new file into the same location.
Now, your debugger will use the correct file! You will have to do this for each file that your debugger complains about.
I hope this helps someone else in the future. I spent a lot of time figuring this out and I sincerely hope someone else won't have to waste that time. Google needs to keep the source packages consistent with the release packages. Looking at all the past SDK releases, none of the source packages appear to be in sync with the latest release version. Maybe another ugly way to debug SDK files is to use a Revision #1 SDK release version that matches the Revision #1 source package.
Unfortunately curious_george's solution only works if the device has a version of Android built directly from the published Google sources. Device manufacturers are not obliged to do that, and the Apache Licence used by Google, unlike the GPL, does not oblige publishers of derivative works to give access to their sources.
My device is a Samsung Galaxy S21, and the build number of the currently installed Android is
SP1A.210812.016.G998BXXU4BULF, which is of course not listed in https://source.android.com/setup/start/build-numbers#source-code-tags-and-builds.
The versions of the sources tagged 210812.016 listed there are
210812.016.A1 android-12.0.0_r3 Tue Aug 24 18:43:39 2021
210812.016.A2 android-12.0.0_r25 Tue Aug 24 18:43:39 2021
210812.016.B1 android-12.0.0_r30 Fri Dec 24 23:08:44 2021
210812.016.C1 android-12.0.0_r31 Sat Dec 25 00:36:35 2021
They all appear to have the same version of View.Java, and Android Studio says that it isn't the version in my device. Even a comment change can confuse the debugger since it looks for the code at a particular line number.
At the moment I also can't debug using the emulator, which would presumably have a genuine Google release of Android, since the latest release of Android Studio (Android Studio BumbleBee | 2021.1.1 Patch 2, Build #AI-211.7628.21.2111.8193401, built on February 17,2022) seems to have broken it. The emulator either locks up its UI or crashes when started, and the debugger can't connect to it.
So there seems currently to be no way of solving the originally posted problem.
HELP!!
I use JavaCV 1.1. I have added jar files (javacv.jar, javacpp.jar and opencv.jar) and *.so libraries to my project in Android Studio. I succesfully build and run my app on Android 5.1 phone, but when i try use functions, that used OpenCV i get error:
java.lang.UnsatisfiedLinkError:dalvik.system.PathClassLoader[DexPathList[[zipfile"/data/app/com.example.dogan.ligntningshower-/base.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]] couldn't find "libopencv_core.so"
I try to add
static {
System.loadLibrary("opencv_core");
System.loadLibrary("jniopencv_core");
}
but it's no work. How to fix it?
I just add *.so libs to folder /app/src/main/jniLibs/armeabi and now all works fine!
if someone still looking for the answer, first you should check if you added correct files to jniLibs folders. heres a complete tutorial :
A Beginner’s Guide to Setting up OpenCV Android Library on Android Studio
second, if .os files are at their places in each and every folder then you should only change the names to the name that is showing up in the compiler error.
in my case the names were libopencv_java3.so and yet the compiler was saying couldn't find "libopencv_java343.so" . after changing the name to libopencv_java343.so it worked.
I’m trying to convert a version 401 binary dictionary -- a directory called PersonalizationDictionary.en_US.dict -- to human readable .xml.
The command line utility dicttool_aosp in packages/inputmethods/LatinIME/tools/dicttool can do it like so:
dicttool_aosp makedict -s sourcedict.dict -x output.xml
I’m unable to compile the Android Lollipop version of dicttool, since dicttool has native C++ dependencies that don’t play nice with my Mac. Note this line in the NativeLib.mk file of dictool:
HACK: Temporarily disable host tool build on Mac until the build system is ready for C++11.
I am hoping someone with a compatible setup can compile this utility for me using “make dicttool_aosp” from the root of the AOSP source tree. I've spent the past few days looking for compiled versions of it, and while I’ve found many makedict.jar files online, they are too old to support my newer V401 binary dictionary. The main difference between the V401 and older versions is that a V401 is split up into multiple files with extensions like .bigrams, .freq, .header, whereas the older dicts are contained in a single file.
Thank you, please let me know if I can clarify anything!
I'm trying to use JRuby in projects created in Android studio. I have built the latest (as of 9/10/2014) JRuby, and have completely updated Android Studio. I have a working app that I can use to test. I have a copy of jruby.jar in the MyApp/app/libs directory. Once there I right-clicked on jruby.jar and selected "Add as Library", which presumably did something (though what I am not certain), and have added the line "compile files('libs/jruby.jar')" to the build.gradle that is in MyApp/app/.
In one of the class files I have "import org.jruby.embed.ScriptingContainer;", which Android Studio says is fine (if I hadn't added jruby.jar as a library I couldn't include this without an error). Then in one of the working methods I say "ScriptingContainer container = new ScriptingContainer();". When I run this method the app will crash. I won't try to include the whole error message, but the important part seems to be:
Caused by: java.lang.ExceptionInInitializerError
at org.jruby.embed.internal.AbstractLocalContextProvider.<init>(AbstractLocalContextProvider.java:42)
at org.jruby.embed.internal.SingletonLocalContextProvider.<init>(SingletonLocalContextProvider.java:88)
at org.jruby.embed.ScriptingContainer.getProviderInstance(ScriptingContainer.java:248)
at org.jruby.embed.ScriptingContainer.<init>(ScriptingContainer.java:228)
at org.jruby.embed.ScriptingContainer.<init>(ScriptingContainer.java:185)
and
Caused by: java.lang.RuntimeException: unsupported Java version: 0.9
at org.jruby.RubyInstanceConfig.initGlobalJavaVersion(RubyInstanceConfig.java:1858)
at org.jruby.RubyInstanceConfig.<clinit>(RubyInstanceConfig.java:1608)
At least, those are the parts that make sense to me. I hav no idea why I would get the error "java.lang.RuntimeException: unsupported Java version: 0.9", since I am using 1.8.0_20. The rest of the errors I cannot follow. When I click on any of the files giving me an error (say AbstractLocalContextProvider.java:42) Android Studio will show the file but also say "Sources not found". That could be the problem, but I don't know why it can't find the sources.
Thanks for any help,
Brian
Uwe Kubosch (#donv70) was able to tell me the solution to this via Twitter, so credit to him, but I wanted to post the solution here in case anyone else needs it.
It was Java version that was causing the problem. In Ruboto the problem is solved here: https://github.com/ruboto/ruboto/blob/master/assets/src/org/ruboto/JRubyAdapter.java#L137
and for use in Android Studio it is necessary only to include the line: System.setProperty("jruby.bytecode.version", "1.6");
The number of course can be 1.6, 1.7, or 1.8, depending on your version of Java.
Looks like an interoperability problem between JRuby and the Dalvik VM (don't forget that you're running against Dalvik, not the Java VM).
There's a bug report at http://jira.codehaus.org/browse/JRUBY-5774 that may lead you in the right direction.
It's kind of old, and is marked 'fixed', but maybe it'll provide some clues?
When I try to extract apk file through apktool api, related extract process never finishes. Same code works well for Java projects. But when I use it inside Android application through virtual device, extract process never finishes.
Here is the code that I use:
ApkDecoder decoder = new ApkDecoder();
decoder.setApkFile(apkFile);
decoder.setOutDir(outputPath);
decoder.decode();
As I said on IRC.
It won't work. There are 2 dependencies in Apktool that
won't work on Android. Yaml and some java 7 code.
Thats why it works fine on Java, but not in Android environment. Bug for java7 code, and the bug for Yaml.
Yaml is only used for parsing out the apktool.yml file, which is needed for recompile. Java 7 features were introduced for SmaliDebugging and NIO2 aids. If neither are needed, you could recompile the apktool binary without those two. (Of course then missing those features)
It may be useful for you: online version of the apktool is available here: www.javadecompilers.com/apktool
Hope, it would help you to decompile the application without installation of the numerous prerequisites.