App does note cope well with extisting eduroam config

[martinpauly]

We frequently encounter a problem when the device already has an eduroam config, even a valid one. The Symptom is this: After the app has been launched and your institution/profile selected,
the app checks various items. If an eduroam config exist, a part of the checks will seemingly fail (red crosses or yellow warning signs for later items). After this the existing config is not replaced.
The workaround is to delete the old config manually and start from scratch.
As we have thousands of working devices to migrate to a new config in the German eudroam community (root cert expires in summer 2019), this is of considerable importance now.
If it's hard to reproduce, I can provide more details.

Thanks, Martin

[ghost]

Hi, as far is I understand, this is an Android rights issue, profiles created by an app are stored differently than user created ones and can not overwrite them. If both configs are created by the same app there should be no problem.

We already begun moving our clients last year by implementing a switch based on the local part of the outer identity to allow a smother transition

[restena-sw]

That's correct. Android APIs forbid apps to change manually configured Wi-Fi connections, and configurations produced by a different app. It can only update or delete configurations which it originated itself.

I totally agree that this is a nuisance when rolling over from manual to app-based configuration. But it is not in our hands.

[martinpauly]

Thank you for the clarification. This also explains why this doesn't affect all devices.
But there might still be a little room for improvement. Currently the app apparently does
not properly detect a situation with a pre-existent, conflicting connection. Rather, it claims
wrong or missing items on startup. Later, it still announces "This will replace your existing eduroam configuration" which does not happen, of course. Could we perhaps check beforehand or at least catch
the error properly and inform the user about the situation?

[restena-sw]

Good point, we should be a bit mor verbose there if API allows us to find out about this condition beforehand.

[GarethAyres]

Hi,

I am a bit confused, as this functionality was added a while back.
If a eduroam profile exists that the app does not have permissions to access, an alert is launched to prompt the user and warn them.

Gareth

[martinpauly]

You are right. I just tested on my own device (Lineage variety of Android 7.1.2). I do get the message,
but only after entering username and password. I suppose there's simply no earlier point to do a reliable check. So I have to apologize for not testing properly before opening this issue.
But at least one detail remains open to me, which might be a German translation problem): After the failure message, asecond message tells me to remove a manually installed eduroam connection, then asks me for "Yes" or "No". "Yes" takes me to the WiFi settings, "No" does not. So obviously the question
"Do you want to go to network settings to remove the existing connection now?" is somehow missing, at least from the German version.

[restena-sw]

That was the point in the "beforehand". If there were a way to figure out that a connection for the SSID eduroam exists without trying to save the profile and failing, then the workflow could be much improved - e.g. the app could warn on startup immediately.

[restena-sw]

Here's an idea for early detection:

on first app launch (never installed a profile), create a connection with dummy details and try to push it to the device.
If this doesn't work -> we know that there's a manual configuration, alert user and suggest to delete
If it does work -> there was no manual configuration; delete installed dummy profile immediately again; stay silent to user

This doesn't cover all cases, e.g. if a user deleted a app-supplied configuration manually and replaced it with a by-hand configuration; but it does get the "basic" job done on initial app first launch.

[zmousm]

Any update on this issue?

I would only suggest the preemptive test suggested previously happens just before the first attempt to install a profile, as I think it might be slightly more user friendly than an unsolicited alert upon app launch.