relaycorp / awala-ping-android

Android app for the Awala Ping Service
GNU General Public License v3.0
0 stars 0 forks source link

App fails to bind to gateway on Android 11 #158

Closed gnarea closed 3 years ago

gnarea commented 3 years ago

... So you get the screen saying that the gateway isn't installed.

I'm 60% confident I tried an early version of the Ping app on Android 11 and it worked, so if I'm not making that up, then we must've changed something that dropped Android 11 support.

I've already uninstalled and reinstalled both apps but the issue persists.

Filmaluco commented 3 years ago

Hi @gnarea, @sdsantos tasked me with taking a quick look. I was able to reproduce the issue. I think it might be related with changes made to Package Visibility and security with Android 11.

https://developer.android.com/training/package-visibility/declaring#package-name

It appears we now have to declare within the app manifests all apps we interact externally.


While we were doing this, we also need to prepare for Android 12 that takes this changes a step further. https://developer.android.com/about/versions/12/behavior-changes-12


Bind is working in previous Android versions, but we found an issue after binding.

Process: tech.relaycorp.ping, PID: 11570
    tech.relaycorp.ping.domain.InvalidIdentityCertificate: tech.relaycorp.awaladroid.endpoint.InvalidThirdPartyEndpoint: Invalid identity certificate
    ...
 Caused by: tech.relaycorp.relaynet.wrappers.x509.CertificateException: Certificate already expired

Do you know what it might be?


About the fix and the update to Android 12, we estimate half a day's work.

gnarea commented 3 years ago

Thanks for looking into this, @Filmaluco!

Re: Package visibility

That makes sense. So you'll change the Android library to declare the <package> dependency on the gateway app. This means that app developers using this lib won't have to make any changes to their manifest file, right?

The only concern about that change is that it'd lock app developers to our implementation of the gateway. That's sort of the case today, because the library only connects to our gateway app, but it would've been trivial to change it at runtime. But with this value hardcoded in the ARR, we couldn't change it at runtime any more. (For context, we wanted to give the user the option to use any Awala gateway they wanted, if in the future a 3rd party developer builds one that competes with ours)

Is there a way to make this work without locking the apps to tech.relaycorp.gateway? Like updating the code of the gateway instead of changing the Awala-compatible apps or the Android library?

If there's no way around it, please go ahead with the change anyway. I just wanted to make validate my understanding of the consequences and leave a trace of how we got here (to avoid being accused of vendor lock-in in the future).

Re: Android 12 support

Please go ahead with that too. You might need to make changes to the gateway too, but we'll see.

Re: CertificateException

I think I know what the problem is but I probably get round to fixing it tomorrow. To work around it, please add this endpoint manually in the Ping app:

That server is extremely slow, but it works! :)

Filmaluco commented 3 years ago

Is there a way to make this work without locking the apps to tech.relaycorp.gateway? Like updating the code of the gateway instead of changing the Awala-compatible apps or the Android library?

We investigated a little bit, this might be possible with component names instead of package names. For this we would need to test if multiple apps can have the same component name and if they can be exported, this while also being able to bind with Android 11 >=

We will explore this a bit further, and keep you updated, it might take an extra half day.

gnarea commented 3 years ago

Sounds good. Thanks!

Filmaluco commented 3 years ago

@gnarea just did a few tests. We are able to make it work with "Actions".

Instead of specifying the package of the gateway in the manifest, we can use a custom Action. The Gateway Service also needs to specify the action, but that's a simple addition. So wait for 2 PRs for the Android 11 fix

Filmaluco commented 3 years ago

@gnarea PR's done. Not sure why the PR with gateway is failing... the same task works with my machine, and the logs are not providing a lot of info. Will try to re-run after lunch...

Also we need to update Ping app with the new SDK after approval :) let me know if I missed something

gnarea commented 3 years ago

Thanks @Filmaluco!

Re: CI issue with gateway app, it runs on Linux so that might have something to do with -- especially given that one of the dependencies had issues on macOS. Either way, you could try adding --scan to https://github.com/relaycorp/relaynet-gateway-android/blob/d2a7fa5b03256dbc08058e89b995e9b1e1d63306/.github/workflows/ci-cd.yml#L32 to get more details -- here's an example in the Ping app.

Filmaluco commented 3 years ago

@gnarea Issue was with Java 8, had to upgrade to Java 11. Seems to work, but reached max limit tests...

sdsantos commented 3 years ago

Maybe security/snyk should only run when the rest of the tasks are successful?

gnarea commented 3 years ago

I just reported the issue to Snyk -- they shouldn't be counting public repos towards that limit.

Until they fix that, Kodiak won't work (so the automerge label wouldn't merge anything), but I can manually merge PRs from GitHUb.

github-actions[bot] commented 3 years ago

:tada: This issue has been resolved in version 1.1.12 :tada:

The release is available on:

Your semantic-release bot :package::rocket: