Develop Reference

Limitation on Ne10 ARM library maximum length fft

I'm computing the Fourier transform of a 2^18 samples vector using the FFT included in Ne10 ARM library and it doesn't seem to work. It produces a Sigsev error on the Android Studio. The funny thing is that a 512 samples FFT works well. My questions are:
Is there a limitation on the maximum amount of samples I can compute the fft on with this library?:
I'm using:
fftPlan = ne10_fft_alloc_c2c_float32_neon(fftSize);
fftIn = (ne10_fft_cpx_float32_t*)NE10_MALLOC (fftSize * sizeof (ne10_fft_cpx_float32_t));
fftOut = (ne10_fft_cpx_float32_t*)NE10_MALLOC (fftSize * sizeof (ne10_fft_cpx_float32_t));
Are these memory allocating functions thread safe? (I've tested and they seem to)
Leaving out their own FFT benchmark comparisons. Is there any other 3rd party site where I can compare its performance with fftw?
The library produces a "text relocations warning" when I use NDK10e for building the native shared library loaded from my android app, which when using ndk13 produces the following error :
D:/AndroidDevelop/android-ndk-r13/build//../toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin\ld: warning: shared library text segment is not shareable
D:/AndroidDevelop/android-ndk-r13/build//../toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin\ld: error: treating warnings as errors clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation)

Multidex with Android 2.3 (API 9)

can anyone tell me if multi dex is supported in android 2.3?
I've searched around but i can't find information for this.
My project have the same configuration like this one: https://github.com/mustafa01ali/MultiDexTest
The project builds without problem, but the final apk can't be installed in devices with 2.3 or lower.
On installation I get the error
Failure [INSTALL_FAILED_DEXOPT]
in Android Studio and this appears in logcat:
E/dalvikvm﹕ LinearAlloc exceeded capacity (5242880), last=1384
W/installd﹕ DexInv: --- END '/data/app/xxx.apk' --- status=0x000b, process failed
E/installd﹕ dexopt failed on '/data/dalvik-cache/data#app#xxx.apk#classes.dex' res = 11

You're hitting a different size limitation (LinearAlloc), which according to this bug is not solved by multi-dex:
https://code.google.com/p/android/issues/detail?id=78035
From comment #7 in that bug:
There is already an option in dx allowing to force generation of
smaller dex files:
--set-max-idx-number= Unfortunately changing the default is not a solution since the linearAlloc limit can be reached at very
different levels depending on the classes hierarchy and other
criteria.
In addition for most applications, moving to multidex will only help
to workaround the linearalloc limit for the installation. But the
application will still crash against the same limit at execution. The
only working use case where I know multidex can help with linearalloc
is when the apk does not contains one application but distinct pieces
running in separate process.
It's not clear that there's anything you can do to work around this limit, at least in the long term; you may need to simplify your app. There's another StackOverflow question here with some information and some workarounds that may get you up and running, at least for a while:
How to avoid LinearAlloc Exceeded Capacity error android

Android Gdb gcore "command not implemented for this target"

I am using gdb for dumping core file for an android process. I am running gdbserver on the device on tcp port and gdb client on the desktop. When i do gcore on client i get the below error.
Does any one know why i'm getting this error , any help much appreciated.
(gdb) gcore
Command not implemented for this target.
The reason i'm doing this to dump process memory and extract Classes.dex file from the memory using core file. I've tried doing this using /proc/pid/mem and proc/pid/maps and dump memory but that has too many mapped regions , i couldn't find the area where the Classes.dex file is. Any other alternate approach is also welcome. Thanks for your help.

First of all, you can only dump odex from memory (because dex compiled to odex for execute). But its not a big deal to convert odex to dex using baksmali-smali.
To find odex in memory you can use gdb for checking magic number for every begin-address of mapped memory(proc/pid/maps - first column):
gdb --batch --pid "pid_task" -ex x/s "mem_start"
So, when returned value equal to "dey\n036", you can dump this memory region via gdb.
Try to begin checking memory addresses from the end of file "proc/pid/maps", it will be much faster.
PS Sorry for my english, but hope it will help.

#Chris Stratton, the memory mapped classes.dex file will be different from the dex file inside apk on disk, for example in cases of packed dex files, some part of dex will be deobfuscated, question is to dump the memory mapped classes.dex file by getting the process memory.

You can use GameGuardian for this. Need root.
Memory editor tab - menu - memory dump - input 0-0 as range and folder - press ok - wait for toast Dump end.
Go to selected folder - open maps file - search needed odex in regions - remember start address of region - open GameGuardian - menu - memory dump - input remembered address in both field as range - press ok - wait for toast Dump end.
Now you have in your folder .bin file with dumped odex file.
Also you can find address in drop down list in GameGuardian UI. Press drop down icon on right with dump range field.
Here some video examples how to do this:
How to dump odex file from memory on Android -
GameGuardian

Too many methods error

Apparently I have too many apache poi jars which return too many methods and go above the limit when I try to read and write an xlsx file. Below is the error I get
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
Is there a way around this? I don't want to delete any libraries and yet my project is not compiling. Please help.

Found the issue!
It's Apache POI's XSSF incompatibility with Android! Actually Apache is pretty okay but when Android converts your Java code into Dalvik Executable files it has a method limit of 65536 which the libraries of Apache POI when they handle XSSF exceed. Hence the error. It has nothing to do with lines. :) I had only 75 rows and 7 columns. More information on this can be found at http://mail-archives.apache.org/mod_mbox/poi-dev/201110.mbox/%3CCA+JOeWNWinmNmEtHs5VK+KEc_6BzAG_=LfpdXqsDsnjJKR2X7Q#mail.gmail.com%3E.

short answer:
just remove the unnecessary jar files. e.g. from the list you gave, I saw there are '8767' methods from org.openxmlformats.schemas.drawingml.x2006.main , if it's not necessary, just remove this jar file and you life will be easier.
Detailed answer:
On titanium official Jira , this bug is still "reopened", created 1 year ago. I don't think they are releasing a new version tomorrow. ( https://jira.appcelerator.org/browse/TIMOB-18082 )
Removing the unnecessary jar files will cause the runtime error, however, since they are unnecessary, runtime error won't occur without them.
read the comments, also refer to here: ADT: fail to build when there are too many packages and classes
and here: Can we create multi dex support builds in Titanium android?

How work with wsdl service in android contained in Azure

1).I generated Web Service Client from WSDL (use Axis2 1.5 carnel, wsdl2java,Tomcat 7.0);
2). Accessing a JAX-WS web service from Android use KSoap2-android library (I tested this lib on service http://www.webservicex.net/ConvertWeight.asmx and it works ok). But work with http://xxx.svc?wsdl I can't connect to the service. When I generated the Web Service Client from Android Progect I get this error :
"IWAB0399E Error in generating Java from WSDL: java.io.IOException: Emitter failure. There is an undefined binding (BasicHttpBinding_ICustomerService) in the WSDL document. Hint: make sure is fully qualified."
3). From Web Service Client I make service.jar, which used on Android Progect how lib, but not working.
4). When I used ksoap2 I get this error:
[2012-06-26 17:25:33 - TranscribeMe_2.2] Dx 1 error; aborting
[2012-06-26 17:25:33 - TranscribeMe_2.2] Conversion to Dalvik format failed with error 1
[2012-06-26 17:26:32 - TMP] Dx warning: Ignoring InnerClasses attribute for an anonymous inner class
(org.ksoap2.transport.KeepAliveHttpsTransportSE$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is not an inner class.
[2012-06-26 17:26:33 - TMP] Dx
trouble processing "javax/xml/ws/Dispatch.class":
Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.
[2012-06-26 17:26:33 - TMP] Dx 1 error; aborting
[2012-06-26 17:26:33 - TMP] Conversion to Dalvik format failed with error 1
Please, help me...

IF you will search StackOverFlow for Axis and WCF/WSDL issues you will find a lot without any answer or suggestion so there is not a lot you would be able to
About your following error:
There is an undefined binding (BasicHttpBinding_ICustomerService) in the WSDL document.
Hint: make sure is fully qualified."
I can say that the problem probably related with how you ICustomerService bindings are defined. As you have chosen BasicHttpBinding, please make sure all the parameters are correct . If you check your Axis generated WSDL, you will be able to verify it easily.
Also in some cases you might hit namespace issues and which could cause Axis WSDL to genatate service.svc?wsdl=wsdl0 and service.svc?wsdl=wsdl1. If that is the case, you can resolve namespace issues by adding namespace attribute for your each data contract along with message header, body and added bindingnamespace attribute in web service end point.
My first suggestion will be to create a simple C# client application and connect to your Windows Azure WCF service to and verify you could connect using BasicHttpBindings without any problem and then use Java app to do the same. If you see the problem, compare the network traffic between two to see the different which might help you to figure out the root cause and for very specific problem ask questions at SO and you will get proper help. Good Luck!!