Develop Reference

Unity Android: Can't build Firebase and Mapbox Project

I'm currently trying to build a Unity project for Android, which utilizes Mapbox, Firebase, Unity's in-built AR Foundation, and a bunch of smaller packages from the Asset Store, which cannot be the source of the problem.
I built the project before adding Firebase successfully, but now I get the following error:
D8: Program type already present: com.google.gson.FieldNamingPolicy$5
(full version posted here pastebin because it's a lengthy one)
Version Numbers:
Unity 2019.3.0f6
Firebase Unity SDK 6.14.0
Mapbox Unity SDK 2.1.1
As far as I can tell, the problem is based on Mapbox and Firebase having dependency issues with each other. However, I have no clue how to fix them.
I tried every plausible solution I could find, including custom-grade templates, Gradle settings, trying internal builds on an older version of Unity (2018.3.14f1), exporting the project to Android Studio, then building from there and more.
None of this worked for me, sadly.
Are there any other methods I could try to fix this?
Thank you in advance!
P.S.: If I try to disable R8 as proposed in the error message, I get a java.io.IOException about a read error related to the "Duplicate jar entry [com/google/d/d$5.class]", but in general, no matter what fix I try, I usually end up with a different error message than with the other approaches.

I have an idea about what may be happening, but don't have an immediate way to test this solution.
It looks like there are two copies of the Google gson library included in your build. Inspecting mapbox-unity-sdk_v2.1.1, I see that there is a file gson-2.8.5.jar included in the unity package. Since the build is apparently including gson as a side effect, you may be good just deleting this file. But I suspect that the support libraries that are also included may cause an issue.
Given this, I would suggest three avenues of remediation:
1) you may want to use the External Dependency Manager for Unity to resolve these files for you. This is included in the Firebase SDK (and is a completely open source project so you may want to request that MapBox use it in the future).
I would recommend reading this article to fully understand what's happening, but what you want to do is create a MapboxDependencies.xml file in an Editor folder (ex: Assets/Mapbox/Editor/MapboxDependencies.xml) and include all the dependencies under Mapbox/Core/Plugins/Android:
<dependencies>
<androidPackages>
<androidPackage spec="com.google.code.gson:gson:2.8.6"/>
</androidPackages>
</dependencies>
And delete the related jar/aar files when you're done.
Note that you will have to track down maven repositories for these, otherwise I would include a complete xml file for you.
Now libraries that may cause you issues are all the support libraries. It looks like Mapbox may still be using the old support libraries prior to Android Jetpack. There are mappings here, so I'll take a first stab at their Dependencies.xml entries for you:
<dependencies>
<androidPackages>
<androidPackage spec="com.google.code.gson:gson:2.8.6"/>
<androidPackage spec="androidx.appcompat:appcompat:1.1.0"/>
<androidPackage spec="androidx.legacy:legacy-support-core-ui:1.1.0"/>
<androidPackage spec="androidx.legacy:legacy-support-core-utils:1.1.0"/>
<androidPackage spec="androidx.media:media:1.1.0"/>
<androidPackage spec="androidx.legacy:legacy-support-v4:1.1.0"/>
<androidPackage spec="androidx.vectordrawable:vectordrawable:1.1.0"/>
</androidPackages>
</dependencies>
The other problem you would typically run into is that under normal circumstances, you'd have to recompile all the libraries that relied on the old support libraries to reference the new androidx ones. Jetpack did come with a tool called Jetifier that should do this automatically if you enable it in the External Dependency Manager:
Although you may run into this issue on some configurations of Unity 2019.3 and later (workaround in the issue thread).
2) Alternatively you can add a mainTemplate.gradle to achieve the same goals. I would recommend using the ExternalDependencyManager, but by deleting the aar/jar libraries and adding them as dependencies in mainTemplate you'll effectively achieve the same outcome.
3) If you resolve your dependencies without mainTemplate.gradle - all of Firebase's aar/jar files will get added to Assets/Plugins/Android/Firebase. If you deleted all of the conflicts with Mapbox libraries, you may get to the same point. This feels a bit more dangerous to me and the support libraries may be harder to work with (you'd have to track down the androidx libraries on your own for instance) - but might remove some of the moving pieces if the dependency managers are new to you.
I hope that all helps!
--Patrick

Developing Android 9.0 eSIM LPA (system app)

Trying to develop android LPA system app for eSIM with the new Pie API.
The doc says to extend the abstract EuiccService class. But this class is not in the official SDK, and the link in the docs just leads to corresponding file in the android source repo.
I tried using this file/class as a dependency, but it references other internal android classes/annotations and causes build/IDE errors.
Does anyone have an idea how to use this?
Do I really have to pull android src code and somehow reference required class from it?
EDIT: I think I've solved it, found couple of potential solutions, but they were a bit cumbersome. Used the android.jar from here: https://github.com/anggrayudi/android-hidden-api (contains modified android.jar with hidden APIs and internal resources). It didn't work when i replaced the whole file and resulted strange build errors, but i manually transferred the android\service\euicc\ folder to original android.jar of android-28 sdk and it works perfectly (class is available and apk builds without issues). And no need to waste time pulling and building AOSP.
EDIT #2: apparently not fully fixable atm. There's issue with android gradle plugins (at least 3.2.x-3.3.x) where during full sync some build task generates mock classes from android.jar and process fails if it's modified (discussion is here: https://github.com/anggrayudi/android-hidden-api/issues/46). Error looks like this:
Failed to transform file 'android.jar' to match attributes {artifactType=android-mockable-jar, returnDefaultValues=false} using transform MockableJarTransform
There's a workaround for that, though inconvenient:
when you need a full sync for the project, replace the android.jar with original, run sync, restore modified android.jar, the IDE now will run indexing and classes will be available again with build working until next full sync.
Will update this post if/when it's fixed or new solution is found.
EDIT#3: here's probably a final solution for EuiccService case (turned out pretty obvious):
Instead of adding 'android/service/euicc' folder to android.jar, just put it in a separate library and add it as a compileOnly dependency. Since the classes were not in the SDK, the lib should not cause conflict (would be the case if you need to use modified framework or access hidden APIs in already existing classes).

If you are going to create a System APP, you will do it in several ways:
You could call a part of the SystemAPI (a method for example) by reference.
You could make the aplication as a part of the AOSP Project (Downloading the AOSP code, and introducing your app as part of packages/apps/)

You will be able to access system APIs on a rooted device or if you have system permissions (this happens when you flash your app into the device as part of the system image).
However, if you want to be able to call the EuiccService class from Android Studio (for coding purposes), you'll need to add the Android framework jar to your project.
The steps are provided below:
First, you will have to download and build AOSP and generate a framework jar for your target Android version. Check the documentation here to get an idea of how to download and build AOSP.
After a successful build all framework classes are compiled into a jar called classes.jar which can be found at the location out/target/common/obj/JAVA_LIBRARIES/framework_intermediates.
Get this classes.jar and add it to your Android project as a jar file.
Gradle sync the project and start coding.
Please beware that you WILL NOT BE ABLE TO run this app on an Adnroid device where you do not have system permission for this app.

Using SkyEpub jar library in an android project

I am going to use SkyEpub 3 library in my android application to read ebooks in epub format. To get familiar with the method of using SkyEpub I have downloaded its android demo project from here.
Its demo project is working properly, But when I use the skyepub.jar in my own project, it says some methods and classes from the jar file are undefined. Of course in the mean time I am using an unlicensed version of this library. I want to test it before buying the license if it was ok. I doubt that the errors are because of using the unlicensed version of the library in my project.
Can any one tell me please what is the problem exactly?
Thank you in advance.

Because there are a lot of classes ,which are not in jar, in example project. In the example, they create a lot of classes by extends another classes from jar. I used this jar before.

I found what was the problem. I increased priority of the jar file in eclipse. Now it works.

ORMLite on Android using javax.persistence annotations

We have developed a web service and now are building an Android application to communicate with the web service. We use persistence in our web service and would also like to use persistence in our Android app. We figured that ORMLite was the way to go for persistency on Android and we are hoping that the javax.persistence support would be good enough for our app. I was hoping that I would be able to copy the web service's data model to the Android app and not having to modify the annotations.
So I tried copying the model classes and adding ormlite-android-4.41.jar and ormlite-core-4.41.jar to my Android project. Unfortunately this did not do the trick. My IDE can't find the classpaths for the javax.persistence annotations. Do I need additional libraries? I can't anything on that in the documentation.

If you are using maven. You can add this to your pom.xml:
<dependency>
<groupId>javax.persistence</groupId>
<artifactId>persistence-api</artifactId>
<version>1.0.2</version>
</dependency>
Alternatively you can download the jar file straight from the maven repository here then add it to the classpath. By the way, the #Table(name = "table_name") is not supported. You should substitute it with #Entity(name="table_name").

Interesting question. If the javax.persistence annotations aren't in the Android JDK then I'm not sure you should be using them.
That said, if you want to use them, you should be able to get the java files from a JDK source jar and include them in your own project. Just copy the annotations that you actually use out of the source jar into the appropriate javax/persistence path.
The ORMLite support for the javax.persistence annotations is far from perfect. If you have any problems please let me know so I can improve them.

How to create multiple Android apps from one code base

I have an Android code base which uses APIs with settings to get different data for several apps. All apps use the same code base but with one or two design tweaks. So how do I re-use the main code base without having to copy the whole Android project each time?
iPhone uses multiple targets in the same project which works well. If android cant do this do I need to compile binaries of the code base in one project and then import into each new app project? If so how? I'm using Eclipse and am an intermediate Java developer.
Any help much appreciated!
Doug

Check out "Working With Library Projects" from the Android documentation. This should be just what you're looking for: http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject

The current way to approach this issue if you are using Android Studio with Gradle is by using Gradle, Build Type + Product Flavor
http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
Build Variants
One goal of the new build system is to enable creating different versions of the same application.
There are two main use cases:
Different versions of the same application
For instance, a free/demo version vs the “pro” paid application.
Same application packaged differently for multi-apk in Google Play Store.
This new concept is designed to help when the differences are very minimum. If the answer to “Is this the same application?” is yes, then this is probably the way to go over Library Projects.

Note: This answer is basically obsolete now that one can create .aar libraries with resources. It still works, though, and there may be times when the portability of a .jar is desirable, so I'm leaving it here.
Blumer's answer is a good one, and you should definitely look into Android's idea of library projects. However, there is another alternative. If you have a module that contains only Java code, but no resources of any kind (images, layouts, etc.), you can compile it to a .jar file separately and use the resulting .jar in multiple application projects. It works like this:
Create a new Java project in Eclipse (not an Android project) and move the source code of your module there.
If your module references any classes from the SDK, you'll need to add the Android SDK .jar to the project's classpath (Project > Properties > Java Build Path > Libraries > Add JAR).
When your module is ready to use, bundle up its .class files into a .jar. You can do this manually, or you can look around to figure out how to get Eclipse to do it for you.
Copy your module .jar file into the "libs" directory of your app's main project.
Add the module .jar to the project's classpath (again, Project > Properties > Java Build Path > Libraries > Add JAR).
Now you should be able to build multiple apps using the same .jar, while maintaining only one copy of the module's source code.
Depending on your particular situation, this may or may not work any better for you than the standard Android library mechanism. But it's worth considering as an alternative.

The Android documentation recommends another approach if there aren't too many "different APIs" used.
The idea is to use reflection instead of making direction references to the code. Make sure to use optimized reflection instead of lookups every time.
References
http://developer.android.com/training/multiple-apks/api.html
http://developer.android.com/google/play/publishing/multiple-apks.html#ApiLevelOptions

You might want to consider using a source control system like Subversion (or GIT). Keep your most feature complete version in the trunk, and make branches for your separate versions that use different data sources or require minor layout changes, etc.