I've been trying to employ Kawa Scheme for developing Android project. I've found two repositories on GitHub: one called 'android-kawa', and another called 'KawaDroid'. They're both a bit dated (last updates were around 2012). In the case of 'android-kawa' I was able to reach the author, but he said he did't remeber enough to help me.
In the 'android-kawa' repo there's a bunch of scripts for setting up and working with the project. One of the scripts downloads the Kawa 1.13 tarball, applies some patches and then attempts to build it.
However, the build isn't supported in Termux, bevaise the config.guess script doesn't recognize the system. This issue can be easily resolved by downloading the latest versions of config.guess and config.sub.
Another problem is the format of the JVM bytecode. When I use the latest Java compiler, the generated bytecode contains (I believe) instructions for JVM8+, which aren't supported by the dx command. This isn't a problem if I run Java inside of Termux, because it installs the regular JVM, but if I want to include the Kawa jar in my APK (which is something that I want), then it becomes an obstacle.
This, again, can be resolved by forcing the Java version to 7 in javac. (But then, the compiler complsins that Java 1.7 is deprecated. I guess this is why the buildAPKs project uses ecj instead of javac)
Also, when I ./configure Kawa, I can pass it the path to the android.jar file (./configure --with-android=...). I have two android.jar files on my system:
~ $ locate android.jar
/data/data/com.termux/files/usr/share/aapt/android.jar
/data/data/com.termux/files/usr/share/java/android.jar
I don't know where they came from or how they differ between one another, but I've been prefering the second one.
So, when I have the kawa.jar available - and when I try to compile it with the command
~/android-kawa $ java -cp $(dirname $(locate android.jar |tail -n 1)) -jar kawa/kawa-1.13.jar -C KawaHello/src/kawa/android/hello.scm
I get the following error:
internal error while compiling KawaHello/src/kawa/android/hello.scm
java.lang.NoClassDefFoundError: android/view/View
at gnu.kawa.android.defs.<clinit>(defs.scm)
at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1155)
at java.base/jdk.internal.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:42)
at java.base/jdk.internal.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:185)
at java.base/java.lang.reflect.Field.acquireFieldAccessor(Field.java:1132)
at java.base/java.lang.reflect.Field.getFieldAccessor(Field.java:1113)
at java.base/java.lang.reflect.Field.get(Field.java:425)
at gnu.expr.ModuleInfo.setupModuleExp(ModuleInfo.java:195)
at kawa.standard.require.importDefinitions(require.java:308)
at kawa.standard.require.scanForDefinitions(require.java:219)
at kawa.lang.Syntax.scanForm(Syntax.java:65)
at kawa.lang.Translator.scanForm(Translator.java:1120)
at gnu.kawa.lispexpr.LispLanguage.parse(LispLanguage.java:64)
at gnu.expr.Compilation.process(Compilation.java:1908)
at gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:305)
at gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:290)
at gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:290)
at gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:290)
at gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:290)
at gnu.expr.ModuleInfo.loadByStages(ModuleInfo.java:290)
at kawa.repl.compileFiles(repl.java:823)
at kawa.repl.processArgs(repl.java:444)
at kawa.repl.main(repl.java:869)
Caused by: java.lang.ClassNotFoundException: android.view.View
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520) ... 24 more
I have obviously tried it without the -cp argument (with the same effect). The android/view/View.class entry is present in the list returned by jar -tf android.jar.
How can I further investigate in the root cause of the problem, and most importantly, how can I solve it?
It turned out that I have invoked Java incorrectly, and that it didn't see the android.jar file. It helped to invoke the compiler in the following way:
~/android-kawa $ java -cp $(locate android.jar |tail -n 1):kawa/kawa-1.13.jar kawa.repl -C KawaHello/src/kawa/android/hello.scm
(the difference is that I only have one -cp argument with jar files separated by :, and that I explicitly give the kawa.repl class name)
My goal is to be able to make my Android TV Mi Box S (Oreo 8.1) transcode properly Dolby Digital+ (EAC3) sounds to Dolby Digital (AC3) and output it to, my AVR through SPDIF.
This transcodindg is possible with Kodi 18.1 applicition but is not proposed by other application or Android 8.1 settings. As Kodi is able to do it I reverse engineered Android stack. My conclusion are : - Android Oreo embeds any necessary codecs ans other stuff to do this transcoding but does not propose the settings to configure this - Android Pie proposes the wanted surround sound setting (output Dolby Digital on SPDIF)
So my goal is to backport Android TvSettings application from Pie to Oreo
I first tryed to generate TvSettings with Android Studio. I hacked the application resources but stopped when I understood that I would have to generate platfom dependacies (for instance SettingsLib.jar)
My second trial is to generate the entire Android platform. The build is complete and I can deploy TvSettings application on a x86 TV simulation BUT when I launched the TvSettings appplication I get this error :
--------- beginning of crash
2019-04-01 12:21:04.976 3987-3987/com.android.tv.settings
E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.android.tv.settings, PID: 3987
java.lang.RuntimeException: Unable to get provider android.support.v4.content.FileProvider:
java.lang.ClassNotFoundException: Didn't find class
"android.support.v4.content.FileProvider" on path: DexPathList[[zip
file
"/data/app/com.android.tv.settings-2DkaCncwGQ874WP-kx3G4Q==/base.apk"],nativeLibraryDirectories=[/data/app/com.android.tv.settings-2DkaCncwGQ874WP-kx3G4Q==/lib/x86,
/system/lib, /vendor/lib]]
I searched this error on internet and it seems that it deals with multidex feature. This multidex feature is well documented for clean developped Android appliacation but nor reaally for applications extracted from Android platform and deployed with adb.
This problem is related to java libraries loading.
I found threads referring Android multidex feature but only for applications buils with Android Studio/Gradle and my app was build with Android platform
What can I do?
have you included fileProvider in your manifest?
Well there seems to be a root error during deployment of my TvSettings application. Here is its log :
E/dex2oat: Invalid version number in dex file header. File: base.apk
I read several pages and found this one very interesting : https://source.android.com/devices/tech/dalvik/configure
So, due to different optimizations, platform apps are not generated with the same file format that apps generated above platform API
My idea is to generate the whole platform including TvSettings app and to deploy TvSettings with adb. So the apk format may be wrong.
My next step is to add in TvSettings/Settings/Android.mk the flag below :
LOCAL_DEX_PREOPT := false
We've got a mobile application (Xamarin.Forms for iOS and Android) that we've been in the progress of migrating from our on-premise Team Foundation Server (TFS) to Visual Studio Team Services (VSTS). For the last couple of months now we've hosted our code in VSTS but have performed the builds and releases to the respective stores from our on-premise TFS. Late last week I migrated both the build and release definitions to VSTS as well, so that now we have the entire process in VSTS.
Or so I thought... For, while the iOS build and release works fine, and Android builds and releases as well, the Android application now crashes when you attempt to run it. No major (read: no) changes have taken place in the code and neither HockeyApp nor our App's own error log are able to record the reason for the crash - nor does the Google Developer Console provide us with any insight for that matter. After a couple of tries I was able to get the following exception out of a Logcat:
I/MonoDroid(21970): UNHANDLED EXCEPTION:
I/MonoDroid(21970): System.ArgumentException: element is not of type Xamarin.Forms.View
I/MonoDroid(21970): Parameter name: element
I/MonoDroid(21970): at Xamarin.Forms.Platform.Android.VisualElementRenderer`1[TElement].Xamarin.Forms.Platform.Android.IVisualElementRenderer.SetElement (Xamarin.Forms.VisualElement element) [0x0001c] in <fa196d4afd1b4356b38d6cf3bb1e4df8>:0
I/MonoDroid(21970): at Xamarin.Forms.Platform.Android.Platform.CreateRenderer (Xamarin.Forms.VisualElement element, Android.Support.V4.App.FragmentManager fragmentManager, Android.Content.Context context) [0x00031] in <fa196d4afd1b4356b38d6cf3bb1e4df8>:0
I/MonoDroid(21970): at Xamarin.Forms.Platform.Android.AppCompat.FragmentContainer.OnCreateView (Android.Views.LayoutInflater inflater, Android.Views.ViewGroup container, Android.OS.Bundle savedInstanceState) [0x0001b] in <fa196d4afd1b4356b38d6cf3bb1e4df8>:0
I/MonoDroid(21970): at Android.Support.V4.App.Fragment.n_OnCreateView_Landroid_view_LayoutInflater_Landroid_view_ViewGroup_Landroid_os_Bundle_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_inflater, System.IntPtr native_container, System.IntPtr native_savedInstanceState) [0x00020] in <20045e457c414d37bc46e447a5bb3bb5>:0
I/MonoDroid(21970): at (wrapper dynamic-method) System.Object.b09cff61-6f2e-471d-b43a-8d2949513eb7(intptr,intptr,intptr,intptr,intptr)
Now there's only one place in our code where we use fragments, which is in a custom renderer we use to extend the default implementation of the BottomBarPage we use instead of Xamarin's default TabbedPage. I therefore attempted a build with this feature turned off (using the default TabbedPage instead of a BottomBarPage and removing the ExportRenderer-attribute), but this did not solve the problem. Of course I also had a look online to see if I could match the error message with any problem anyone else might have experienced. Results seemed rather meager and not particularly applicable to my case: install the latest version of Xamarin.Forms (which we cannot do at the moment - besides things were working on our private build server) or do a clean and rebuild (I actually tried turning on the Clean-option in our Xamarin.Android-task, but to no effect).
I therefore proceeded to compare the last build log from TFS with a recent one from VSTS to see if I could find any major difference. This turned out to be rather tricky as the output between the two build definitions differs markedly. Superficially, they both look the same, though, performing the same tasks. I did notice, however, that our own Mac build server used newer versions of both MS Build and Android Build Tools than does the VSTS Hosted Mac (15.6.0.0 versus 15.4.0.0 and 27.0.1 versus 23.0.0 respectively), so I decided to change the build environment, as there seems to be no way to influence these parts of the build-environment and the highest installed version of the Android Build Tools will be used when none is explicitly specified anyway (according to https://learn.microsoft.com/en-us/xamarin/android/deploy-test/building-apps/build-process). Running on VS2017 Hosted now at least gives me Android Build Tools version 27.0.3. The JDK-version is the same on all environments, by the way.
With the switch in build-environment also not resolving the issue I next tried the following:
Turned off AOT-compilation - though a comparison of the log showed that what differed mostly were IDs and compression levels/final file sizes.
Verified that I deselected to use the shared runtime (as suggested here) and that both "armeabi" and "armeabi-v7a" architectures are selected for compilation (as proposed here).
Switched from using the Xamarin.Android build-task to using the shell-script which I had built for our on-premise TFS, as the latter's agent had lacked the Xamarin.Android-capability and the script was meant as a work-around.
Compared the list of Android resources reported by the log as included in the build, which was equal.
Compared the list of intermediate assemblies reported by both build logs as being packaged and found them to be more or less equal (with the new VSTS-build adding unfamiliar Mono.Data.Tds.dll- and System.Runtime.InteropServices.RuntimeInformation.dll-assemblies).
Performed a per-project comparison of copied files reported by the build logs - something I found of little informative value, since I considered additional assemblies & files reported by VSTS harmless, but am otherwise unable to evaluate the impact of files reported by TFS but not reported by VSTS (in other words, I'm unsure of the informative value of comparing the lists of copied files).
Verified the list of files reported by both logs as having been signed and zip-aligned (the configuration between TFS and VSTS is completely the same, therefore this task has received little attention in my investigation otherwise).
Made a build on VSTS from the same branch and commit as the last-known working one made on TFS and compared these using Android Studio's APK analysis/package comparison tool.
Only the latter - the package comparison - I've found to be informative, yet of what I do not know. That is to say, one would expect packages containing exactly the same code and resource files to have little difference among them except for maybe the version numbers in the Android-manifest. And, indeed, this is what I'm seeing for the assets and resources. However, significantly (at least in my opinion), the META-INF, lib, classes.dex, assemblies and typemap-files all differ in size. It is unclear to me what this means, though...
Now about 1.5 days in, the only promising result so far is another post here on Stack Overflow that seems to describe the same symptoms as we're experiencing, yet reports a different exception message in their logcat. No resolution has been posted, however.
Edit 1
One thing I've noticed just now when comparing the Android-manifest between builds made on TFS versus those made on VSTS is that the following metadata is lacking from the application-node when building on VSTS (yet is present in local [debug-]builds):
<meta-data
android:name="android.support.VERSION"
android:value="26.1.0" />
I'm unsure what package adds this node and what it does, however, but feel it might be significant and will be investigating this further.
Edit 2
After a long day of frustration trying all kinds of different combinations of libraries (some of which don't seem to want to install on the .NetStandard projects VS2017 creates for mobile Apps by default instead of the old PCL), I managed to narrow down where the above entry in the Android-manifest comes from: apparently this is something that the version 26.1.0 Xamarin Android support libraries add. It turns out that one of the Xamarin Android support libraries referenced in the CS-project-file of one of the three Android-projects our App uses was still pointing towards an old 26.1.0.1 version, whereas all other references had been updated to 27.0.2. Changing this entry manually ensured that entry in the Android-manifest went away. This, however, did, unfortunately, not solve our build issues with the Android-version of our App...
Edit 3
Building on a hosted VS2017 environment now results in the below exception messages:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2374):C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2374,3): Error : error XA5101: Missing Android NDK toolchains directory '\toolchains'. Please install the Android NDK. at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainDirectories(String toolchainsPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainPath(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkTool(String androidNdkPath, AndroidTargetArch arch, String tool) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolPrefix(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.Aot.<GetAotConfigs>d__73.MoveNext() at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerable.GrabChunk_Buffered(KeyValuePair`2[] destArray, Int32 requestedChunkSize, Int32& actualNumElementsGrabbed) at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerator.GrabNextChunk(Int32 requestedChunkSize) at System.Collections.Concurrent.Partitioner.DynamicPartitionEnumerator_Abstract`2.MoveNext() at System.Threading.Tasks.Parallel.<>c__DisplayClass42_0`2.<PartitionerForEachWorker>b__1() at System.Threading.Tasks.Task.InnerInvoke() at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask) at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2374):C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2374,3): Error XA3001: System.AggregateException: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> Java.Interop.Tools.Diagnostics.XamarinAndroidException: error XA5101: Missing Android NDK toolchains directory '\toolchains'. Please install the Android NDK. at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainDirectories(String toolchainsPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainPath(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkTool(String androidNdkPath, AndroidTargetArch arch, String tool) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolPrefix(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.Aot.<GetAotConfigs>d__73.MoveNext() at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerable.GrabChunk_Buffered(KeyValuePair`2[] destArray, Int32 requestedChunkSize, Int32& actualNumElementsGrabbed) at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerator.GrabNextChunk(Int32 requestedChunkSize) at System.Collections.Concurrent.Partitioner.DynamicPartitionEnumerator_Abstract`2.MoveNext() at System.Threading.Tasks.Parallel.<>c__DisplayClass42_0`2.<PartitionerForEachWorker>b__1() at System.Threading.Tasks.Task.InnerInvoke() at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask) at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object ) --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken) at System.Threading.Tasks.Task.Wait() at System.Threading.Tasks.Parallel.PartitionerForEachWorker[TSource,TLocal](Partitioner`1 source, ParallelOptions parallelOptions, Action`1 simpleBody, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally) at System.Threading.Tasks.Parallel.ForEachWorker[TSource,TLocal](IEnumerable`1 source, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally) at System.Threading.Tasks.Parallel.ForEach[TSource](IEnumerable`1 source, ParallelOptions parallelOptions, Action`1 body) at Xamarin.Android.Tasks.Aot.RunParallelAotCompiler(List`1 nativeLibs) at Xamarin.Android.Tasks.Aot.<>c__DisplayClass71_0.<DoExecute>b__0() at System.Threading.Tasks.Task`1.InnerInvoke() at System.Threading.Tasks.Task.Execute() --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification) at System.Threading.Tasks.Task`1.get_Result() at Xamarin.Android.Tasks.Aot.DoExecute() at Xamarin.Android.Tasks.Aot.Execute() ---> (Inner Exception #0) System.AggregateException: One or more errors occurred. ---> Java.Interop.Tools.Diagnostics.XamarinAndroidException: error XA5101: Missing Android NDK toolchains directory '\toolchains'. Please install the Android NDK. at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainDirectories(String toolchainsPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainPath(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkTool(String androidNdkPath, AndroidTargetArch arch, String tool) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolPrefix(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.Aot.<GetAotConfigs>d__73.MoveNext() at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerable.GrabChunk_Buffered(KeyValuePair`2[] destArray, Int32 requestedChunkSize, Int32& actualNumElementsGrabbed) at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerator.GrabNextChunk(Int32 requestedChunkSize) at System.Collections.Concurrent.Partitioner.DynamicPartitionEnumerator_Abstract`2.MoveNext() at System.Threading.Tasks.Parallel.<>c__DisplayClass42_0`2.<PartitionerForEachWorker>b__1() at System.Threading.Tasks.Task.InnerInvoke() at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask) at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object ) --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken) at System.Threading.Tasks.Task.Wait() at System.Threading.Tasks.Parallel.PartitionerForEachWorker[TSource,TLocal](Partitioner`1 source, ParallelOptions parallelOptions, Action`1 simpleBody, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally) at System.Threading.Tasks.Parallel.ForEachWorker[TSource,TLocal](IEnumerable`1 source, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Action`3 bodyWithStateAndIndex, Func`4 bodyWithStateAndLocal, Func`5 bodyWithEverything, Func`1 localInit, Action`1 localFinally) at System.Threading.Tasks.Parallel.ForEach[TSource](IEnumerable`1 source, ParallelOptions parallelOptions, Action`1 body) at Xamarin.Android.Tasks.Aot.RunParallelAotCompiler(List`1 nativeLibs) at Xamarin.Android.Tasks.Aot.<>c__DisplayClass71_0.<DoExecute>b__0() at System.Threading.Tasks.Task`1.InnerInvoke() at System.Threading.Tasks.Task.Execute() ---> (Inner Exception #0) Java.Interop.Tools.Diagnostics.XamarinAndroidException: error XA5101: Missing Android NDK toolchains directory '\toolchains'. Please install the Android NDK. at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainDirectories(String toolchainsPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolchainPath(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.NdkUtil.GetNdkTool(String androidNdkPath, AndroidTargetArch arch, String tool) at Xamarin.Android.Tasks.NdkUtil.GetNdkToolPrefix(String androidNdkPath, AndroidTargetArch arch) at Xamarin.Android.Tasks.Aot.<GetAotConfigs>d__73.MoveNext() at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerable.GrabChunk_Buffered(KeyValuePair`2[] destArray, Int32 requestedChunkSize, Int32& actualNumElementsGrabbed) at System.Collections.Concurrent.Partitioner.DynamicPartitionerForIEnumerable`1.InternalPartitionEnumerator.GrabNextChunk(Int32 requestedChunkSize) at System.Collections.Concurrent.Partitioner.DynamicPartitionEnumerator_Abstract`2.MoveNext() at System.Threading.Tasks.Parallel.<>c__DisplayClass42_0`2.<PartitionerForEachWorker>b__1() at System.Threading.Tasks.Task.InnerInvoke() at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask) at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )<--- <---
Process 'msbuild.exe' exited with code '1'.
I'm not - as far as I'm aware - using the Android NDK, so I don't quite understand why I'm getting this exception message now. However, the VSTS hosted Mac environment doesn't seem to experience these problems (yet), so I'm switching back to building on Mac.
Edit 4
Did some searching, and apparently the above exception messages are due to problems with the automated update of Visual Studio from version 15.6 to version 15.7, which recently took place (source). Always nice to see these things being checked global roll-out.
Edit 5
So here are some further things I've tried since the last update: explicitly setting the JDK-version used by Xamarin.Android to version 8 and the JDK Architecture to x64 (as described here); and removing all custom renderers for Android, since the original exception seems to point at the VisualElementRenderer<TElement>, which is the base class for almost all (if not all) default and custom renderers. All of this to no avail, however, so that I suspect the exception thrown derives from within Xamarin.Forms itself.
Edit 6
We finally tried adding the Mac we use for our internal build flow in TFS as a private build agent to VSTS today, which was a surprisingly easy thing to do! We didn't even need to change our firewall configuration, as it seems that the agent makes connection with the server (across HTTP and HTTPS), not the other way around (we followed the steps described here). I would that all installations were this easy!
Notwithstanding the ease with which we configured our private build agent, we still experienced the same crash following builds, irrespective of whether we built with the Xamarin.Android build-task or our custom build script (which we had previously used on the very same machine from within TFS with success).
We did eventually bump into the solution by following up on a suggestion made here, however, something that seemed somewhat unrelated and not pertinent before. Yet, as I had coincidentally just updated the version of our Xamarin.Forms from version 2.5.1.444934 to version 2.5.1.527436 the day before, I decided to try running a build with this code. Which turned out to work! I've got no clue why though... But I guess that's less relevant than being able to build again!
As it turns out, updating Xamarin.Forms is the solution.
Though suggested as resolution to the same error as ours on the Xamarin forums, and something I had come across before, the age of the post and the old version of Xamarin.Forms involved made me disregard this option as less relevant to our problem. What didn't help either was that I thought we were already on the highest version of Xamarin.Forms 2.5.1, and are not quite ready to move to Xamarin.Forms 3.0 yet. Yesterday, however, I discovered there was still a revision we could upgrade within the 2.5.1-branch, which is what I did. When I then tried a build with this code, surprisingly the resulting APK turned out to run without any issue!
The reason why updating Xamarin.Forms works is unclear to us, though. We did, however, observe that this particular version of Xamarin.Forms, 2.5.1.527436, was released just about a week before I migrated our build definition from TFS to VSTS. It might therefore be that there's some correlation there.
Edit 1
Ran into some trouble with Xamarin.Forms 2.5.1.527436 today, which has eventually led me to the most likely cause for our problems creating an Android build of our App. That is, in order to resolve a crash caused by Xamarin.Forms, I tried to revert Forms to the last version I knew still worked. However, the problem with Xamarin.Forms persisted, even after the downgrade. This triggered me to inspect the project-files and compare the working version of the App to that which had been downgraded, yet should have ended up the same notwithstanding.
As it turns out some project files had references to two different versions of Xamarin.Forms: the one that I had intended to use, and the one we had been using before that. Now this mixture didn't cause any problems while running on a local development machine, since this machine would have both old and new versions of Xamarin.Forms installed and there would therefore not be any missing assemblies. However, I can imagine that this would not be the case when running a VSTS-build on a build-server. Moreover, the project files containing the incorrect assembly references were both Android projects - which explains why iOS had no trouble building...!
Upgrading to ndk 8b I receiving some crash report (most of them are Galaxy SII with Android 4.03)
java.lang.UnsatisfiedLinkError: Cannot load library: reloc_library[1286]: 1836 cannot locate '__gnu_thumb1_case_uqi'...
at java.lang.Runtime.loadLibrary(Runtime.java:370)
at java.lang.System.loadLibrary(System.java:535)
at com.iuculano.fplayer.SDLActivity.void onCreate(android.os.Bundle)(SourceFile:324)
at android.app.Activity.performCreate(Activity.java:4465)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1052)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1932)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1993)
at android.app.ActivityThread.access$600(ActivityThread.java:127)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1159)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4507)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:790)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:557)
at dalvik.system.NativeStart.main(Native Method)
The exception is caused by a simple System.loadLibrary("main");
What does it mean? cannot locate '__gnu_thumb1_case_uqi'
The __gnu_thumb1_case_uqi is a helper which does an indexed jump on a densely packed switch table; quickly implements the switch. You have two options: avoid it or link with it.
If you increase an optimization level (by using -O3) you might not need this symbol. Also, changing the CPU may help as well as using thumb2 instructions. Compiling with the -ffreestanding option may also avoid this symbol. If you have control over the switch statement, you can replace it with an array of function pointers.
This routine is inside libgcc. You can statically link libgcc. Somewhere in the Android SDK/compiler, there must be a libgcc.a. Link with libgcc.a, using -L and -l or use -static-libgcc linker option to get the code (see http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html).
Edit: If you aren't compiling anything, then you can find libgcc.so on your system. It might be in /lib or /usr/lib or perhaps some place weird for Android devices. Adding the directory where the libgcc.so is located to the environment variable LD_LIBRARY_PATH could also fix the problem. It maybe unfortunate that Samsung released incompatible binaries and you have no way to fix the issue if you aren't compiling your own code. The correct libgcc.so maybe inside something like /usr/lib/thumb for multi-lib distributions. I don't know much about the Davlik stuff, but the Android JVM might not pointing to the right set of libraries when it runs.
Are you compiling for armv7? If you're not, try compiling for armv7.
Producing optimised NDK code for multiple architectures?
read about 'arm' vs 'thumb' in the accepted answer in the above link.
then, remove your config instructions to build for thumb and verify that you are building for arm...
OR...
ill make a wild guess ... its the library order you have in the linker statement in your 'Android.mk'
try the google forum for ndk ... searching for 'cannot locate symbol'...
Really desperate?
see 'Runtime errors' section here
Iam trying to run draw9patch tool from android sdk(ver.10), and it gives me exception with error trace like this:
sh ./draw9patch
Exception in thread "AWT-EventQueue-0" java.awt.HeadlessException
at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:173)
at java.awt.Window.<init>(Window.java:437)
at java.awt.Frame.<init>(Frame.java:419)
at javax.swing.JFrame.<init>(JFrame.java:218)
at com.android.draw9patch.ui.MainFrame.<init>(MainFrame.java:44)
at com.android.draw9patch.Application$1.run(Application.java:48)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:226)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:647)
at java.awt.EventQueue.access$000(EventQueue.java:96)
at java.awt.EventQueue$1.run(EventQueue.java:608)
at java.awt.EventQueue$1.run(EventQueue.java:606)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:105)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:617)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)
Ok, problem solved.
I removed OpenJDK, and installed oracle jdk, and now everything works fine.
This means that either your computer is running no X or similar or that it can not connect to the X server (e.g. because you are logged in from a remote via ssh without X forwarding).
If you are running X, it may mean that some library path is messed up and the java executable is not able to find some libX* libraries.