I'm building a c project in Eclipse-android and get the following error:
This is a ndk build error (independent to my code)
/Users/eladb/MyWorkspace/android-ndk-r8e/build/gmsl/__gmsl:512: *** non-numeric second argument to 'wordlist' function: ''. Stop.
tried
android-ndk-r8b
android-ndk-r8e
how can I fix this?
This is a known problem due to the r8d NDK not picking up properly the android:minSdkVersion property from the AndroidManifest.xml.
To work around that issue change the line 512 of the file /android-ndk-r8d/build/gmsl/__gmsl to:
int_encode = $(__gmsl_tr1)$(wordlist 1,$(words $1),$(__gmsl_input_int))
In your AndroidManifest, add the following line:
<uses-sdk android:minSdkVersion="3" />
This fixed the problem for me. You generally get this when importing a project you downloaded, as newly generated projects don't have that kind of error.
For information, this issue is also reproductible from the command-line.
Looks like the XML parsing code in ndk-build is sensitive to whitespace (as of r8e.) I was getting this error when I had the following line in my manifest:
<uses-sdk android:minSdkVersion ="10" android:targetSdkVersion="11" />
The problem went away when I replaced it with the following line, removing the whitespace between minSdkVersion and the = sign:
<uses-sdk android:minSdkVersion="10" android:targetSdkVersion="11" />
Ugh.
It's debatable whether you should patch the ndk (as described in the accepted answer) or do a workaround on the application side. I chose the workaround, as I work on a team with several different environments where we need to build, including a shared CI server, and I didn't want to go around patching the ndk for each environment and for each new developer. If you work solo, the accepted answer may be more appropriate as it will be fixed for your future projects as well.
Try to change your file carriage control (\r\n) to linux format (\n)
To fix this, I edited the file in vi and did a "set filetype=unix"
just got into the same issue
"....android-ndk-r12b/build/gmsl/__gmsl:512: *** non-numeric second argument to `wordlist' function: '18e'. Stop."
if you get this 18e, the e can be anything this is because that in the Application.mk you added a letter to the APP_PLATFORM
"APP_PLATFORM := android-18e"
and it should be
"APP_PLATFORM := android-18"
with no letter in the end, this solve the misstype which by the way i don't know when and how it has been added as i didn't open this file for weeks now, STRANGE !
Update your NDK to r15b or latter. For me its work.
Related
Strange problem with Manifest Merger, Visual Studio Mac, Xamarin Forms (5.0.0.2125), Android project, SDK 29 to 30. Problem initiated from an extra ">" in the Properties/AndroidManifest.xml file. That generated the error below, indicating the xml structure wasn't closed; line 35, column 11 being was the last line and character of the Properties/AndroidManifest.xml.
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(3,3): Error AMM0000: Error: org.xml.sax.SAXParseException; lineNumber: 35; columnNumber: 11; XML document structures must start and end within the same entity. (AMM0000)
So, I edited out the extra character, and the obj/debug/AndroidManifest.xml is created and looks right, however, the build error remains the same!
Subsequent complete rewrites and edits of the Properties/AndroidManifest.xml file have only 2 outcomes
Entering an erroneous xml format will generate the appropriate errors describing the error.
Entering a correct xml format, with any combination of entries, lines and characters will generate a correct obj/debug/AndroidManifest.xml file with the the correct Properties/AndroidManifest.xml content. However, the original build errors stay, with the " line 35, column 11 being was the last line and character of the Properties/AndroidManifest.xml." error.
So, something cached, somewhere, but no clue where. Started during an aborted simulator build and has been here ever since.
Have tried quite few things including:
cleaning, rebuilding and many combinations
remove obj and bin
removing/adding declarations in the AndroidManifest.xml
using different AndroidManifest.xml files
deleting AndroidManifest.xml and running
restoring from cloud a different version of solutions
commenting out Activity declaration on MainActivity
reinstall of VS for Mac
I think it is similar to this bug
Xamarin android Manifest being replaced on build. only solution seems to be to repair visual studio
Has anyone seen this type of bug before?
Help much appreciated as have run out of ideas here.
AndroidManifest.xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="17" android:versionName="1.17" package="com.mycompany.myapp">
<uses-sdk android:minSdkVersion="29" android:targetSdkVersion="30" />
<application android:label="myapp" android:icon="#mipmap/ic_launcher" android:supportsRtl="true"></application>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
</manifest>
Solved here, github.com/xamarin/xamarin-android/issues/6385. Was a problem in a Nuget Firebase library AndroidManifest.xml file. Unfortunately the error reporting in VS Mac Manifest merging doesn't report which of the 140+ AndroidManifest.xml files has the problem. However, with a bit of sleuthing, there is a way to eventually work it out.
I have downloaded a sample project from here: https://learn.microsoft.com/it-it/samples/xamarin/xamarin-forms-samples/webservices-azurenotificationhub/
In the building I got the error:
Failed to create JavaTypeInfo for class: Android.Support.V4.View.Accessibility.AccessibilityManagerCompat/IAccessibilityStateChangeListenerImplementor due to MAX_PATH: System.IO.DirectoryNotFoundException:
I use Visual Studio 2019.
Thank you in advance,
Piero Sbressa
So this is definitely related to the MAX_PATH problem on Windows. This is a long dicussion about this here . Hopefully according to microsoft support team they are planing solve this issue and removing MAX_PATH as limit.
I would suggest to move your project to a "shorter" path.
I did not found an alternative. You can follow the discussion, hopefully they fix this issue.
I got the same exception, when I built the mobile application first. Error code was XA4209 and suggested to: The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
After I changed the number of characters in the path, everything worked fine.
you can do a number of things ,
best to move the directory closer to root say your drive name is C the closer to "c:" the shorter the path the less likely this error will appear.
you could change the output path to be in a folder with shorter path , u find that in android project properties > build > output path
you can also change one of the parent folders name to be shorter , in my case i had a path 261 character long, i litteraly deleted one letter in a parent folder and fixed the issue.
I'm trying to help out a friend of mine by compiling a ROM for the Samsung Galaxy Grand 2 (ms013g).
make: *** No rule to make target
'/home/quiche/cmsource/out/host/linux-x86/bin/dtbToolCM' needed by
'/home/quic/out/target/product/ms013g/dt.img '.
I keep getting this error i cannot fix, i tried the fix described here: CM12 build failed for oneplus one
and i also made sure android_device_qcom_common is in my local_manifest.xml.
Somewere else, someone suggested changing dtbToolCM to dtbTool, which i tried to no avail.
Seems like You need to add suitable kernel project to your local manifest
Downloading of android_kernel_samsung_klte project helped to me (I was building device_samsung_klte)
Please try this to add below to your Device.mk
BOARD_KERNEL_SEPARATED_DT :=true
Please see Android.mk for dtbtool.
Thank you.
I hit this error and found no hits for the error message, so I thought I'd share the solution I came up with to save anyone else facing the problem repeating my work.
When writing a new Android library (apklib) for use in a (large) application, I'm getting the following error during dexing when I add my new project as a dependency:
trouble writing output: Too many field references: 70185; max is 65536.
You may try using --multi-dex option.
References by package:
<...long list of packages with field counts elided...>
The particular build step it fails on is:
java -jar $ANDROID_SDK/build-tools/19.0.3/lib/dx.jar --dex \
--output=$PROJECT_HOME/target/classes.dex \
<... long list of apklib and jar dependencies elided ...>
Using --multi-dex as recommended by the error message might be a solution, but I'm not the owner of the application project and it already has a large complex build process that I would hesitate to change regardless.
I can reproduce this problem with a no-op test library project that has literally no fields, but in the error output it's listed as having 6000+ fields. Of the packages listed in the error output, there are a handful with similar 6k+ field counts, but then the vast majority have more plausible <1k field counts.
This problem is similar to the "Too many methods" problem that Facebook famously hacked their way around. The FB solution seems insane, and the only other solutions I've found (e.g., this Android bug ticket, or this one, this SO answer, this other SO answer) all involve changing the main app's code which is well beyond the scope of what I want to do.
Is there any other solution?
The solution was to change the package in the AndroidManifest to match the main application's package.
A manifest like this:
<manifest package="com.example.testlibrary" ...
resulted in 6k+ fields and build failure. Changing it to match the main application's package
<manifest package="com.example.mainapplication" ...
resulted in the project building successfully.
Note that only the package in the manifest is changing, I did not make any changes to the library's Java source or its layout (the Java package was still com.example.testlibrary with directory structure to match).
I hypothesize that the different package name is causing all the Android fields to be included again under that package. All the packages in the error listing with 6k+ fields had a different package name than the main application.
I also (later, grr), found this blog post which details the same problem and the eventual same solution.
While compiling native code-base, I'm getting the following error -
<NDK-HOME>/platforms/android-17/arch-arm/usr/include/jni.h:235:68: error: expected ';' at end of member declaration
<NDK-HOME>/platforms/android-17/arch-arm/usr/include/jni.h:235:70: error: '\__NDK_FPABI__' does not name a type
...
With tons of repetitions.
Platform related details are as below -
Native OS: Windows 7 (64 bit) with Cygwin64
NDK Version: r9c
A similar problem has been reported here. However, even after modifying LOCAL_CFLAGS, I couldn't find the intermediate files as suggested.
Was wondering if some of you have faced this problem already and if so, do you guys have a work-around for this?
Alright, finally got rid of these __NDK_FPABI__ errors and my native code compiled just fine. Indeed, there were subtle hints in the intermediate files (*.i and *.ii) as suggested by Andrew in the link on my previous post; these are usually related to finding appropriate headers. Once relevant changes were made, things worked like a charm.
Few things I learned while debugging this issue -
The problem was related to header files. Certain headers were being picked up from /usr/include which otherwise should have been picked up from $NDK_HOME/platform/$ANDROID_VERSION/$ARCH/usr/include. Making necessary changes in the Android makefile fixed the issue for me.
Always resist the temptation of adding hot-fixes to NDK files. This will make your life a lot easier in the long run.
One should look for the intermediate files (*.i, *.ii, *s and few others) in $PROJECT_ROOT, instead of $PROJECT_ROOT/jni (assuming native code lies there).
The latest release of NDK, namely ndk-r9d fixes some of the issues with __NDK_FPABI__ related errors.
Hope this helps!