Add a test apk

[afischerdev]

The discussion in #364 has shown it would be nice to have a signed test version. At the moment all tests need recompilation from the tester before tests can start.

What about a 'devel' flavour with applicationId 'btools.routingapp.test'?

This could be signed with an extra certificate in 'Java CI' action. This means testers have a downloadable apk with extra data folder and don't have remove product version.

[EssBee59]

Hello,

No idea what is the best app-type for test purpose (signed with extra keystore or debug version).. Just for info I tested app-installations under Android 11: -APP Signed with my extra keystore is OK -APP Debug version OK (as create with "gradlew assembleDebug") -APP "unsigned" (first delivery) NOT OK

Ess Bee

[afischerdev]

The idea was to generate for each update an Android Apk that can be installed / used / tested directly.

This can be done with an extra application ID (e.g. 'btools.routingapp.test'). The app now has its own directories and is separate from the original.

This is useful for surface or directory tests. However, other programs can only access the service if the new application ID is also used.

[EssBee59]

However, other programs can only access the service if the new application ID is also used.

Very good idea to allow parallel installation of test and production apps! I undesrtand that access from navigation apps such as Osmand (using IPC) to the test app will not be possible?

Regards

[zod]

I think it would be enough to provide the debug APK which works without any signature. Most tests can also be carried out in the emulator (or could even be automated). Having an additional APK which doesn't allow testing all features (e.g. file access when called using service interface) isn't beneficial.

For user feedback it would be nice to provide beta versions using Google Play Console to more users. When needed signing with the Google Play key could also be automated using GitHub Actions or fastlane. The signing key can be stored as GitHub Action Secret so it's not public accessible.

[afischerdev]

@EssBee59 The apks have different application ids. So an apk developer has to use something like this when testing e.g. new interface.

  BRouterServiceConnection conn = new BRouterServiceConnection();
  Intent intent = new Intent();
  if (TEST_NEW_ROUTING) {
    PackageInfo pi = context.getPackageManager().getPackageInfo("btools.routingapp.test", 0);
    if (pi.versionCode > 42) { .. }
    intent.setClassName("btools.routingapp.test", "btools.routingapp.BRouterService");
  } else {
    PackageInfo pi = context.getPackageManager().getPackageInfo("btools.routingapp", 0);
    if (pi.versionCode > 41) { .. }
    intent.setClassName("btools.routingapp", "btools.routingapp.BRouterService");
  }
  context.bindService(intent, conn, Context.BIND_AUTO_CREATE);

@zod Yes, you are right everything needs a test. At the moment this means to me: remove old version, install new, upload some data and go on. At finish I go back the way: remove new version, install old, upload favorite data sections, personal profiles, nogos. Ready to make a walk.

[EssBee59]

@zod yes, the task for testing is not easy (for myself, I save the brouter directory first and restore the data after "install old", this save much time!)

@afischerdev yes I understand the use of 2 different apps I am using Osmand for production and Osmand+ for test of new version I dowload from "daily build" The 2 versions are separated in Android (ID and Storage), so I can test with Osmand+ without deinstalling Osmand

But with Brouter we have the "IPC" chalange: I think, in order to be adressed, the service must have an own address? So, to be able to test the core feature of Brouter (the service), production and test app shoul register with different addresses? (probacly an error will occurs, when 2 aps tried to register on the same address)

Some documentation about this: ==> Brouter (manifest) (service section) android:exported="true" android:name=".BRouterService" android:enabled="true" android:process=":brouter_service"

I do not see the difficulty in Brouter itself (it is easy to define a second assress in the test version): The problem i see is, for testing the service, the client must use this alternate address!

Osmand code public static BRouterServiceConnection connect(Context ctx){ BRouterServiceConnection conn = new BRouterServiceConnection(); Intent intent = new Intent(); intent.setClassName("btools.routingapp", "btools.routingapp.BRouterService"); boolean hasBRouter = ctx.bindService(intent, conn, Context.BIND_AUTO_CREATE); if(!hasBRouter){ conn = null; } return conn; } }

So I think, we need for this a special version of the clients (Osmand, Orymaps, Locusmaps) to test the Brouter-test service?

For myself, no problem to create a special version of Osmand, but I am not sure all the tester can do the same with their prefered navi-app ....??

A example an extract of logcat with Osmand (under Android 10 I had a sporadic disconnect) 11-08 13:57:37.008 1648 5629 I ActivityManager: Killing 8944:btools.routingapp:brouter_service/u0a307 (adj 930): empty #17

My thoughts are possibly not right, but I think it is better to clarify this point first before starting changes Ess Bee