I am developing an Ionic application which runs fine but is not totally recognized as the same application when built on another workstation.
Both workstations are using the same environment (Ubuntu, Visual Studio Code, ...) and are accessing the same git repo. When I am working on the same station, android recognizes the application and keeps its data and authorizations between different builds, but when I switch between the two stations and build the app again the new build replaces the previous one but its data and authorizations are lost.
Since I am relying on the same git repo, the config files (AndroidManifest.xml, capacitor.config.ts and friends) are identical and I wonder where android does find a difference (and how I fix that)...
Related
I have two user accounts on Ubuntu 22.04, Android Studio (and all build tools installed on both. For my main account everything works, on the other, the Android app builds fine but behaves differently. This wrong behavior only occurs when building the app on my main account, but not when someone else builds it or the CI runner creates an APK.
It does not matter whether I build it from the command line or from within Android Studio.
I am desperately looking for an explanation or even for ways to debug this. Isn't there some command that prints all environment variables, all paths to all tools, configs, etc… involved in the build process to give me some clue as to what is going on?
This issue only affects building Android apps. Building other JVM-based software (Spring, even mixed Kotlin+Java sources, traditional JEE services) works perfectly fine.
I copied the project folder to other machines, set up a VM, and freshly checked everything out from git and the same reproducible behaviour occurs: Building on my main machine results in a runnable Android app, which exhibits bugs that do not exist in the source code or in the libraries used, building it anywhere else results in an app, which behaves as it should. We even verified that building the app on my main account produces different smali code compared to any other build setups.
I tried manually installing the Android SDK, tried managing it from within Android Studio installed from the JetBrains, flathub, snap store… no dice.
How to debug this?
We're working in an app for Android/IOS and the team has at least 3 people working in the app code and who need to have the app running locally in their particular env, someone is developing over Mac OS to eventually build to iOS and the others are on Windows machines.
We've been experiencing problems with the Ionic project after installing ngCordova, some cordova plugins and the ionic-platform-web-client, the mac machine had the app running beautifully and the windows instances were broken complaining that: Module 'ionic.service.core' is not available!
We don't know which particular step caused the code inconsistency and after several hours of looking around to fix it we decided just to create a new Ionic project and copy our specific www code inside. Since we don't want that to happen again we need to figure a reliable method of keeping all platforms working right after we install a plugin or add an Ionic service.
Could this be accomplished only by gitignoring www/lib folder and platforms, and then running bower install in each dev machine after a new module have been added to the project? or is it more complex than that and we're omitting some important steps to allow the project collaboration without these kind of issues?
Yes, you can put platforms in your .gitignore. I personally wouldn't be putting www/lib folder there, though.
Also, I would strongly advise that on all the machines where you're building the apps locally you have the same version of Ionic and Node.
We are developing android app. We have a project, multiple libraries and several test projects. Some of the test cases in test projects are organized into suites.
Our layout seems like this:
Root
Application
Library1
Library2
AppTest1
suiteQuick
suiteDeep
AppTest2
...
Everything works (somehow), but for various reasons we have decided to migrate this into the new build system, based on gradle. Here is where the troubles begin.
As I understand, in new project layout required by the new build system, the tests reside in the same project as the application / libraries (in folder instrumentTest).
I can imagine we could collapse all this AppTest applications' source codes into single instrumentTest folder of the Application, but we definitely do not want all the tests to launch in the same run.
For instance, the tests from AppTest1.suiteDeep takes approximately 45 minutes and as such are not suitable to be run after every single commit into Gerrit-managed repository for commit verification.
Another issue is regarding the target device. On our CI server, we've got attached several Android devices, but we don't want the tests run on all of them. On old build system this was easy, all we had to do was to specify via ant on which device the instrumentation to run.
But with gradle all the connected devices are used in parallel. I believe this can be sometimes useful, but it is not suitable nor desired behavior in our environment.
I looked everywhere on the net, but I was not able to find a solution for any of these problems. Any tip will be appreciated.
I'm currently using gradle android plugin v 0.8.1.
As you may know there are three ways to deploy a Qt application on Android :
Use Ministro service to install Qt
Deploy local Qt libraries to temporary directory
Bundle Qt libraries in APK
The first method takes about 30 seconds and it also needs to install an extra apk . Ministro.
The second takes about 1 minute for me ! And anytime I try to run the program Qt creator pushes Qt libraries to the device.
The third one makes the .apk file really big and again takes about 1 minute for me.
I think with this situation that's not reasonable to develop Android application using Qt. Is there a way to make the deploying process faster?
Almost a full year since the OP and things have not changed at all. Deployment of a 7 MB APK takes over minute and a half for a project that compiles in 5 seconds. The reason I am answering is not that the problem got resolved, but to offer an alternative solution.
I've implemented a "workaround" consisting of two applications that work in tandem - one on the PC and one on the device - I created this mostly to compile files remotely, but it turned out to be a much faster alternative for deployment as well. On the host create an application that launches compilation in a separate process, when done copy the product file over network to the device to deploy. Besides remote compilation this reduced the time to deploy to like 10 seconds, I can live with that.
(Not a complete and fully tested answer yet, but I'll update if I find out more …)
Option 1: Copy the changed libraries to a rooted device
A new build will most often result only in one changed file: your libAppName.so, the native library containing your application's code. At least in 2015, it was possible to simply copy over this library to the Android device, without having to re-build the APK package. This only works with rooted Android devices (note that all emulators are rooted by default).
Step by step, according to this blog article and updated with the paths as I found them on my device:
Run the cross-compilation step on your build host system. So just make or the equivalent in Qt Creator.
Copy the resulting libAppName.so to the rooted Android device:
adb push build/path/libAppName.so /data/app/com.example.appname/lib/arm
Restart the application on the Android device.
If that works, you might even be able to integrate it as a custom deployment step in Qt Creator.
I did not test this technique yet due to lack of a rooted device. But it should still work given that (1) rooted Android devices still allow to overwrite all files and (2) debug builds of APKs can still be installed without code signing, so overwriting a library in an APK without code signing should be possible.
Option 2: Desktop targets as a workaround
I found out by chance that Qt's multi-platform character can be used to avoid the slow Android deployment 80% of the time. You just set up another compilation target; under Qt Creator you'd add a target under "Projects → Build & Run", using a kit for "Device Type: Desktop".
Now when you want to test anything that is not Android-specific, test instead in the Desktop version. Building and starting that will only take a few seconds.
This approach is further supported by using a framework for convergent application development so that the same user interface is usable both in the desktop and mobile versions. KDE Kirigami and MauiKit are two libraries for this purpose that build on Qt. Documentation for getting started is a bit scarce, but for Kirigami I wrote an extensive README for the setup of an example application.
I want to make some changes to the stock Mms Android application and install it on my device. However, I have problems with compiling the code checkout obtained from git. I have created a new Eclipse Android project with "use existing sources", setting the target framework to 2.1. However, Eclipse does not find some needed framework classes, e.g. android.telephony.SmsManager.
I have the whole Android toolchain set up and working (make finished without errors), Eclipse is running on Sun Jdk 1.5.
Perhaps my mistake was that I did not copy the .classpath file into the new project, I will check this. Never the less, should I succeed, will I be able to install this .apk into a non-rooted device?
The stock Android applications are not designed to be built using the Android SDK, mostly because many of them predate that SDK. Right now, they can only be compiled as part of the firmware.
Even if you wind up with an APK, you will not be able to install it separately from a replacement firmware, unless you change the package in the manifest. You cannot have two applications on the device at the same time with the same package, and since you will not be signing your APK with the digital signature used by the firmware, yours will not be able to overwrite the existing one.
If you have a device that supports replaceable firmware (e.g., ADP2, Nexus One), you may be able to create, sign, and install your own firmware, then replace that APK in the future without replacing all of firmware a second time -- I don't know how well that works.