-
-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade Nativescript gradle version to the latest #938
Comments
Hi @RVEIII, |
Hi @Plamen5kov, Thank you for looking into this. This is actually a huge issue for the project I'm on. Is there any indication yet of a time frame you are planning to have a fix for this in? We currently have an iOS application that customers are using and are porting it to Android. We have a lot of UI elements that come from external libs that we are using in via plugin. The issue we're having is that we cannot get the app to run consistently consuming these .aar files. This seems to be because they are built with Android Studio and have a newer version of gradle that supports Java 8...but I can't truly confirm that. Our project setup is that we have our own library project that depends on those external libraries to build. Then we have those set as compile dependencies in the include.gradle in our plugin's platforms/android/ directory alongside our library's .aar file. But pretty much every time I run the project I get a crash with this(I've hidden our info...but you get the point):
I have gotten it to work a handful of times by removing all of the plugin libs, building(which crashes because the plugin code is not available), then reinstalling the plugin and rebuilding without deleting platforms/android first. Here is our app.gradle:
and our include.gradle for our plugin:
|
Hi, @RVEIII |
@Plamen5kov - That's great news. Thanks! I'm trying to build this now but I'm having a bit of trouble. What's the best way to generate the android-runtime and use it with our own application? The build instructions for this seems to be building a test application. |
@RVEIII following the build instructions (executing
|
@Pip3r4o and @Plamen5kov, this seemed to fix our build issues. There is one problem with the change though. When I build and then try to run the client via
The apk exists in a subfolder of that with the format flavor/debug/app-(flavor name)-debug.apk. I tried copying that apk to the build/outputs/apk directory and it still didn't pick it up. So I just verified the apk by using adb. Can you please look into the issue with the apk location? Also, is there any way we could get some sort of snapshot to use with this in it? We are looking to start serious Android development soon and would like a stable build to use until 4.0 is released. Thanks a lot for the quick responses and fixes! |
@RVEIII, the resulting apk name is |
Hey @Plamen5kov, The resulting apk is not named app-debug.apk. With my gradle script using the following product flavor:
The apk is placed here: platforms/android/app/build/outputs/apk/testFlavor/debug/app-testflavor-debug.apk. I did use adb to install it and that was fine. But it used to simply work with tns run android. And this is important to allow an easier workflow in debugging. |
@RVEIII working with flavors will be fully enabled in the upcoming 4.0 release of NativeScript. Right now there is no code in the NativeScript CLI that can handle installation of apks which break the convention that has been established. In the simple case where no flavors are used, Please keep in mind that we're providing a temporary workaround here, and not a complete solution. Another thing to note is that, when you start building for multiple flavors, CLI will not be able to make a decision which one of the built APKs to install on the device, so a flag and/or an interactive picker will be provided for your convenience. We'll let you know when the release candidate for 4.0 is ready so that you may give it a go. |
Cool, thanks for clarifying @Pip3r4o. I'll remove them and see how that works. One more question, is there a way we could get some sort of milestone build to use once this fix is merged to your master branch? We'd like to use it without taking changes every time a developer needs to build the tns-android project. |
@RVEIII I am not sure I understand entirely what you are asking here - you could consider the branch a 'milestone build' - build it once and reuse it. The next release will be a major one - 4.0 and in preparations for it, it is unlikely that we will ship any significant changes until then. |
Hey @Pip3r4o, I was asking for some sort of repo that we could pull a build of the tns-android tgz file from. I suppose we can maintain our own repo with a copy of it in it. I am still seeing the issue with running the apk on Android without the flavors. Without any flavor, it builds this:
Even if I copy it here:
|
@RVEIII that is correct, if you notice the changes in this commit in the branch in question, there is some code removed which originally took care of renaming the apk to something appropriate which the NativeScript CLI could install. As stated in one of my previous responses, the CLI currently expects to find If you are feeling adventurous, you could also maintain a local distribution of the CLI, which will have the apk names Modify the lines https://github.com/NativeScript/nativescript-cli/blob/3064e0d3a452fa708adde255ebca17b2c31bb159/lib/services/android-project-service.ts#L90 to include |
Ah, ok. Thanks @Pip3r4o. I missed the (appName) part of that. |
Gradle is updated to 4.1 and the android plugin to 3.0.1 . This will be available in the next official |
From @RVEIII on February 1, 2018 19:40
Did you verify this is a real problem by searching the NativeScript Forum and the other open issues in this repo?
I searched for Gradle issues and read a lot of them. It did not answer my question/problem.
Tell us about the problem
I have an application that uses a plugin that depends on a few Android libraries from an external source. Those libraries were compiled with Java 8, Android Gradle Plugin 3.0.1, and Gradle 4.4. The min sdk is 21 and the target is 27.
In my nativescript app, I can get those library dependencies brought into the apk by putting them in my plugin's include.gradle. The issue though is that when I build the app I get this error:
Dex: Error converting bytecode to dex:
Cause: Dex cannot parse version 52 byte code.
This is caused by library dependencies that have been compiled using Java 8 or above.
If you are using the 'java' gradle plugin in a library submodule add
targetCompatibility = '1.7'
sourceCompatibility = '1.7'
This error is remedied by using the Jack compiler option in my app.gradle and the source and target compatibility set to Java 1.8:
I have a requirement to be able to support this app on sdk 21+. But due to the use of the Jack compiler option, it won't allow me to use anything before 24. I would not have this issue if I could use a newer version of gradle to build the Nativescript app. It seems that Nativescript uses 2.3.3. But I need 3+.
Is there a way to change this? I tried with a classpath dependency but the issue there is that the build.gradle file that gets generated for platforms/android has methods in it that are no longer available in Gradle 3. I need to be able to use the latest version of the Android Gradle plugin to build my app.
Which platform(s) does your issue occur on?
Android
Please provide the following version numbers that your issue occurs with:
Please tell us how to recreate the issue in as much detail as possible.
Build a Nativescript app for Android and see that Gradle 2.3.3 is used.
Copied from original issue: NativeScript/NativeScript#5370
The text was updated successfully, but these errors were encountered: