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.
Related
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 use AndroidJniBitmapOperations library.
But I'm a Junior Dev, with no knowledge in the NDK, JNI world.
I succeed to resolve a few errors like 'UnsatisfiedLinkError', but Now I'm getting a new one when I trying to build:
error: undefined reference to 'AndroidBitmap_unlockPixels'
Also I get a few errors inside the CPP file:
1."Incorrect type for parameter 'prarmeterName', which should have type 'jint'.
2."Add extern 'C'"
But I don't sure if the last 2 are important.
Help me to update this library, because its important and talked in SO several times, like: here.
The link for the library it self:
https://github.com/AndroidDeveloperLB/AndroidJniBitmapOperations
All what I have done until now is:
https://github.com/LiorA1/MyRevApp
You need to link the library that provides that API. In https://github.com/LiorA1/MyRevApp/blob/master/app/src/main/cpp/CMakeLists.txt, copy the code that you have for the logging library like so:
find_library(log-lib log)
find_library(jnigraphics-lib jnigraphics)
target_link_libraries(JniBitmapOperationsLibrary ${log-lib} ${jnigraphics-lib})
Although I think the template code is actually overly complicated here and you can simplify to just:
target_link_libraries(JniBitmapOperationsLibrary -llog -ljnigraphics)
Untested though.
As for how you can figure out which library you need to use for each Android API, I find the easiest way is to search for it on cs.android.com. For this one, I searched for AndroidBitmap_unlockPixels file:.*\.map\.txt (every NDK API is enumerated in a *.map.txt file). You can also use this page, but the code search is authoritative and makes it easier to look up an individual function rather than just "bitmap", in this case.
I have .docx file in assets folder and use this part of code to to read it
AssetManager am = context.getAssets();
InputStream is;
is = (InputStream) am.open("amaretti.docx");
XWPFDocument hdoc=new XWPFDocument(OPCPackage.open(is));
and jars for this are:
poi.jar
poi-ooxml.jar
But shows me an error:
08-27 18:16:31.660: I/dalvikvm(23221): Could not find method org.openxmlformats.schemas.wordprocessingml.x2006.main.CTDocument1$Factory.newInstance, referenced from method org.apache.poi.xwpf.usermodel.XWPFDocument.onDocumentCreate
I guess some jar or classes are missing.
Any suggestion would be useful.
Thanks in advance
You're missing some jars. In order to read Word 2007 files using POI you also need the following libraries (they're all available in the archive you download from the official Apache POI site):
poi-ooxml-schemas (the one you're getting the error about)
xmlbeans
dom4j
stax
According to the official website, dom4j and stax are no longer needed but I found I had problems when I didn't add them.
Unfortunately, you're bound to discover that adding all of these libraries will result in a Dalvik dex error (an Android classes.dex can hold up to 64k of method declarations, which you will cross). The "official" explanation for this is that POI is simply not designed for Android. Unfortunately I have not been able to find an easy, manageable solution for that problem (there have been attempts, some partially successful, of porting POI to Android, but they're too cumbersome for my taste). I solved that problem by sending the Word 2007 files to a remote server, converted them to the old format and returned to the mobile device to be opened by POI.
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!