@bfdi Vielleicht könnt Ihr auch mal das RKI animieren, die APK nicht an den Play Store zu binden – sondern wie viele andere Android-Projekte auch, mit den Releases des zugehörigen Github-Repos zu veröffentlichen. Die Entwickler hätten das schon längst getan, dürfen aber anscheinend nicht. Siehe die zahlreichen Issues dazu im Repo der App (z.B. issue 1483) sowie der Wishlist (z.B. issue 57). Die App funktioniert auch mit @microg; die "Privacy-Fraktion" hätte somit dann auch mehr "Motivation".

@2342 @bfdi @microg Wie erklärt: derzeit nicht realisierbar (die App benötigt noch immer proprietäre Bibliotheken, F-Droid kann sie also nicht bauen. Und selbst wenn, würde die offizielle Exposure-API sie nicht akzeptieren). microG ist lediglich Ersatz für die Play Dienste *AUF DEM GERÄT* – eine Alternative für die Libs *in der App* gibt es (noch) nicht. Darauf warten? Oh, prima, verzögern wir das Ganze ein weiteres halbes Jahr, wie gehabt… Traurig das.

@IzzyOnDroid @2342 @bfdi

Ich verweise an dieser Stelle gerne auf den Eintrag in den Changelogs zum neuesten @microg release github.com/microg/GmsCore/rele:

Initial support for using microG EN as a library: Required artifacts published to maven central.

@larma @2342 @bfdi @microg Oh! Ich wusste nicht, dass Du schon so weit bist – das sind ja gute Neuigkeiten! Würde das auch mit der "offiziellen API" funktionieren (aka "drop-in replacement") – oder eher "parallel" (App braucht beides/flavors wenn sowohl microG als auch die offizielle API unterstützt werden sollen)?

(PS: Der Eintrag stammt von vor ein paar Stunden, daher kannte ich ihn noch nicht…)

Follow

@IzzyOnDroid

Ist wie im changelog steht alles noch nicht 100% getestet, sollte aber praktisch drop-in sein:
1. Alle dependencies mit `com.google.android.{play,gms}` aus der build.gradle werfen.
2. Die dependency auf `play-services-nearby*.aar` rauswerfen
3. Neue dependencies hinzufügen:
- `org.microg.gms:play-services-nearby` (client library)
- `org.microg.gms:play-services-nearby-core-ui` (implementation)
4. Profit.

· · Web · 2 · 2 · 4

@larma @IzzyOnDroid Warum juckt es mir bloß in den Fingern, eine App zu schreiben, die alle existierenden Apps vereint, die sich um diese API wrappen?

@fynnDirect Worauf wartest Du? :awesome: Wenn Du das innerhalb eines halben Jahres hinbekommst, sieht allerdings das TAG_SAP Team mit der "offiziellen App" ein wenig alt aus (und die BuReg bzgl. der Kosten ebenfalls)… 🙈

@IzzyOnDroid
Freue mich hierbei übrigens auch wirklich sehr über feedback, also wenn das mal jemand ausprobiert hat für die CWA oder irgendeine App eines anderen Landes.

Übrigens: wenn man die Implementierung direkt einbettet werden auch zusätzlich die Funktionen von microG die nicht über die Google API verfügbar sind erreichbar. Damit wäre es dann möglich im Falle einer Warnung Datum und Uhrzeit des Kontakts anzuzeigen.
Das ist definitiv als Einladung zum basteln zu verstehen 😉.

@rugk magst Du diese Details von @larma im Issue weitergeben? Also kurz: microG Lib als drop-in-replacement möglich (voriger Toot von Marvin mit "Steps Needed"), bietet dann (bei Nutzung mit microG auf dem Gerät) sogar zusätzliche Funktionalität? Die TAG-SAP sollte eigentlich über (bezahlte) Test-Kapazitäten verfügen. Und die Qualität von Marvin's Code eilt ihm als guter Ruf voraus, da sollten sie also nichts zu jammern haben :awesome:

@IzzyOnDroid @larma hmm, already did so?
github.com/corona-warn-app/cwa

Wenn du genaue Steps usw. hast gerne ergänzen. (Den Mehrwert mit Uhrzeit anzeigen wird SAP wohl nicht nutzen.)

@larma @IzzyOnDroid Kompilieren tut es jedenfalls, starten auch, und es fragt auch korrekt nach, ob man exposure notifications aktivieren möchte. Des Weiteren bin ich nicht sicher, wie ich das testen könnte.

Sign in to participate in the conversation
Mastodon

The original server operated by the Mastodon gGmbH non-profit