Trying to convert an existing Android build system using Ant with 'ant_rules_r3.xml' integration from the older SDK to the newer SDK 'main_rules.xml' setup. We have some custom SVN tasks patched into the 'ant_rules_r3.xml' file too, so it might not be as simple as a file swap.
Are there any guides, info, or blogs on how the SDK has been changed and what I need to do to make the conversion? Have the tasks and/or parameters changed?
Thanks,
DD
I couldn't find any change notes or other references when I upgraded my SDK. It took a while for me to realise that they'd changed the name of the file to main_rules.xml. I was pretty annoyed to find that my builds failed.
Firstly you will need the latest 1.8.? version of Ant, 1.7 definitely won't work. I found that if you've overridden the compile target,then the line in the target
<src refid="android.libraries.src"/>
now needs to be
<src refid="project.libraries.src" />
I think that was the main thing, though there may be others.
Having had my whinge about the change, I must say that the new obfuscation target worked straight out of the box and has turned out to be useful.
Related
My gradle build completes successfully, but I get:
WARNING: Unsupported Kotlin plugin version.
The `embedded-kotlin` and `kotlin-dsl` plugins rely on features of Kotlin `1.5.31` that
might work differently than in the requested version `1.6.10`.
All of my build.gradle.kts scripts refer to using version 1.5.31. The only association my project has with version 1.6.10 is that Android Studio has the Kotlin version 1.6.10 plugin added. If I try to disable that plugin, I get a message that several other plugins will be disabled. If I accept that, android studio crashes and will not start up again. It won't start up again even if you reinstall android studio again. The solution is to find the file named "disabled-plugins.txt" and delete that file. It's in your AppData folder and in a JetBrains subdirectory. It turns out that it's one or more of those other disabled plugins that prevents Android Studio from starting up again.
The question I have is how do I fix this version mismatch issue. I can't delete the plugin from Android Studio for the reasons I mentioned above. If I try to update my project to using version 1.6.10 I get literally 100's of unresolved dependencies. And it seems from opinionated investigation that 1.6.10 still have too many issues for general use.
By the way, when I look at the gradle window for the project I can see where the dependencies come from. Usually when I look at the gradle window I just see sub project folders that I can drill into for more information, but for this project, it has an additional folder name dependencies. I don't know how they get into my project. But when I look at their version numbers that's where the 1.6.10 mismatch happens.
So, I think I understand why the warning message is valid, I'm at a lost on what I need to do to correct this situation. For the moment, I'm just ignoring the warning, and so far I'm not finding any issues in proceeding that way. But that's means I'm proceeding, without an understanding of what's going on here! Sometimes that's okay and at other times that's a bad judgment The error message itself seems inverted. I would think that 1.6.10 is the embedded kotlin and kotlin-dsl since it an android studio plugin, but the error message seems to say it in the opposite way. So anyway, if someone can bring some clarity as to what's going on, and how I'm thinking wrongly about this problem would be greatly appreciated.
I'll accept the following as the answer to what's going on about the unsupported kotlin version:
https://github.com/gradle/gradle/issues/13020
So, for the moment, I'll go on like this is just a nuisance warning and ignore that.
What I just did was to re-create my Android Studio from a blank brand new project. I copied and pasted stuff from the previous project into the new project. I copied the source and build.script.kts files, so essentially everything is a copy of the disabandoned project. This new project didn't give me the WARNING message anymore. And in additional, I'm now able to upgrade my project to using kotlin 1.6.10, which I previously couldn't do because of the literally 100's of dependencies resolution issues. Whatever, that issue went away, and a lot of others things started working as expected once I recreated the project. I can't say what got my project into that weird state. Deleting the .gradle and .idea folders, wouldn't fix the problem. I didn't try deleting the JetBrains cache, I wish I would have tried that.
I'm experiencing a strange behaviour from Intellij that I never had before. I don't know if it's related with this new update (14.0.3) or what. So what happens is every time I add a new resource, let's say a new .xml or a new View in a previous .xml file, my R file doesn't get updated, I've to compile the hole project again, otherwise it warns me about not finding that resource. I've tried to delete the gen folder but it doesn't work either and it gets worse, all my R references get mixed up so I end up with CastExceptions and misplaced drawables, the only was is to re-compile again... It never happen to me before.
Anyone experienced this kind of behaviour?
Four Suggestions:
1) Make sure that you are indeed using the latest-greatest Android SDK Build Tools.
2) You could probably use lint to determine the lint warnings. Go to File > Settings > and search for lint in the search box. You will find lot of different options in there. Make sure they are checked. I have had some instances when lint would complain that i am using an attribute in the .xml that is not supported and that sometimes catches Intellij off guard.
3) Go into the project structure and at the very bottom there should be a tab Problems. Make sure that tab is clean. Sometimes if there is an issue with the path while using third party libraries, R.java breaks.
4) Make sure you are indeed using the correct api's available for the target/min SDK you specify.
Hope this helps. If you find the solution please update the OP so that it might be helpful to someone else.
So I've contacted JetBrains support and their response was:
Andrey Dernov (JetBrains Support)
Feb 16, 11:41
Hello,
There was a bug with Android projects https://youtrack.jetbrains.com/issue/IDEA-135234 . The issue will be fixed in upcoming 14.0.4 update. Or you can use the last EAP build from https://confluence.jetbrains.com/display/IDEADEV/IDEA+14.1+EAP . We are sorry for inconvenience.
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
One developer on my team has some setting in Android Studio that replaces the distributionUrl entry in gradle/wrapper/gradle-wrapper.properties to use the gradle-###-all.zip, while my Android Studio changes it back to gradle-###-bin.zip.
Basically, my diff always looks like:
-distributionUrl=https\://services.gradle.org/distributions/gradle-1.12-all.zip
+distributionUrl=https\://services.gradle.org/distributions/gradle-1.12-bin.zip
This is annoying. What setting is it, and how do I change it?
gradle-1.12-all.zip file will have binaries, sources, and documentation.
gradle-1.12-bin.zip will have only binaries(That should be enough as you don't need any samples/docs)
If you want to know about gradle wrapper, please check this
http://www.gradle.org/docs/current/userguide/gradle_wrapper.html
If you and the other developer want a uniform experience, place this code in your build.gradle file
wrapper {
distributionType = Wrapper.DistributionType.ALL
}
This will make ./gradlew wrapper --gradle-version 5.6 automatically append -all instead of -bin
For build.gradle.kts:
tasks.wrapper {
distributionType = Wrapper.DistributionType.ALL
}
Like #San said, -all will have binaries, sources, and documentation, while -bin will just have the binaries.
From what I've seen Android Studio recommends to use gradle-*-all.zip and even provides a "quick fix" to change that. On the other hand, the command ./gradlew wrapper sets up the wrapper using gradle-*-bin.zip, overwriting the previous setting. Make sure nobody is calling "./gradlew wrapper" automatically.
The difference is that the -bin version contains only the runtime and no sample code and documentation. 1
It actually makes sense to go for the -bin version: it is smaller and you're unlikely to need the -all version unless you're debugging Gradle scripts. For this reason, the lint warning to go for the -all version has been removed. Also, new projects are generated with the -bin version by default.
There is a ticket to let IntelliJ download the sources when you need them (after which there really isn't a reason for the -all version), but it hasn't been implemented yet.
I'm trying to get an (inherited) Android project to build. I'm using Ant & command line tools (and IDEA).
In styles.xml, there are references that cannot be resolved such as:
<style name="AppBaseTheme" parent="#style/Theme.AppCompat.Light">
This is the original error I ran into:
[...]/res/values/styles.xml:8: error: Error retrieving parent for item:
No resource found that matches the given name '#style/Theme.AppCompat.Light'.
I then noticed that project.properties has this appcompat reference which is broken on my (OS X) machine:
target=android-18
android.library.reference.1=../../../../adt-bundle-linux-x86_64/sdk/extras/android/support/v7/appcompat
I tried to fix that by making the reference relative to ${sdk.dir}:
android.library.reference.1=${sdk.dir}/extras/android/support/v7/appcompat
So now that path should be correct. But now when I run ant debug:
BUILD FAILED
/opt/android-sdk-macosx/tools/ant/build.xml:573:
/opt/android-sdk-macosx/extras/android/support/v7/appcompat resolve to a
path with no project.properties file for project /Users/joka/devel/project/
So, any ideas? What's the simplest way to get this project built?
(Please note that Ecplise-specific advice won't be useful to me.)
Edit: The Android SDK installation looks like this:
As Jay indicated, only relative paths will work on Unix/Mac.
For the Ant build to work, I also needed to generate build.xml for the appcompat project, using the command android update project -p <dir>, in my case:
/opt/android-sdk-macosx/tools/android update project
-p /opt/android-sdk-macosx-r22.0.1/extras/android/support/v7/appcompat
The exact config for me was:
android.library.reference.1=../../../../../../../opt/android-sdk-macosx/extras/android/support/v7/appcompat
(This also works in local.properties, which I think is a better place since the same path won't work for all developers.)
I merely promoted my comment from 6 months ago into an answer as someone suggested.
By the way, now that I actually know something about Android development, I'd urge anyone who has the chance to ditch Ant and look into the new Gradle-based build system which is totally sweet in comprarison. It is CI-friendly and makes it easy to automate useful things (like using different package name and app icon for different build types). Stack Overflow will help when you run into problems.
Using the support libraries with Gradle, you'd skip all the above hassle and simply do:
dependencies {
compile "com.android.support:appcompat-v7:18.0.+"
}
I ran into the same problem, so I tried using a relative path and that fixed the problem for me. It looks like only relative paths work with android.library.reference. I did a quick search to verify this, and came across this stackoverflow link which indicates that absolute paths will work with android.library.reference on Windows, but not on Unix or Mac.
Peace.
Your path seems to be wrong (you are missing the 'compatibility' part).
The v7-appcompat library is at
{sdkpath}/extras/android/compatibility/v7/appcompat
for me (SDK Tools version 22.0.5 on Max OS X 10.7.5)
I came across this after updating my SDK tools from revision 15 to 17, seems like there are quite some changes under the hood that cost me a long evening. Figured I share this so I hopefully save somebody else's nerves:
After updating my project would still compile and build, but at runtime throw all kinds of errors and exceptions NoClassDefFoundError, ClassDefNotFoundException or the dalvik vm complaining in logcat that it was not able to resolve some classes or super classes. Turned out that it was not able to load classes that were located in external jar files (which were on the classpath).
SOLUTION / ANSWER: (unfortunately stackoverflow does not let me answer this due to lacking reputation)
Turns out that since revision 17 of the sdk tools, only external libraries that are marked to be exported in java will be part of the apk at runtime. So the solution is simple:
Go to Java Build Path -> Order and Export and check the box next to all your jars that you need at runtime (should usually be all of them).
I'm not sure whether I should have done that before, but with revision 15 and earlier this was never an issue.
Just add the library Jar files to you apk. Its very easy to do it.
Right Click on the project and click on properties.
Click on the Java Build Path and move to the Order and Export Tab.
Click on Select All on the right side. Click on ok.
Re-build the application and try running the application.
Now it should work. Lemme know if it worked for you.. ?