Standort wird über eine empfohlene App nicht erkannt

Vorbemerkung: Seit einer Woche hoffe ich auf Hilfe, leider bislang vergeblich . . .
Und deshalb bin ich jetzt vielleicht a bisserl unverschämt und poste statt auf Englisch das Ganze auf Deutsch. Zumal die App, um die es geht, nur für Benutzers des Nahverkehrs im Rhein-Neckar-Raum interessant ist.

Die App VRN eTarif ist im /e/ Application Checker aufgeführt, allerdings in der Version 1.4.0. Ich habe sie über APPS (foundation.e.apps / cleanapk.org) in der Version 1.9.25 (com.sevenre.linear_v3145753.apk) herunter geladen und installiert.
Die Einstellung “Standort” ist aktiviert, alles funktioniert bestens. Die Datenbank wurde aktualisiert: 7965 Haltestellen. NUR: die Haltestelle, an der man steht, wird nicht gefunden, obwohl man bei den Android-Einstellungen (Standort - VRN etarif - letzter Zugriff) die aktuelle Uhrzeit angezeigt bekommt. Deshalb kann ich damit keinen Fahrschein zu lösen.
Bei anderen Apps (DB Navigator, stadtmobil, OsmAnd, Magic Earth) funktioniert die Anzeige des Standorts problemlos.
Was tun ? Gibt es vielleicht weitere “Leidensgenossen” ?

1 Like

Nachtrag 19-06-2021: Das Thema beschäftigt mich, weil ich für den Nahverkehr diese App häufig brauche, aber so ist sie unbrauchbar, was auch finanziell einen Verlust bedeutet.
Im Google-StockROM Android 10 gab es keine Probleme mit der App.
Wie schon berichtet ist diese App (VRN eTarif Version 1.4.0) im /e/ Application Checker als funktionierend für /e/ aufgeführt.
Nun habe ich mir mit einiger Mühe diese ältere Version besorgt und installiert, UND: das gleiche Problem wie oben beschrieben, der Standort wird nicht erkannt. In den microG-Einstellungen ist sie unter “Cloud Messaging” nicht registriert, vielleicht liegt das aber auch daran, dass sie keine Push-Nachrichten versendet.
Auf der Seite “https://github.com/microg/GmsCore/wiki/Problem-Apps” fand ich den Hinweis, dass Apps, die die MapsV2 API benutzen, Problem-Apps seien. Mir scheint, diese VRNeTarif-App könnte dazu gehören.
Aber ich bin Musiker und Germanist und kein Programmierer, vielleicht schreibe ich jetzt Unsinn ?
@aibd und @Ingo_FP_Angel : Ihr habt mir schon einmal mit Ratschlägen geholfen, was meint ihr dazu ?

Ich habe leider keine Ahnung von der Materie.

Das beste, was mir einfällt, wäre den Hersteller der App zu kontaktieren. Nicht, dass ich da eine flotte Lösung erwarten würde, aber wenn keiner, der einen Hebel hätte, von dem Problem weiss, wird sicher nichts passieren.

1 Like

Vielen Dank für die rasche Antwort. Den Hersteller (www.seven-re.com) habe ich mit entsprechender Problembeschreibung angeschrieben. Bei derartigen Anfragen zu früheren Zeitpunkten habe ich allerdings von Seven RE noch nie eine Antwort bekommen. An den Verkehrsverbund VRN habe ich ebenfalls eine Anfrage gestartet, die wollten dann Screenshots haben, um die an den Hersteller (s.o.) weiterzuleiten. Zur Zeit liegt von beiden noch keine Antwort vor.
Ich ging bislang davon aus, dass der Fehler möglicherweise an meinen microG-Einstellungen liegen könnte. Die scheinen aber richtig eingestellt zu sein, da selbst Google Maps im Rahmen der nicht aktivierten “Web- und App-Aktivitäten” funktioniert und ebenfalls unter “Cloud Messaging” registriert werden konnte. Ansonsten sorge ich dafür, dass ich vor allem FOSS-Software verwende.

Haargenau das gleiche Problem. Falls es eine Antwort von SevenRe gibt oder eine andere Lösung für dieses Problem, wäre ich auch sehr dankbar.

Hallo,
ich bitte die späte Antwort zu entschuldigen, ich war verreist und konnte erst jetzt das neue Betriebssystem-Update (/e/OS 0.18-20210827132306) herunterladen, von dem ich mir eine Lösung des Problems erhofft habe, auch wegen einer neuen Version von microG. Leider vergeblich.
Auf eine Antwort von SevenRE kann man getrost bin zum Sankt-Nimmerleinstag warten.
Aber mit dem Verhalten der e-Leute bin ich auch nicht gerade überglücklich: ein Camille Anonyme via /e/ help desk" helpdesk@e.email sandte mir eine Anweisung, wie man das Problem bei GitLab melden kann. Das habe ich nach bestem Vermögen getan (Location not detected only by a single app (#3456) · Issues · e / Backlog · GitLab) - und da liegt nun mein Text seit zwei Monaten.

Vor dem Wechsel von Google Android 10 auf /e/ habe ich mir die Auflistungen des /e/Application Checkers gründlich angesehen und finde nun die Tatsache sehr ärgerlich, dass die dort als funktionierend aufgeführte App (VRN eTarif Version 1.4.0) schon den Fehler hat, dass der Standort nicht gefunden und erkannt wird. Genau so wie auch die neuere, die in dem e-App-Store “APPS” (foundation.e.apps / cleanapk.org) angeboten wird: VRN eTarif - Version 1.9.25 (3145753).

An Romain Hunault von /e/ und GitLab habe ich vor knapp zwei Monaten geschrieben und bislang keine Antwort erhalten.
Vielleicht sollte man gelegentlich Gael Duval (gaelduval@indidea.org) anschreiben ? Wenn zwei dies tun, ist das vielleicht besser als wenn nur ein Einzelner dies tut ?

Moment. Es hat wohl seinen Grund, warum der Application Checker tatsächlich nur von “available”, " downloading" und “installing” spricht, so weit klappt das ja anscheinend.

Der Grund ist das in /e/ anstelle von Google-Diensten enthaltene microG. microG ist nicht Google. Manche Apps brauchen aber Google.

VRN eTarif braucht laut Aurora Store Google-Dienste (der /e/ Apps Installer enthält diese Angabe ja leider nicht).
Da kann microG sich dann nach Kräften bemühen, der App vorhandene Google-Dienste vorzuspielen, das klappt bei vielen Apps auch mindestens eine Zeit lang, und in vielen Fällen auch unauffällig gut, aber garantieren kann das niemand.

/e/ erweckt in seiner Kommunikation gern einen anderen Eindruck, technisch sieht’s aber nunmal so aus.

BEVOR man sich auf eOS (oder LOS with microG) einlässt sollte man wissen, WAS das ist.
eOS ist ein Fork von “LOS with microG”.
“LOS with microG” ist ein Fork von LOS (aber MIT microG).
LOS ist ein Fork von AOSP.

Vorteil von eOS: KEINE Google-Dienste (und somit kein "nach-hause-telefonieren (zu Google)).
microG simuliert einige Google-Dienste.
Aber nicht ALLE perfekt.
Somit laufen einige App’s, aber nicht alle.
Wer also auf eine bestimmte App angewiesen ist muss diese testen.
Wenn sie läuft - alles gut. Wenn nicht - anderes OS benutzen.

Mein Daily-Driver: S9 mit eOS.
Ich finde eOS “gut”. Das muss aber jeder für sich selbst testen.

2 Likes

Und das im Prinzip ständig, weil Google durch Änderungen an seinen Diensten die Kompatibilität von microG dazu jederzeit kaputt machen kann. Dann sind entsprechende Änderungen an microG fällig, auf die man warten muss, solange verhalten sich betroffene Apps nervig (z.B. ständige Pop-ups im laufenden Betrieb, man möge doch bitte die Google-Dienste updaten) oder fallen halt ganz aus.

Wer wirklich auf die Lauffähigkeit von Sachen angewiesen ist, die Google-Dienste brauchen, ist bei /e/ falsch.
Für “schön wenn ein paar Google-abhängige Sachen laufen, nicht existenziell schlimm wenn nicht” ist /e/ gut geeignet.

1 Like

Vielen Dank für die Informationen, man lernt ja nie aus.
Die jeweilige Rolle von Google-Diensten und microG waren mir wohl bewusst.
Aber der letzte Satz im ersten Beitrag vcon AnotherElk ist besonders interessant:
“/e/ erweckt in seiner Kommunikation gern einen anderen Eindruck, technisch sieht’s aber nunmal so aus.”
Tja, so etwas sollte doch bitte auf der Seite “https://e.foundation/” stehen ! Eine ehrliche Darstellung hat noch nie geschadet !

Als ich noch Android 10 auf meinem Smartphone hatte, hatte ich eben wegen des Verhaltens von Google schon seit längerem die Software “Blokada” installiert, die recht befriedigend funktioniert.
Eigentlich dachte ich nach dem Wechsel auf /e/: Auf diese App kann ich ja jetzt verzichten.
Denn was schreibt der /e/-User db91595 dazu: "Vorteil von eOS: KEINE Google-Dienste (und somit kein “nach-hause-telefonieren (zu Google)).”
Zu diesem Aspekt füge ich einige ScreenShots der Logseite von “Blokada” an, die ich gelegentlich gemacht habe, um zu zeigen, was sich - trotz des installierten Betriebssystems /e/ (eOS) - im Hintergrund auf meinem Smartphone abspielt.
Meine Frage an die Experten:: Was wäre denn, wenn ich nicht die Software “Blokada” installiert hätte ?




Sind die denn von einem frisch installierten /e/ ohne zusätzlich installierte Apps, und ohne irgendwelche Websites im Browser aufzurufen, die Blokada was zum Blockieren geben?
Und in den microG-Einstellungen sind alle “Google-Dienste” deaktiviert, weil ja auch keine Apps da sind, die darauf angewiesen sind?

Natürlich ist so etwas wie Blokada weiterhin sinnvoll, wenn sich der Benutzer selbst werbebelastete Apps und/oder Google-abhängige Apps installiert und Websites besucht, die Werbekram nachladen. Was hat das mit dem OS zu tun?
Bei /e/ geht es darum, dass /e/ die schlimmen Sachen erstmal von Haus aus nicht selbst machen soll.

@montloup
Sind die beiden location modules in microg settings aktiviert und funktionieren auch? Selbstprufung in microg.

Gehen die Apps über aurora store statt über die Grütze des /e/ stores?

DAS denke ich mir auch.

@montloup
Was in deinem Blokada-Log an Google aufgeführt ist dürften App’s sein.
Das hat dann nichts mit eOS zu tun.

Weniger Apps als tracker über Websites surfen ausgeführt
/e/ bedeutet ja nicht automatisch dass tracker auf Websites nicht aufgerufen werden :wink:

Nun, um irgendwelche Spekulationen auf den Boden der Tatsachen herunterzuholen füge ich der Einfachheit halber wieder ScreenShots an, die ich heute gemacht habe.
Die letzte Änderung an /e/ fand Ende August 21 statt, als ich das Update /e/OS 0.18-20210827132306 herunterlud.
M.E. sind in den microG-Einstellungen alle “Google-Dienste” deaktiviert.
Die ersten beiden hier angehängten ScreenShots (Blokada Host-Logs) habe ich heute um 11:32 / 11:33 Uhr gemacht, nachdem das Smartphone gestartet, aber noch keine App aktiviert wurde. Nach ca. zwei Minuten kamen dann keine Meldungen über geblockte Hosts mehr. Ich schaltete dann das Smartphone wieder aus.
Die “location modules” (Mozilla Location Service und Nominatim) in microG sind aktiviert und funktionieren auch.
Zusätzlich zu den System-Apps von eOS habe ich vorwiegend FOSS-Apps via f-droid installiert und elf weitere über den e-App-Store “APPS” (foundation.e.apps / cleanapk.org) bezogene:
Collabora Office, CovPass, DB Navigator, Gboard, Magic Earth, Google Maps Go, Microsoft Word, Notfall-Hilfe 112, stadtmobil carsharing, Total Commander, WetterOnline.

Zum Schluss meiner Ausführungen noch eine weitere “Demonstration”:
Alle Apps werden geschlossen, das Host-Protokoll in Blokada gelöscht, das Smartphone wird herunter gefahren und anschließend wieder gestartet.
Der System-Browser wird mit einer Anfrage bei Wikipedia gestartet und wieder geschlossen.
Das Host-Protokoll hierzu in Blokada ab 14:37 Uhr wird anbei in vier weiteren ScreenShots mitgeteilt:

Screenshot_20211005-113241_Blokada|250x500















Da sind ja einige dabei wo mich nichts mehr wundert…
Da kannst du auch gleich bei Stock Android bleiben

Über google und microsoft muss ich nichts weiter zu sagen.
Magic Earth und vor allen Dingen den DB Navigator kannst du hier Interessantes erfahren
https://www.kuketz-blog.de/category/microblog/
Die beiden aktuellen Artikel

Magic Earth ist allerdings vorinstallierter Bestandteil von /e/, aber da es ein Closed Source Sonderling in /e/ ist (momentan), gibt’s dazu diese Erläuterung … https://doc.e.foundation/maps.

Wer’s nicht haben will, kann’s deinstallieren … Uninstall default apps - #29 by AnotherElk.

Der Screenshot sagt aber etwas anderes.

Also für mich gibt’s hier irgendwie nichts spektakuläres zu sehen, es sei denn, man könnte unerwünschte Dinge jetzt /e/-Komponenten zuordnen, die diese Dinge gemäß /e/-Dokumentation nicht tun sollten. Der Rest liegt beim Benutzer.

Zu Magic Earth sagt Mike ja auch nichts anderes. Im Wesentlichen.
Man muss sich in dem Fall einfach drauf verlassen. Traffic fliest zumindest nicht an Drittanbieter sondern nur zu ME

@AnotherElk
Zitat montloup “M.E. sind in den microG-Einstellungen alle “Google-Dienste” deaktiviert.”
Antwort von AnotherElk: Der Screenshot sagt aber etwas anderes.

Eine Anleitung dazu, was ich ändern sollte, um wirklich alle Google-Dienste zu deaktivieren, wäre hilfreich.

eOs wirbt damit, dass das System “entgoogled” ist und auf Open-Source-Strukturen basiert. Warum werden jedoch im “/e/ Application Checker” überhaupt Apps angeboten, die nur mit Google-Diensten funktionieren ?
Denn werden solche Apps installiert, gibt es im Hintergrund ordentlich “traffic”, von dem der ahnungslose Neu-Nutzer zunächst gar nichts mitbekommt. Er geht ja davon aus, dass sein Gerät mit einem google-freien System arbeitet.
Benutzt er eine Blockierungssoftware wie z.B. Blokada, kommt er aus dem Staunen kaum heraus.
Eine Nachfrage im Forum von eOs führt nun zu Belehrungen von oben herab, wenn nicht gar Häme.

Dafür darf man dann noch eine weitere Erfahrung machen: Wochenlang wartet man vergeblich auf eine Antwort (siehe oben !).
Aber in dem Moment (z.B. am 31.08. oder am 05.10.21), wo man Fragen und eventuell Zweifel am heiligen System eOS nur andeutungsweise von sich gibt, kommt Bewegung auf. Da geht es plötzlich ganz schnell mit den Antworten.

Übrigens, eine Anleitung dazu, was ich in microG ändern sollte, um wirklich alle Google-Dienste zu deaktivieren, würde mich nach wie vor sehr interessieren (@AnotherElk).

FAZIT:
Ich habe mir einfach erlaubt, zu einigen Sachverhalten FRAGEN zu stellen, habe damit vielleicht empfindliche Punkte getroffen und leider nicht allzu sachliche Antworten bekommen.
Der Vorgang ist dennoch aufschlussreich. Wer nicht TOTAL an eOS glaubt, wer also nicht “für uns” ist, der ist “gegen uns”.
“Da kannst du auch gleich bei Stock Android bleiben” (kisman172).
So einfach ist das !
Bin ich in eine Sekte geraten ?