I recently broke the Dalvik Limit (https://developer.android.com/studio/build/multidex.html)
of 64K referencs as I started getting
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/
Xamarin.Android.Common.targets: Error: Tool exited with code: 2.
Output: trouble writing output: Too many field references: 77369; max
is 65536. You may try using --multi-dex option.
error after updating some nugets to MonoDroid 7.
When I turn on the MultiDex option in android settings and compile my project I get -
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets:
Error: Tool exited with code: 10. Output: Error: Can't read
[/Library/Frameworks/Xamarin.Android.framework/Versions/7.0.1-3/lib/xbuild-frameworks/MonoAndroid/v7.0/mono.android.jar]
(Can't process class [android/app/ActivityTracker.class] (Unsupported
class version number [52.0] (maximum 51.0, Java 1.7)))
(pjr.mob.android)
I can see BUGs relating to this -
https://bugzilla.xamarin.com/show_bug.cgi?id=44187
https://bugzilla.xamarin.com/show_bug.cgi?id=44013
https://bugzilla.xamarin.com/show_bug.cgi?id=33052
https://bugzilla.xamarin.com/show_bug.cgi?id=35491
It looks like I have to manually download and install ProGuard 5.X as detailed in these answers -
Xamarin.Android Proguard - Unsupported class version number 52.0
Xamarin Android ProGuard Enable
and overcome any issues that arise from this.
Yet, Xamarin Studio explicitly tells us in the (i) information box next to the proguard option is that it is not recommended to run proguard for a DEBUG build and that we should only run multidex after trying proguard first.
Will this mean we cannot debug effectively after enabling it? but I cannot DEBUG anyway (I cannot even run a release build even with the linker on which I thought might help) now without enabling it?
Is there some kind of Xamarin Support coming for this or do I need to look at somehow reducing the packages etc that we use (I am not sure I can do as most of it is Google Play Services related).
Any help is appreciated.
Other Info from Xamarin Studio Help > About
Java SDK: /usr
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16, mixed mode)
Unsupported class version number [52.0] (maximum 51.0, Java 1.7)
1st) The error you got is from not having Java v8 installed and/or Xamarin configured to use it.
Ref: java Lang UnsupportedClassVersion Error in Xamarin Studio
2nd) MultiDex can be used without Proguard and is only needed on API-20 and below. Enabling Multi-Dex enables the Android SDK tools to create as many secondary sex file as needed.
3rd) If you are enabling Proguard, you should look at replacing the proguard.jar in your android-idk with the Facebook version as it is sooooo much faster ;-)
Ref: https://github.com/facebook/proguard
Or use the SourceForge-based one:
Ref: Xamarin.Android Proguard - Unsupported class version number 52.0
To clarify where I got to with this for future readers -
a) The 52.0 Error was due to the fact that the included ProGuard version with Xamarin required updating to the latest version (even after I had upgraded my JDK to 1.8 as discussed) -
Xamarin.Android Proguard - Unsupported class version number 52.0
NOTE: AFAIIA: I could not run multi-dex without fixing the proguard error first.
b) Xamarin Studio unfortunately lets you TICK pro guard for debug builds but then in turn does NOT actually run ProGuard for debug builds, causing confusion if you are very new to using it + trying to work out how things hang together.
The xamarin docs tell you this on inspection, which might be the case for VS -
ProGuard is disabled by default. The Enable ProGuard option is
available only when the project is set to Release mode. All ProGuard
build actions are ignored unless Enable ProGuard is checked.
c) So, when hitting the MultiDex limit; in order to progress -
DEBUG - enable multiplex only, this should (when working, I am still working on it in XS) allow you to bypass the 64K error as expected AND debug will work as expected.
You should leave your linker to No Linking as usual for debug builds.
RELEASE - enable ProGuard firstly to see if you can configure it to bring down your method count without requiring the overhead or multidex as it brings in the secondary methods at run-time.
If you don't want to mess with Proguard config then as an intermediate step your multidex set-up from DEBUG should just work for your release when fully tested.
When any documentation states you should try ProGuard first and then multidex it means just for a RELEASE not for debug build.
UPDATE: I also had to go via Xamarin Support to get my Multi-dex to build, but as of https://releases.xamarin.com/stable-release-cycle-8-service-release-1/ this is now working fine. My Android project in XS had a custom application class and that was not being correctly inherited by the build tools from the required multidex class when ticking Multidex.
Under Xamarin Studio -> Preferences -> Projects -> SDK Locations -> Andorid was pointing to a directory that I was no longer using for the more recent SDK updates. Changed it to point to the correct SDK directory and build succeeded.
Related
After a recent update, Android Studio fails to build an unmodified project with errors along these lines:
> A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
> AAPT2 aapt2-4.1.1-6503028-linux Daemon #0: Unexpected error during compile '/path/to/app/src/main/res/mipmap-xxxhdpi/ic_launcher_round.png', attempting to stop daemon.
This should not happen under normal circumstances, please file an issue if it does.
Notice that it's failing on an image supplied by Android Studio itself!
What can I do to fix it?
This seems to be an error in the newest (newer?) Gradle plugin(s) when it comes to PNG images; Google's IssueTracker lists several newly reported bugs along these lines. One of them mentions that it's a Gradle issue; I made mine work by reverting to a previous version: Gradle Plugin 4.0.1 and Gradle version 6.1.1 work fine.
It will be necessary to ignore AS' nagging about a newer version until this gets fixed.
[Added at the request of #YinOrYan]
To revert to an older version of Gradle:
In the menu, select "Files", then "Project Structure..."
In the dialog that pops up, select "Project" (first item in my version).
You can select the desired versions of the Gradle plugin and of Gradle from the drop-down menus.
This should not lose any system calls, as this is different from the SDK or API versions. However, it's not independent of them, so there is probably a limit to where you can set them.
As usual you will want to be online when you first build, or whenever you have to import a dependency, but otherwise it should be possible to work offline.
Sadly, it looks like an issue with older architectures. While the team at Google is looking into fixing it, in the meanwhile you can still use the new Android Studio and AGP, but temporarily revert to using an older version of AAPT2:
Try locating the old aapt2 executable in your gradle cache, e.g.:
~/.gradle/caches/<subdirectories, hashes
etc>/aapt2-4.1.0-alpha03-6246747-/aapt2(.exe)
Once you have the path you can add to your gradle.properties file:
android.aapt2FromMavenOverride=path/to/old/aapt2
To make this a little bit more robust you can actually copy that executable to a non-cache location, in case you clean your caches and it dissapears.
Hope this helps! Keep an eye on the Issue Tracker bug for updates.
I also had the same problem with AAPT2 errors and I have got over it.
First, downgrades Gradle to version 4.0.1, or
Second, I have done is upgrading the AMD Athlon processor to AMD FX-4300 without downgrading the gradle plugin version.
Wow, that's a real show-stopper! Can you explain how you reverted to an older gradle in Android Studio. Is it possible to work offline after doing this. And, did you lose any of the new system calls as a result? All this going on after finally getting my code working with the new AR Core stuff...
Just an observation that AS4.0.1 no longer clobbers IntelliJ (2020.2) initiated project settings any more, and merely complains of 'unsupported Modules' being detected(Note *).
Is this the beginning of Détente with peaceful co-existence (I wouldn't want to be unhappily surprised in future)?
Just to give specific context, here is what I refer to: (both reject the last configuration - a failed hack) and utilise their preferred first or second one respectively: This is a GOOD thing)
From IDEA 2020.2:
Unsupported Modules Detected: Compilation is not supported for following modules: CalibSense.app.
Unfortunately you can't have non-Gradle Java modules and Android-Gradle modules in one project.
The IDE modules below were removed by the Gradle project reload:
app
You can open DIALOG to select the ones you need to restore.
DIALOG LIST:
Android App:
[x]app
[v]Badroid.CalibSense.app (level: WORKSPACE)
[x]CalibSense.app (level: WORKSPACE)
From AndroidStudio 4.0.1(somewhere between IDEA 2019.2 and 2019.3):
Unsupported Modules Detected: Compilation is not supported for following modules: CalibSense.app.
Unfortunately you can't have non-Gradle Java modules and Android-Gradle modules in one project.
DIALOG LIST:
Android App:
[v]app
[x]Badroid.CalibSense.app (level: WORKSPACE)
[x]CalibSense.app (level: WORKSPACE)
Suggested Update AS 4.1 (including - All improvements from IntelliJ IDEA 2020.1.4)
Note *: It turns out they both complain of an illegal configuration, not of each others working configuration.
Nope.
The problem is in a different version of the IntelliJ Platform. Android Studio and IntelliJ Idea is developing separately because it's different products of different companies.
Google adopts the IntelliJ Platform in Android Studio - so we can think about it as about hacked IDEA.
So usually backward compatibility exists - it means that I can open in a new version of IntelliJ IDEA my older projects, but not vice versa.
So if look at AS 4.0 release notes we can mention that it is based on IntelliJ IDEA 2019.3.3 (https://developer.android.com/studio/releases#4.0-idea-2019-3-3). But your try to open a project of newer version IntelliJ Platform (2020.2). So it fails because your try to open a newer project version (2020.2) by old IDEA (2019.3.3)
But you can without issues open a project of AS 4.0 with IDEA 2020.2 - it will simply convert older project layout to new.
I have just installed Netbeans 11.1 and when I save one of my Java files, Netbeans does not start a gradle build automatically. This used to work in Netbeans 8.2.
I have installed nb-javac and have also tried the newest Beta version to no avail.
Is this a known bug or do I need to reconfigure something when going from NB 8.2 to 11.1?
(This is only an explanation rather than a solution to your problem.)
First, Compile on Save is an option which is set or unset at the individual project level, rather than at the global level. So for a NetBeans Gradle project, select Properties > Build > Compile to view the setting for the Compile on Save checkbox. For that checkbox, note that:
It is unchecked by default, so there will not be an automatic Gradle build when you save a project file.
It is disabled, so you cannot trigger a build whenever you save a project file.
The problem persists in the latest beta of NetBeans 11.2.
I don't see a bug report for this issue, so perhaps you can raise one? Click the Log In button to sign up first if necessary.
That said, there is a related issue which may explain why the check box cannot be enabled. See closed bug NETBEANS-680 Erroneous Gradle Compile-on-Save activity which relates to Gradle projects using version 9.0 of NetBeans. Apparently there were spurious and unwanted compile-on-save runs being triggered even though Compile on Save was unchecked. Perhaps the feature has been deliberately disabled for Gradle projects because of that issue, though that is just speculation on my part.
Also see the GitHub page for the Gradle plugin. Comments from the NetBeans team for NETBEANS-680 suggest that the problem was with the plugin rather than NetBeans. That said, if NetBeans is offering functionality that cannot be enabled (i.e Compile on Save), it is definitely a NetBeans issue regardless of the underlying cause.
Finally, note that you can configure the Gradle plugin using Tools > Options > Java > Gradle, but I dodn't see any options there that would help with this issue.
I have attempted to archive my project for submission to App Store, however, every time I get errors "use of undeclared identifier" for everything related to google iOS SDK. The application itself runs and builds flawlessly with the discussed SDK integrated, the only thing that fails is the archive process. I have tried both cocoa pods and manual method of integration (separately, of course). Furthermore, I used the latest xCode versions (6.4 and 7 beta 4) on two different macs running OS X 10.10.4. This is the guide I have been using.
Your issue has something to do with the configuration of archiving in combination with your Release settings. If you change the scheme settings Command + < to use the Debug configuration for archiving, you may be able to successfully archive your app. This means that somewhere you are probably not matching the Debug and Release configurations.
See the following screenshot for example project Build Settings that are missing the Swift bridging header in release:
Add bridge.h to the release configuration and you will be able to build with the Release schema and you will be able to archive under release configuration.
I have been asked to update some old code I worked on years ago. All in xCode no eclipse and the change is needed urgently so do not have time to migrate away from xCode ATM.
I got my hands on a OS 10.5.8 box installed xcode 3.1.4 and the code compiled fine locally.
Tried to deploy never worked " Unsupported major.minor version 49.0 error" seems the server is running JVM 1.4.2 I have 1.6 locally. I followed some instructions on how to downgrade my local machine to java 1.4.2 without success.
So I gave up and put an old copy of the site back on the server. But now ALL the sites on the server get that same error message and none of them will start even though they have not been touched in 3-4 years. Not sure what happened? my only logically explanation is i accidentally did one action on the server instead of locally? Either way I have no idea what is wrong or how to fix it?
Where do I start trying to debug this?
Can I install a new version of java 1.5 or 1.6 on the server (OS 10.3.9) and have it work ok with webobjects?
Was this project a framework or an Application? If it is a framework that is depended-on by the other WebObjects projects, that would explain why everything started failing when you updated this project.
By default, Xcode did not include (or "embed") any depended-upon libraries or frameworks in the Project.woa bundle. Apps built this way depend upon any required resources being available in a few specific locations and then load them at launch. If they all now link to a framework or library that is incompatible, then they'll all stop working.
As far as the actual "Unsupported major.minor version" error goes, you do not need to downgrade the version of Java on your Mac, you can simply tell the compiler to target an older version of Java.
I can't remember if Xcode used Ant to do its Java compiling, but if it did and you are using Ant 1.7 or later, you can force Ant to compile 1.4-compatible binaries with Java 1.6 by editing the build.xml file so the javac tag includes a "target" parameter such as: <javac target="1.4" ... /> or by passing in the ant.build.javac.target property when you call Ant, either via command line or by modifying a properties file that Ant will load. I believe build.properties still existed in Xcode-based WebObjects projects. If it does this would be a good place for the property.
The basics are covered by this stackoverflow question: How to compile classes to JDK1.5 when ant is running in JDK1.6