Develop Reference

What is the exact meaning of "Too many field references" in Android?

I can check the classes.dex file through analyze apk in Android studio.
For example.
This dex file defines 9214 clasees with 48592 methods, and references 57284 methods.
If the build fails because of a dex error, I will see the following error message.
Too many field references: 70000; max is 65536.
You may try using --multi-dex option.
What exactly does 70000 mean in this error message?
Number of defined method? or Number of referenced Methods?
If the answer is a number of methods, is it possible to do the following result?
This dex file defines 9214 clasees with 60000 methods, and references 70000 methods.
I've already read sentence below.
The Dalvik Executable specification limits the total number of methods that can be referenced within a single DEX file to 65,536
(from Document)
But I don't know exactly what 65536 means.
Please tell me the answer. THX :)

You have to enable multidex for your application.
Refer: https://developer.android.com/studio/build/multidex
Guide: How to enable multidexing with the new Android Multidex support library
What exactly does 70000 mean in this error message?
Ans: Total methods count in your apk(includes methods count from libraries also).

Any library to read mdict *.MDX files in android?

I have a .mdx file that infact is a dictionary database (some android apps like bluedict can read its data).
I have used Daemon.tools but it could not open it.
I was looking for any library or sources which helps me to read MDX dictionary files in Java, I have found some resources already such as KnIfER/mdict-java but it does not work in Android Studio (it has errors on accumulation_blockId_tree.xxing(new myCpr(position,1)).getKey().value line and it is connot resolve symbol 'value'). Does any one knows a good source about these files and possible libraries which could be used for it?.

Well, actually this is my java project.
the error mentioned is just a problem of jdk version. you can add <> parentheses after myCpr and convert return of xxing to type myCpr<Integer,Integer> .
But now, I have very much reduced usage of rbtree and use more binary list searching.have a look there.

"trouble writing output: Too many field references: 70185; max is 65536. You may try using --multi-dex option." when building Android project

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.

ERROR: '__NDK_FPABI__' does not name a type

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!

Reading MS Excel 2010 files in android using Apache POI

I am using Apache POI in my android application to read xlsx file stored in SDCARD.
I am using following jar libs from Apache POI
poi-ooxml-schemas-3.9-20121203.jar
poi-ooxml-3.9-20121203.jar
But when I try to Run Android App I am getting below mentioned stacktrace.
trouble writing output: Too many methods: 66024; max is 65536. By package:
13 java.lang
1 java.lang.reflect
5 java.util
1 javax.xml.namespace
66 org.apache.xmlbeans
19 org.apache.xmlbeans.impl.values
1 org.apache.xmlbeans.impl.xb.xmlschema
2500 org.openxmlformats.schemas.drawingml.x2006.chart
1430 org.openxmlformats.schemas.drawingml.x2006.chart.impl
8767 org.openxmlformats.schemas.drawingml.x2006.main
5258 org.openxmlformats.schemas.drawingml.x2006.main.impl
86 org.openxmlformats.schemas.drawingml.x2006.picture
33 org.openxmlformats.schemas.drawingml.x2006.picture.impl
745 org.openxmlformats.schemas.drawingml.x2006.spreadsheetDrawing
417 org.openxmlformats.schemas.drawingml.x2006.spreadsheetDrawing.impl
230 org.openxmlformats.schemas.drawingml.x2006.wordprocessingDrawing
164 org.openxmlformats.schemas.drawingml.x2006.wordprocessingDrawing.impl
298 org.openxmlformats.schemas.officeDocument.x2006.customProperties
256 org.openxmlformats.schemas.officeDocument.x2006.customProperties.impl
617 org.openxmlformats.schemas.officeDocument.x2006.docPropsVTypes
596 org.openxmlformats.schemas.officeDocument.x2006.docPropsVTypes.impl
285 org.openxmlformats.schemas.officeDocument.x2006.extendedProperties
196 org.openxmlformats.schemas.officeDocument.x2006.extendedProperties.impl
23 org.openxmlformats.schemas.officeDocument.x2006.math
24 org.openxmlformats.schemas.officeDocument.x2006.relationships
2 org.openxmlformats.schemas.officeDocument.x2006.relationships.impl
2076 org.openxmlformats.schemas.presentationml.x2006.main
1224 org.openxmlformats.schemas.presentationml.x2006.main.impl
1 org.openxmlformats.schemas.schemaLibrary.x2006.main
7271 org.openxmlformats.schemas.spreadsheetml.x2006.main
4556 org.openxmlformats.schemas.spreadsheetml.x2006.main.impl
11448 org.openxmlformats.schemas.wordprocessingml.x2006.main
9217 org.openxmlformats.schemas.wordprocessingml.x2006.main.impl
4 schemaorg_apache_xmlbeans.system.sE130CAA0A01A7CDE5A2B4FEB8B311707
1170 schemasMicrosoftComOfficeExcel
1223 schemasMicrosoftComOfficeExcel.impl
285 schemasMicrosoftComOfficeOffice
124 schemasMicrosoftComOfficeOffice.impl
2 schemasMicrosoftComOfficePowerpoint
3 schemasMicrosoftComOfficeWord
2858 schemasMicrosoftComVml
2529 schemasMicrosoftComVml.impl
[2013-11-25 21:20:32 - CRD] Conversion to Dalvik format failed with error 2
Can anyone tell where am I missing?

If you use too much code for any android app, the compilation will throw this error. The similar problem is stated and resolved here. You should split the app in parts as a plugin, in the form of a separate APK available for download. That APK would expose some component that the main app would use. There are various app on google play of such kind.

Please note that there are a number of problems when using Apache POI on Android. The one you are hitting can be solved by the so called "multiDex" feature in newer versions of Android.
There are currently two projects which try to solve most of the problems for you:
https://github.com/andruhon/android5xlsx
https://github.com/centic9/poi-on-android/ (mainted by me)
The first one is currently based on POI 3.12, whereas the second can be re-compiled with newer versions of POI more easily.