I'm researching the possibility of using Xamarin (MonoDroid) and Maqetta for building a cross-platform app. Before I ask my question I must admint to being a novice Android developer.
I'm curious to how I'm supposed to deploy the workspace I get from Maqetta on my android device. The Zip-file I download contains a very simple web project with two views in a .html file similar to this tutorial: http://www.youtube.com/watch?v=J0LneuYl280&feature=plcp
The thing is that the .zip file contains over 6500 files, but OK... It's no more than 8 MB total. I drag the entire folder structure into the Assets folder on Visual Studio. When building I get the following error:
Error 1 Invalid resource directory name: "assets". C:\Users\the\Desktop\Jobb\ImageCaptureApplication\ImageCaptureApplication\aapt.exe ImageCaptureApplication
I don't get anything else from this error.
Whats the story about this Assets folder? If I dig deep into the web workspace I got from Maqetta and remove the 'dojox' folder under "/lib/dojo/" now at least I'm able to compile and build the code, but my web page doesn't look like anything.
Is the file number too high for the Assets folder? Could it be too many levels in the directory tree from Maqetta? I understand there is a limit of 1 MB per file, but a search tells me that it doesn't look like I'm violating this rule.
It would definatly be too cumbersome to manually scan through each release of the Maqetta web project trying to filter out unnecessary dependencies..
Maqetta download size is a problem. You can select/deselect individual libraries, but the Dojo library, when included, is included in its entirety. You can edit the Dojo directory manually, as you have, or use the Dojo build script or the Dojo Web Builder (build.dojotoolkit.org) to create a smaller subset of the toolkit based on your usage. Maqetta integration with the Dojo Web Builder is a work in progress.
Was this "assets" folder part of Dojo? Did you identify where it was? The only problem I was aware of with the Android app builder is that it had a problem with underscores in filenames, but I believe that has been fixed.
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.
Background info
When uploading an app to the play store that uses a native library its necessary to also upload the native debug symbols to get useful crash/ANR info.
If you upload without symbols you receive the following warning: "This App Bundle contains native code, and you've not uploaded debug symbols. We recommend you upload a symbol file to make your crashes and ANRs easier to analyze and debug."
In the past when uploading apps as .apk files it was necessary to manually upload such debug info. Now using .aab if the native library is built via android studio its possible to set android.defaultConfig.ndk.debugSymbolLevel = 'FULL' at which point when you build a the .aab it will include the debug info automatically, you upload this single file and everything is done/working.
pre-built libraries
However its not always possible/ideal/necessary to build a library inside android studio. Sometimes there are reasons for libraries to be externally pre-built and just used by android studio not built by it; Android studio supports this via a directory structure which is described here https://developer.android.com/studio/projects/gradle-external-native-builds#jniLibs
In short you just copy the libraries into the correct src/main/jniLibs/{ABI} path(s) and it is picked up and made part of the bundle.
Problem
Android studio can build a .aab that contains debug info that play store can understand so that you don't need to upload it manually.
Android studio can use pre built native libraries if you place them in the right path structure
I am unable to find any documentation or way to do both of these things together, use native pre-built libraries but include their debug info in the .aab. Even though logically it should be possible to do this.
I have searched everywhere I think but can't find anyone even talking about this really, how/where do you place the corresponding debug information so that that also can be included as part of the .aab? Is there a separate path for this, do they just need a specific file extension, does gradle need to be told what to do with them somehow?
Is it really just not possible?
Things I have tried:
Don't split the debug info just leave them in the .so files - play store does not strip them then so you deliver giant debug versions of your builds to your users
Split the debug info into files with .so.dbg extension and place them alongside the .so files - they aren't included in the .aab
Following the instructions (here https://support.google.com/googleplay/android-developer/answer/9848633 and elsewhere) to manually zip and upload the symbols after uploading the .aab - this appears to work but isn't the same convenience wise as having them in the .aab
I've tried building a sample app with android studio building a lib instead of using a pre-built lib just to verify that it does then include the debug info and what file extension it uses.
After some more digging I found the task responsible for this is "ExtractNativeDebugMetadataTask" with which some effort can likely be tailored/altered to do custom things here.
However this ended up being unnecessary as while digging into this I discovered that it actually already works.
At least as of now in latest gradle versions (not sure about the past).
It was only failing due to some NDK path confusion which doesn't fail the build/creation of the bundle building but just logs an easy to miss informational message.
Ultimately all you need to do to make this work is:
Build your external .so files with -g -g3 or similar
Do not strip them in any way
Place them in jniLibs directory structure un-stripped
Configure your build.gradle appropriately android{ ndk { debugSymbolLevel 'FULL' } ndkPath "$projectDir/path/to/NDK" }
Resulting .aab will contain the stripped .so files and the split-debug .so.dbg files all in the right location.
I am using an Android Unity plugin for a library which followed the prior Unity 5 suggested structure and it was working perfectly. The package was placing the necessary files under Assets/Plugins/Android where the jar file existed and in folder Assets/Plugins/Android/res/raw some .js and .css files used by the library. Everything was working perfectly but when upgraded to Unity 5 hundreds of errors appeared regarding the .js and .css files. (like insert semicolon at a specific line, or expected token at that line etc.)
I am aware of the changes in Unity 5, especially as mentioned here: http://docs.unity3d.com/Manual/PluginInspector.html , however I cannot find a proper solution to resolve this. So what i think the issue is that Unity is trying to parse these files as something different most probably as c# files resulting to the errors. How can exclude files in Assets/Plugins/Android/res/raw from that procedure, or at least how can i handle this situation. Do i have to restructure the file hierarchy with the new Unity 5? As far as I read they can keep the same structure for backwards compatibility.
We've got a similar issue on one of our projects, and there seems to be no way of preventing unity (at least, to try) to compile all your scripts. At this point unity expects the .js files to be "unity script files" and tries to compile them, which of then fails, when the .js files are some kind of web stuff.
I must admit, that I have no clue, why unity changed the behaviour from 4.x to 5, as the folder was indeed skipped from compilation in unity prior to version 5. See also "specific folders" section below.
Possible solutions
1. Putting the potential script files in a specific folder
There are some specific folders, where unity does not try to compile your files e.g. WebPlayerTemplates.
see http://docs.unity3d.com/Manual/ScriptCompileOrderFolders.html
2. Renaming the potential script files
As the unity compilation will only be performed for certain files (e.g. .cs or .js) you can avoid compilation by renaming them to e.g. .js_
For sure, both solutions will break your plugin in the first place, if you won't adapt it accordingly.
But what you can do is, to use a pre build hook to revert your changes (renaming or moving the files back) and make the plugin work on the device.
And just after the build again, to avoid the compilation (errors).
How to achieve this
Just create a custom build script (must be stored in an Editor folder, e.g. Assets/Editor). You'll find a new menu in unity named Build with an entry CustomBuild, where you can (and must) start your build.
Minimum version:
using UnityEditor;
using UnityEngine;
public class BuildProcessor {
[MenuItem ("Build/Custom Build", false, 0)]
static void CustomBuild() {
PreProcess();
BuildPipeline.BuildPlayer(new string[] { "your-main-scene.unity" }, "build-output-dir", BuildTarget.Android, BuildOptions.None);
PostProcess();
}
static void PreProcess() {
//Your pre-process here (e.g. rename all files from .js_ to .js)
}
static void PostProcess() {
//Your post-process here (e.g. rename all files back from .js to .js_)
}
}
More advanced scripts can be found on the web, or just feel free to add your creativity here ;-)
I took some inspiration here: http://jon-martin.com/?p=309
For how to rename a bunch of files you may want to check out this post: Renaming files in folder c#
I hope this will somehow satisfy your needs, let me know if something is not clear to you.
I am using some resources (images/drawable) in my own framework Android project to render some UI widgets. I just want to supply my framework as .jar to my clients. My clients can use this jar in their Android application libs.
The problem is even though I am exporting /res (i.e all images) directory at the time of .jar conversion, my client application is unable to use them. The reason I know is my client android application always look resources (images refereed as R.drawble.imgId) in client application resources but not in jar.
After goggling, I found a way to solve this is to supply my framework resources as zip along with .jar, so that my client applications will place supplied resources in their /res/drawable folder and no issues.
Now my Question is Is there any other way to achieve? How android is doing this for its view backgrounds?
For Distributed Jar, I found below method as simpler compare to others.
Please see below link for more
Packaging Android resource files within a distributable Jar file
There are a few questions on SO about using .jar files in an Android project. But I am wondering if the reverse is possible - is it possible to use .apk files in a Java desktop project?
The reason for this is that I created a Java desktop app for object database management, but it needs the model classes from whichever application database it is looking at. With an object database, you need the model classes to define you database schemas. Side question - forgive me for my ignorance but can you run a runnable .apk in a desktop environment? something like this:
http://www.techday.in/how-to-run-android-apk-apps-on-computer/
Anyway, my goal is to kick off my personal object manager program from an individual android application. So in that case the .apk files would have to be able to talk with .jar files. If that fails, I could try just the opposite - kick off the jar file, and use the -vm argument as a location of the .apk files to put in the classpath. Either way. Which is easier? ---> .apk files in a Java program's classpath or .jar files in an Android program's path? Please, just expound away, I want all your thoughts.
APKs contain DEX files, not Java Classes so you would need to translate from one VM file format DEX Davlik to another. The link you provided is for Bluestack's Android VM which would run a APK as it is running the Android OS. If you want to look up how VirtualBox does things that would be the closest match.
The source for Android projects do use standard JAR files for libraries and class files are generated as part of the build process however once you start to package into something you can put on a Android device/emulator/environment you are in a different world.
However as the DEX file format is open-sourced, what you are trying to do isn't impossible, but it might be easier to use the intermediate class files instead.