I'm developing an android plugin for Unity that uses zxing as library.
My app crashes when at OnCreate on an Activity which extends CaptureActivity due to missing resources (R.id. stuff).
I have placed the zxing project in Plugins/Android, as for the other plugins. It finds classes (I managed to list all classes in apk and they are there, even cativities can be started), but there must be some kind of problem when creating layouts as it fails there.
If I surround onCreate with try... catch, then the scanning activity starts and works, but there are no menus, icons, buttons...
I tried creating a .jar in eclipse and then replace the entire project in Unity by it, but it doesn't work either.
I'm using facebook plugin as well, and it works properly. The project structure is as usual: project placed in Plugins\Android and that's all.
Why is facebook project working fine and mine not? I can't understand.
I already solved other problems by reimporting the stuff, and some months ago I managed to make zxing work in another project, but now I can't (maybe updates have something to do)
For now my only option is to get resources by name: getResources().getIdentifier(name, defType, defPackage). It would work, despite of the lot of work, as I'm not going to modify anything else in ZXing, but not the best option, and definitively not a general solution to work with plugins.
Any help, or documentation in deep unity android plugins stuff is welcome.
PS: I added sources to unity plugins folder, so I can edit with Eclipse with no need to compile, copy and all that stuff. I can't do that for ZXing as unity creates a bunch of .meta files that makes R generation fail (files can be ignored applying patterns in code folders, but R generation is done by a different processor and I was not able to set any filter), so I have to copy the project from eclipse to unity when modified.
Related
I have a native Windows library I'd like to include as part of Windows build/package in my MAUI app. Is there a way to do this where it won't be included in the builds/packages of the other platforms?
I found a way to do this with Android native libraries: I simply place them in (ProjectDir)\Resources\lib\(Architecture), where (Architecture) is, for example, 'arm64-v8a'. Then I can simply flag them in the .csproj file as an AndroidNativeLibrary and all's well; they show up in my Android build and don't appear in any of the other builds (Windows, IOS, etc.).
Things I've tried:
Manually copying the Windows native lib (a DLL) to the generated AppX folder via a postbuild script. Not ideal. For one, the AppX folder isn't technically generated until after the build is finished; it's part of a packaging step (I believe). So, this kind of works, but isn't really the proper solution. I want the DLL to automatically be included by the packager.
Adding the DLL as an item to the .csproj. This means it gets automatically included in the AppX package, but is still not ideal as it subsequently winds up in every platform's build.
The most promising: referenced the DLL via a 'file' element in (ProjectDir)\Platforms\Windows\app.manifest. However, it doesn't seem like this manifest file plays any role in the build/packaging. Rather Package.appxmanifest seems to be the file that matters. If I throw intentional typos into app.manifest, building and packaging still succeed. I also added app.manifest to the csproj explicitly via ; it doesn't seem to care.
Anyway, any ideas/insight would be much appreciated.
Ok, I found a fantastic article that solves my problem: https://learn.microsoft.com/en-us/xamarin/cross-platform/cpp/
Not sure how I didn’t find this before; I was looking forever.
I am using Visual Studio and I have followed the previous answers to this question where I just need to add the reference in my Solution Explorer. I have already done it but in my Unity3d, it still says The type or namespace name 'Forms' does not exist in the namespace 'System.Windows' (are you missing an assembly reference?)
Is there another way to fix this?
Unity will add project references to its known libraries, or those that you manually add to the Plugins folder. But even then, the known libraries are often stubs, and the manually added plugins need to be compatible. Unlike standard VS project, it won't pick up all of the libraries you have on your local machine.
To illustrate the point, if you want to use System.Text.Json, you need to manually download that dll and all the dependancies, and add those to the Plugins folder. After that you will then have access to the System.Text.Json namespace. So, in some cases it can be done.
What you shouldn't ever be doing with a Unity project, is to try and add your own references through Visual Studio to the project yourself. Unity is in control of your Solution and Project files, and will overwrite your references as it needs to.
That part explains why you aren't able to add System.Windows.Forms to you project through Visual Studio. Now comes the point where we ask why you would even try and add that to a Unity project. Unity has its own GUI systems (in my opinion, the better, although still green around the gills, being UI Toolkit). You CAN drive native Windows features from within Unity, but that's another question altogether. When using Unity, it's simplest to work within the bounds of the engine.
I have a mature app that needs to have an SDK brought in that wraps the camera and makes it do some spiffy processing while it's running. The SDK has come to me in the form of some aar files but my app still lives in Eclipse. Because of my massive, steaming pile of a branding structure and deadlines for this integration the uncertain timeline required to fully migrate to Android Studio will not work (for now) so I'm going for converting the aars and using them in my app via Eclipse.
The problem I'm having is that I need to kick off the activity in the library but even though I fixed up all my build time reference problems, when running the app once I get to the point that is supposed to kick off the activity I get this error.
I've read through and double checked dozens of how-tos explaining how to consume the aar files and I think I've followed every step including:
Unzip the aar files and dress them up as individual library projects, including the file structure with the resources, the manifest, and the .jar
Make the project that needs the libraries add them as such
Add the .jars contained in the library projects to the build path (this step was not listed in most articles, and wasn't necessary for the project to build, but nevertheless it did not help my problem)
Declare the activity in your AndroidManifest.xml that the library brings in and declares in its AndroidManifest.xml
As I've said, everything looks good at build time, so I'm not sure what else to check. Because I'm reading that Gradle and Android Studio mashes manifests together really well, I have a hunch that it's something I'm supposed to regulate between the manifests but I don't know what it could be if that is it. I've wondered if I'm declaring the 3rd party's activity properly, but I'm not sure how to test it because the only way I can think to test it is to provide gibberish for the namespace but even then there are no complaints. I've also tried dissecting the .apk to look at the .dex file but I could not decipher anything useful.
My guess is that the library may not be building properly in eclipse - even before it's being added as a dependency to the application project.
Try looking at out/classes/* and making sure you have a .class file for the activity in question. I think the .class should actually be in the library as well as end up in the application project's out/ dir also.
If there are any native files (x.so) (as I would imagine there might be for spiffy camera stuff), you can look for the x.so files being included in the out/ dirs of both the library and application projects as well as the library.jar file.
Another option to maybe consider for this use case: https://github.com/ksoichiro/gradle-eclipse-aar-plugin
It seems that our app had a bad version of the appcompat-v7 support library. The .jars in it were different sizes than the one that comes with the SDK and several resources were missing. I have no idea how we ended up that way or where this bad version came from. Once I replaced it, things went great.
Later, I did encounter the need to drop in the .so files into the libraries I made that came out of the .aar files as Stad Kurdziel said in his answer, but that was causing a different error (the exception explicitly states that the .so is missing) and I arrived at the solution independently.
I've been playing with a Java's Magento connector called magja (https://github.com/magja/magja) in a 'normal' Java project. And everything were working fine till this point.
After that, I started a simple Android application that would use the magja code to consume such information from Magento.
The question is: how should I configure the my Android project to deal with a 'normal' Java project (not a library)? This another project uses several xml files to configuration and Maven to deal with dependencies. How this impacts my Android App?
Thanks a lot!
EDITED
Actualy, I've already tried this approach (Android project unable to reference other project in eclipse), but always when the app tries to run the 'project B' (magja) code, it causes a
java.lang.NoClassDefFoundError: org.apache.commons.httpclient.params.HttpConnectionManagerParams
I believe it's related to some .jar files that magja uses. It looks like that I would solve the problem if I could share such library between the projects.
I've been working on getting unit testing to work with a custom Android library. I've followed the first suggestion from this Android developer guide and created an Android app project that depends on the library (via Properties->Android->Library->Add...) as liaison to the actual testing project.
All seemed to work fine, but then I encountered my first run-time-exception in one of my test cases. When I wanted to fix the code in my library, I found, that double-clicking any item in the JUnit test panel would open a .class file, instead of the corresponding .java file. So editing the code is not possible, until I've crawled though the package hierarchy and grabbed the .java file manually.
Also, the debugger/test-runner is happily ignoring any breakpoints in the library. Is there a way to make the test project realize, that the code for the library is right there in the workspace? Not having the abilities to debug using breakpoints and jumping from a stack trace into the code are big productivity bummers.
Addendum: After leaving Eclipse and starting another session, now breakpoints seem to be respected. However, the debug-perspective will open the .class files instead of the corresponding .java files.