Remove Google Play Services dependency

[arthurlutz]

It would be nice to be able to install owntracks without using google play service and using the f-droid application : https://f-droid.org/

[jpmens]

Closing as duplicate of #82

[jpmens]

Closing as duplicate of #82

[arthurlutz]

ok, sorry for the duplicate, I did do a search before submitting this issue and did not find #82

Could I suggest a different use of the issue tracker where issues could be left open even when the main participants do not have time to work on them. Open issues that are welcomed by "core" team could be a invitation for others to contribute to the project.

[arthurlutz]

ok, sorry for the duplicate, I did do a search before submitting this issue and did not find #82

Could I suggest a different use of the issue tracker where issues could be left open even when the main participants do not have time to work on them. Open issues that are welcomed by "core" team could be a invitation for others to contribute to the project.

[binarybucks]

All the open issues are essentially free to work on.
I wecome every helping hand that I have ;)

[binarybucks]

All the open issues are essentially free to work on.
I wecome every helping hand that I have ;)

[jpmens]

@arthurlutz I will reopen now, and we're looking forward to your contributions. :-)

[jpmens]

@arthurlutz I will reopen now, and we're looking forward to your contributions. :-)

[binarybucks]

Jup, but instead of ripping out all the Play Services it would be nice if the whole thing would work with them in the first place ;)

[binarybucks]

Jup, but instead of ripping out all the Play Services it would be nice if the whole thing would work with them in the first place ;)

[binarybucks]

no longer on the roadmap.

[binarybucks]

no longer on the roadmap.

[friesenkiwi]

Hi. I read about OwnTracks and MQTT a while ago and followed it since then because I'd love to set up my own server and use it with the app, also possibly contributing to the server or app. Now I wanted to try out he app but unfortunately can't install it. Because it needs Google Play Services. Which I don't understand. What for are they needed? :)

I thought, the point at developing an OWNTracks client/server application which is open source was, because one wanted to track one's own position on an own server, sharing it only with people one decides on without depending on big corporations like Microsoft, Apple or Google, thus controlling one's own data?

I actually can't install the app on my Samsung S4 Mini because i run CyanogenMod 11 M13 with no Google Services installed. :-(

So ... for me it would be very desireable to have OwnTracks working wirhout the Play Services and being distributed via F-Droid. @binarybucks, you said, it's no longer on the roadmap. That's sad :-(. Is there any chance of putting it back on it? :-) Maybe if I'd contribute some code to remove the Google Play Services dependency?

[friesenkiwi]

Hi. I read about OwnTracks and MQTT a while ago and followed it since then because I'd love to set up my own server and use it with the app, also possibly contributing to the server or app. Now I wanted to try out he app but unfortunately can't install it. Because it needs Google Play Services. Which I don't understand. What for are they needed? :)

I thought, the point at developing an OWNTracks client/server application which is open source was, because one wanted to track one's own position on an own server, sharing it only with people one decides on without depending on big corporations like Microsoft, Apple or Google, thus controlling one's own data?

I actually can't install the app on my Samsung S4 Mini because i run CyanogenMod 11 M13 with no Google Services installed. :-(

So ... for me it would be very desireable to have OwnTracks working wirhout the Play Services and being distributed via F-Droid. @binarybucks, you said, it's no longer on the roadmap. That's sad :-(. Is there any chance of putting it back on it? :-) Maybe if I'd contribute some code to remove the Google Play Services dependency?

[Pimmetje]

I only used Google play services for push. I even installed the same app on a system without Google play. It worked with some small modifications. Now i have Google play services removed altogether in favor of a MQTT flavor.

[Pimmetje]

I only used Google play services for push. I even installed the same app on a system without Google play. It worked with some small modifications. Now i have Google play services removed altogether in favor of a MQTT flavor.

[friesenkiwi]

Do you mean you have a version of OwnTracks without the Google Play Services? Or did you mean a completely different App?

#84 has the same question to remove the dependency and it also has a suggestion to include https://github.com/mapzen/LOST as a replacement. I'd find that very appealing and would volunteer to do the coding on it, if it was of interest for OwnTracks. @jpmens, @binarybucks, what are your thoughts on that?
I wouldn't want to "rip out" anything in the sense of destroying the functionality, but keep it and introduce the new quality of independence, open services and a larger community and target audience (e.g. those who are relying on the F-Droid catalog)

[friesenkiwi]

Do you mean you have a version of OwnTracks without the Google Play Services? Or did you mean a completely different App?

#84 has the same question to remove the dependency and it also has a suggestion to include https://github.com/mapzen/LOST as a replacement. I'd find that very appealing and would volunteer to do the coding on it, if it was of interest for OwnTracks. @jpmens, @binarybucks, what are your thoughts on that?
I wouldn't want to "rip out" anything in the sense of destroying the functionality, but keep it and introduce the new quality of independence, open services and a larger community and target audience (e.g. those who are relying on the F-Droid catalog)

[binarybucks]

@Pimmetje OwnTracks doesn't use Google Play Services for push so I'm not sure what you did there. Could you provide some more detail on your modifications? If they're usefull, we could implement them as well.

@friesenkiwi OwnTracks is open source and allows you to send your location to your own server, yes. The part were it gets the locations from is Google Play Services which are not open source, yes. I'm not sure why there is such hate agaist the Play Services (besides from developers, because the APIs change every few months). If you own an Android device or use Google Maps, Google most likely has your location anyway. If you can live without these services I envy you to be honest.

I removed the item from the roadmap because at that point there wasn't any good alternative that I was aware of that didn't require rewriting the (barely working) location component.

If LOST is really a drop in replacement that might even work better, I'm more than happy to test ad accept a pull request from you.

[binarybucks]

@Pimmetje OwnTracks doesn't use Google Play Services for push so I'm not sure what you did there. Could you provide some more detail on your modifications? If they're usefull, we could implement them as well.

@friesenkiwi OwnTracks is open source and allows you to send your location to your own server, yes. The part were it gets the locations from is Google Play Services which are not open source, yes. I'm not sure why there is such hate agaist the Play Services (besides from developers, because the APIs change every few months). If you own an Android device or use Google Maps, Google most likely has your location anyway. If you can live without these services I envy you to be honest.

I removed the item from the roadmap because at that point there wasn't any good alternative that I was aware of that didn't require rewriting the (barely working) location component.

If LOST is really a drop in replacement that might even work better, I'm more than happy to test ad accept a pull request from you.

[friesenkiwi]

Ok, that's a good thing to hear and it spurs my ambition! :-) I will try to make some progress in the coming weeks and keep you in the loop.

You mentioned, the location component is "barely working", can you tell a bit more about it, so I can account for that during the work?

I wouldn't call it hate (at least not on my side), it's more like scepticism and trying to stay independent from "big overseas companies" as much as it's reasonable.
I have no Google account and my device has only ever been connected to any network as soon as there was a Cyanogenmod on it (which was actually pretty easy and came with a lot of other benefits), so I at least tried to lower the probability of Google having my location ;-).
There's really not much to envy, I'd say, because there's no "austereness", nothing I am missing or functionality I would need. GPS-only localisation might not always be as quick, but that has not been of disadvantage so far.

[friesenkiwi]

Ok, that's a good thing to hear and it spurs my ambition! :-) I will try to make some progress in the coming weeks and keep you in the loop.

You mentioned, the location component is "barely working", can you tell a bit more about it, so I can account for that during the work?

I wouldn't call it hate (at least not on my side), it's more like scepticism and trying to stay independent from "big overseas companies" as much as it's reasonable.
I have no Google account and my device has only ever been connected to any network as soon as there was a Cyanogenmod on it (which was actually pretty easy and came with a lot of other benefits), so I at least tried to lower the probability of Google having my location ;-).
There's really not much to envy, I'd say, because there's no "austereness", nothing I am missing or functionality I would need. GPS-only localisation might not always be as quick, but that has not been of disadvantage so far.

[binarybucks]

GPS-only localisation might not always be as quick, but that has not been of disadvantage so far.

But you don't really want to use that for background location gathering if you love your battery.
I really like the idea of the Fused Location Provider because it (in theory) can reuse locations requested by other applications.

You mentioned, the location component is "barely working", can you tell a bit more about it, so I can account for that during the work?

The location API generally isn't as reliable as on iOS. We get signifficantly less location updates from it on longer tracks. We had an other issue with reporting but that is fixed in the more recent versions. There's also that issue that the Location API stops providing location change events unless you reboot the device. There's an open issue on the Google bug tracker with 200+ comments about that but apparently nobody at Google cares to fix this. The issue has since been marked obsolete without a fix in sight. Thus locations from LOST might prove to be more reliable than through Google Play which whould be awesome.

[binarybucks]

GPS-only localisation might not always be as quick, but that has not been of disadvantage so far.

But you don't really want to use that for background location gathering if you love your battery.
I really like the idea of the Fused Location Provider because it (in theory) can reuse locations requested by other applications.

You mentioned, the location component is "barely working", can you tell a bit more about it, so I can account for that during the work?

The location API generally isn't as reliable as on iOS. We get signifficantly less location updates from it on longer tracks. We had an other issue with reporting but that is fixed in the more recent versions. There's also that issue that the Location API stops providing location change events unless you reboot the device. There's an open issue on the Google bug tracker with 200+ comments about that but apparently nobody at Google cares to fix this. The issue has since been marked obsolete without a fix in sight. Thus locations from LOST might prove to be more reliable than through Google Play which whould be awesome.

[jpmens]

If this makes our Android app more reliable in terms of location publishes, I'm all for it: make it happen! ;-) We can always look at battery consumption in hind-sight. ;-)

[jpmens]

If this makes our Android app more reliable in terms of location publishes, I'm all for it: make it happen! ;-) We can always look at battery consumption in hind-sight. ;-)

[friesenkiwi]

OK, so I got the dev environment set up, the app compiles and I even managed to get past the initial error popup by just uncommenting the bit in the code. The app only crashes when trying to get a detailed view on a contact.
I'll next need to set up my own server for testing and then get to code.
After a quick search in the code, it seems that there are two main points to start digging: The localisation part and the map display part. I was thinking of adding a choice for each of those in the preferences with an automatic fallback to LOST or https://github.com/osmdroid/osmdroid in case one doesn't have the Play Services installed. Also It should be possible to use GoogleMaps even without the PlayServices, the DB Railnavigator and Öffi work on my device with Google Maps installed seperately.

Also, my use case for using OwnTracks would be a bit different: I wouldn't want my location to be tracked all the time (even on my own server), but only when there is a concrete "need". So the battery drain might not be AS much of a problem to people in that case. But it might be helpful to include some informational text on this in the settings (later on).

I'll see what I can do next week.

[friesenkiwi]

OK, so I got the dev environment set up, the app compiles and I even managed to get past the initial error popup by just uncommenting the bit in the code. The app only crashes when trying to get a detailed view on a contact.
I'll next need to set up my own server for testing and then get to code.
After a quick search in the code, it seems that there are two main points to start digging: The localisation part and the map display part. I was thinking of adding a choice for each of those in the preferences with an automatic fallback to LOST or https://github.com/osmdroid/osmdroid in case one doesn't have the Play Services installed. Also It should be possible to use GoogleMaps even without the PlayServices, the DB Railnavigator and Öffi work on my device with Google Maps installed seperately.

Also, my use case for using OwnTracks would be a bit different: I wouldn't want my location to be tracked all the time (even on my own server), but only when there is a concrete "need". So the battery drain might not be AS much of a problem to people in that case. But it might be helpful to include some informational text on this in the settings (later on).

I'll see what I can do next week.

[binarybucks]

you just need to change things in ServiceLocator. The map doesn't use the
Play Services.

Mit freundlichen Grüßen / With kind regards
Alexander Rust

On 29 Jul 2015, at 13:51, friesenkiwi notifications@github.com wrote:

OK, so I got the dev environment set up, the app compiles and I even
managed to get past the initial error popup by just uncommenting the bit in
the code. The app only crashes when trying to get a detailed view on a
contact.
I'll next need to set up my own server for testing and then get to code.
After a quick search in the code, it seems that there are two main points
to start digging: The localisation part and the map display part. I was
thinking of adding a choice for each of those in the preferences with an
automatic fallback to LOST or https://github.com/osmdroid/osmdroid in case
one doesn't have the Play Services installed. Also It should be possible to
use GoogleMaps even without the PlayServices, the DB Railnavigator and Öffi
work on my device with Google Maps installed seperately.

Also, my use case for using OwnTracks would be a bit different: I wouldn't
want my location to be tracked all the time (even on my own server), but
only when there is a concrete "need". So the battery drain might not be AS
much of a problem to people in that case. But it might be helpful to
include some informational text on this in the settings (later on).

I'll see what I can do next week.

—
Reply to this email directly or view it on GitHub
#88 (comment).

[binarybucks]

you just need to change things in ServiceLocator. The map doesn't use the
Play Services.

Mit freundlichen Grüßen / With kind regards
Alexander Rust

On 29 Jul 2015, at 13:51, friesenkiwi notifications@github.com wrote:

OK, so I got the dev environment set up, the app compiles and I even
managed to get past the initial error popup by just uncommenting the bit in
the code. The app only crashes when trying to get a detailed view on a
contact.
I'll next need to set up my own server for testing and then get to code.
After a quick search in the code, it seems that there are two main points
to start digging: The localisation part and the map display part. I was
thinking of adding a choice for each of those in the preferences with an
automatic fallback to LOST or https://github.com/osmdroid/osmdroid in case
one doesn't have the Play Services installed. Also It should be possible to
use GoogleMaps even without the PlayServices, the DB Railnavigator and Öffi
work on my device with Google Maps installed seperately.

Also, my use case for using OwnTracks would be a bit different: I wouldn't
want my location to be tracked all the time (even on my own server), but
only when there is a concrete "need". So the battery drain might not be AS
much of a problem to people in that case. But it might be helpful to
include some informational text on this in the settings (later on).

I'll see what I can do next week.

—
Reply to this email directly or view it on GitHub
#88 (comment).

[friesenkiwi]

It seems, with using Google Maps API v2, Google Play Services is mandatory as a dependancy as well:

Prior to using any methods from this class, you must do one of the following to ensure that this class is initialized:
Call MapsInitializer.initialize(Context). As long as a GooglePlayServicesNotAvailableException isn't thrown, this class will be correctly initialized.

• https://developers.google.com/android/reference/com/google/android/gms/maps/model/BitmapDescriptorFactory

getMap() returns null, so all calls building upon it crash the app with a NullPointerException.
The app is usable, however, if a map is to be shown e.g. when tapping a 'contact' in the "Locations" view, crashes.
My suggestion would be, to implement a fail-safe mode, which always checks the availability of play services and if it is not available, once displays a Pop-Up, stating that "some functions may not be available". If a Map is to be displayed, the App would instead just show a short Toast.

Ultimately, I would target to add an abstraction layer to transparently fallback to OpenStreetMap-maps (https://github.com/osmdroid/osmdroid) or even better, ONLY use osmdroid...

What is your opinion on this?

I understand that it's very tedious to avoid using features, which seem to be common for many android phones... :-(. But on the other hand, there are also many phones without those services and in my perception, it would be their users who'd be the core target users for a privacy-aware application like OwnTracks and who would be most grateful, if it could be available in F-Droid...

Sorry for the evangelization :D

[friesenkiwi]

It seems, with using Google Maps API v2, Google Play Services is mandatory as a dependancy as well:

Prior to using any methods from this class, you must do one of the following to ensure that this class is initialized:
Call MapsInitializer.initialize(Context). As long as a GooglePlayServicesNotAvailableException isn't thrown, this class will be correctly initialized.

• https://developers.google.com/android/reference/com/google/android/gms/maps/model/BitmapDescriptorFactory

getMap() returns null, so all calls building upon it crash the app with a NullPointerException.
The app is usable, however, if a map is to be shown e.g. when tapping a 'contact' in the "Locations" view, crashes.
My suggestion would be, to implement a fail-safe mode, which always checks the availability of play services and if it is not available, once displays a Pop-Up, stating that "some functions may not be available". If a Map is to be displayed, the App would instead just show a short Toast.

Ultimately, I would target to add an abstraction layer to transparently fallback to OpenStreetMap-maps (https://github.com/osmdroid/osmdroid) or even better, ONLY use osmdroid...

What is your opinion on this?

I understand that it's very tedious to avoid using features, which seem to be common for many android phones... :-(. But on the other hand, there are also many phones without those services and in my perception, it would be their users who'd be the core target users for a privacy-aware application like OwnTracks and who would be most grateful, if it could be available in F-Droid...

Sorry for the evangelization :D

[binarybucks]

I won't maintain a version that includes OSM and GMaps for the time beeing
We could create a placeholder view hat says "you're using the Google free
version of this app so this functionality is not available".
This should be faily easy by adding a new Fragment in ActivityMain and
showing that instead of the MapFragment. We can switch that out for a OSM
Fragment anytime if we like.

I'll have to think about a way to remove the BitmapDescriptorFactory first (226)

[binarybucks]

I won't maintain a version that includes OSM and GMaps for the time beeing
We could create a placeholder view hat says "you're using the Google free
version of this app so this functionality is not available".
This should be faily easy by adding a new Fragment in ActivityMain and
showing that instead of the MapFragment. We can switch that out for a OSM
Fragment anytime if we like.

I'll have to think about a way to remove the BitmapDescriptorFactory first (226)

[friesenkiwi]

That sounds like a reasonable compromise :-)
Is there any problem with BitmapDescriptorFactory apart from this? Because the only usage I see apart from the MapFragment is in Contact.getFaceDescriptor() and that is only called by the MapFragment, so it shouldn't be much of a problem.

[friesenkiwi]

That sounds like a reasonable compromise :-)
Is there any problem with BitmapDescriptorFactory apart from this? Because the only usage I see apart from the MapFragment is in Contact.getFaceDescriptor() and that is only called by the MapFragment, so it shouldn't be much of a problem.

[binarybucks]

You're right, it's not really a problem if we don't have a map anyways.
One thing that came to my mind however: How restrictive is F-Droid? Is it enough that the app works when no Play Services are available but is linked against them anyways?

[binarybucks]

You're right, it's not really a problem if we don't have a map anyways.
One thing that came to my mind however: How restrictive is F-Droid? Is it enough that the app works when no Play Services are available but is linked against them anyways?

[friesenkiwi]

As far as I can see, they're fairly moderate. There is some documentation e.g. at https://f-droid.org/wiki/page/Inclusion_Policy and https://f-droid.org/wiki/page/Antifeatures.
My interpretation is, that if the App is completely free, it can be included into the repository without problems. But if the app would rely completely on non-free services or dependencies, it might be flagged with "Anti-features". But this would be an act of human consideration, and in the case of OwnTracks, where the essential operation would be ensured also without the "dependency" (which is intended to be the case), i'd expect no flags.

[friesenkiwi]

As far as I can see, they're fairly moderate. There is some documentation e.g. at https://f-droid.org/wiki/page/Inclusion_Policy and https://f-droid.org/wiki/page/Antifeatures.
My interpretation is, that if the App is completely free, it can be included into the repository without problems. But if the app would rely completely on non-free services or dependencies, it might be flagged with "Anti-features". But this would be an act of human consideration, and in the case of OwnTracks, where the essential operation would be ensured also without the "dependency" (which is intended to be the case), i'd expect no flags.

[binarybucks]

Reading the comment by one of the F-Droid over at #82 this just leaves us with the option to run an own repository because I'm not going to maintain versions of Paho, Fabric and all the Google Support libraries.

To be honest, I'm not sure if we can dedicate any resources (read time and money) to run a repository. At least for me Google Play is a perfectly acceptable software store.

[binarybucks]

Reading the comment by one of the F-Droid over at #82 this just leaves us with the option to run an own repository because I'm not going to maintain versions of Paho, Fabric and all the Google Support libraries.

To be honest, I'm not sure if we can dedicate any resources (read time and money) to run a repository. At least for me Google Play is a perfectly acceptable software store.

[friesenkiwi]

I suggest to take one step at a time: First trying to replace the Google Play Services dependancy with LOST without breaking essential functionality or endager it's stability, maybe even increase the localisation quality (which I started and am willing to continue and hopefully eventually finish, also by implementing the Geofencing functionality over at LOST). This will enable the App to run on more devices.
Afterwards, we may fathom the feasibility meeting F-Droid's requirements to include the App into it's repository without too much effort, introducing unnessecary overhead and reducing the maintainability (which are all valid reservations, in my opinion). On the other hand, that may widen the target audience for the app even more (those, who don't have a Google account, like myself...)
Is that a valid approach for you? I would be very sad, if a port to LOST couldn't be included only because it is not clear upfront, whether F-Droid inclusion is feasibile or not. I'd consider it valuable in itself.

@mvdan, you are referring to the external maven repositories

• https://repo.eclipse.org/content/repositories/paho-releases/ (the Eclipse Paho M2M IoT MQTT-Library)
• https://maven.fabric.io/public (Beta-/Crash Reporting)
  and the included
• libs/android-beacon-library-2.0-beta7.aar (which is a build of https://github.com/AltBeacon/android-beacon-library providing Bluetooth LE beacon functionality if I'm not mistaken? )
  Is that correct or am I missing something?
  Also LOST would be an additional included .jar, built from github source.
  Is there a way you can think of, not maintaining own forks/mirrors of the libraries but still link to it, so you can fetch it during the build, maybe as submodules or something?

[friesenkiwi]

I suggest to take one step at a time: First trying to replace the Google Play Services dependancy with LOST without breaking essential functionality or endager it's stability, maybe even increase the localisation quality (which I started and am willing to continue and hopefully eventually finish, also by implementing the Geofencing functionality over at LOST). This will enable the App to run on more devices.
Afterwards, we may fathom the feasibility meeting F-Droid's requirements to include the App into it's repository without too much effort, introducing unnessecary overhead and reducing the maintainability (which are all valid reservations, in my opinion). On the other hand, that may widen the target audience for the app even more (those, who don't have a Google account, like myself...)
Is that a valid approach for you? I would be very sad, if a port to LOST couldn't be included only because it is not clear upfront, whether F-Droid inclusion is feasibile or not. I'd consider it valuable in itself.

@mvdan, you are referring to the external maven repositories

• https://repo.eclipse.org/content/repositories/paho-releases/ (the Eclipse Paho M2M IoT MQTT-Library)
• https://maven.fabric.io/public (Beta-/Crash Reporting)
  and the included
• libs/android-beacon-library-2.0-beta7.aar (which is a build of https://github.com/AltBeacon/android-beacon-library providing Bluetooth LE beacon functionality if I'm not mistaken? )
  Is that correct or am I missing something?
  Also LOST would be an additional included .jar, built from github source.
  Is there a way you can think of, not maintaining own forks/mirrors of the libraries but still link to it, so you can fetch it during the build, maybe as submodules or something?

[binarybucks]

Continue with your work to add Geofences to LOST. If these work, we can
compare accuracy and battery life against the Play Services.

I'd like to keep the maven repositories for now. If you pull in LOST,
please import it through Maven Central (or as .jar until your changes are
merged).
Paho also plans to be included in Maven Central but that might take some
time but we shouldn't worry about the dependency problems.
First we should see if it will work at all.

On Mon, Aug 10, 2015 at 10:22 AM, friesenkiwi notifications@github.com
wrote:

I suggest to take one step at a time: First trying to replace the Google
Play Services dependancy with LOST without breaking essential functionality
or endager it's stability, maybe even increase the localisation quality
(which I started and am willing to continue and hopefully eventually
finish, also by implementing the Geofencing functionality over at LOST).
This will enable the App to run on more devices.
Afterwards, we may fathom the feasibility meeting F-Droid's requirements
to include the App into it's repository without too much effort,
introducing unnessecary overhead and reducing the maintainability (which
are all valid reservations, in my opinion). On the other hand, that may
widen the target audience for the app even more (those, who don't have a
Google account, like myself...)
Is that a valid approach for you? I would be very sad, if a port to LOST
couldn't be included only because it is not clear upfront, whether F-Droid
inclusion is feasibile or not. I'd consider it valuable in itself.

@mvdan https://github.com/mvdan, you are referring to the external
maven repositories

• https://repo.eclipse.org/content/repositories/paho-releases/ (the
  Eclipse Paho M2M IoT MQTT-Library)
• https://maven.fabric.io/public (Beta-/Crash Reporting) and the
  included
• libs/android-beacon-library-2.0-beta7.aar (which is a build of
  https://github.com/AltBeacon/android-beacon-library providing
  Bluetooth LE beacon functionality if I'm not mistaken? ) Is that correct or
  am I missing something? Also LOST would be an additional included .jar,
  built from github source. Is there a way you can think of, not maintaining
  own forks/mirrors of the libraries but still link to it, so you can fetch
  it during the build, maybe as submodules or something?

—
Reply to this email directly or view it on GitHub
#88 (comment).

Mit freundlichen Grüßen / With kind regards
Alexander Rust

[binarybucks]

Continue with your work to add Geofences to LOST. If these work, we can
compare accuracy and battery life against the Play Services.

I'd like to keep the maven repositories for now. If you pull in LOST,
please import it through Maven Central (or as .jar until your changes are
merged).
Paho also plans to be included in Maven Central but that might take some
time but we shouldn't worry about the dependency problems.
First we should see if it will work at all.

On Mon, Aug 10, 2015 at 10:22 AM, friesenkiwi notifications@github.com
wrote:

I suggest to take one step at a time: First trying to replace the Google
Play Services dependancy with LOST without breaking essential functionality
or endager it's stability, maybe even increase the localisation quality
(which I started and am willing to continue and hopefully eventually
finish, also by implementing the Geofencing functionality over at LOST).
This will enable the App to run on more devices.
Afterwards, we may fathom the feasibility meeting F-Droid's requirements
to include the App into it's repository without too much effort,
introducing unnessecary overhead and reducing the maintainability (which
are all valid reservations, in my opinion). On the other hand, that may
widen the target audience for the app even more (those, who don't have a
Google account, like myself...)
Is that a valid approach for you? I would be very sad, if a port to LOST
couldn't be included only because it is not clear upfront, whether F-Droid
inclusion is feasibile or not. I'd consider it valuable in itself.

@mvdan https://github.com/mvdan, you are referring to the external
maven repositories

• https://repo.eclipse.org/content/repositories/paho-releases/ (the
  Eclipse Paho M2M IoT MQTT-Library)
• https://maven.fabric.io/public (Beta-/Crash Reporting) and the
  included
• libs/android-beacon-library-2.0-beta7.aar (which is a build of
  https://github.com/AltBeacon/android-beacon-library providing
  Bluetooth LE beacon functionality if I'm not mistaken? ) Is that correct or
  am I missing something? Also LOST would be an additional included .jar,
  built from github source. Is there a way you can think of, not maintaining
  own forks/mirrors of the libraries but still link to it, so you can fetch
  it during the build, maybe as submodules or something?

—
Reply to this email directly or view it on GitHub
#88 (comment).

Mit freundlichen Grüßen / With kind regards
Alexander Rust

[binarybucks]

I've migrated the MapFragment from Google Maps to MapBox which is a map solution based on Openstreetmaps available on Maven Central.

How are things on the LOST front regarding Geofencing?

[binarybucks]

I've migrated the MapFragment from Google Maps to MapBox which is a map solution based on Openstreetmaps available on Maven Central.

How are things on the LOST front regarding Geofencing?

[ThomasRgbg]

Just as a little motivation, I would also like to use Owntracks, in case it works without Google Play Services. There are a lot of Android phones out without it (e.g. in China) and it would be great if you could support them.

[ThomasRgbg]

Just as a little motivation, I would also like to use Owntracks, in case it works without Google Play Services. There are a lot of Android phones out without it (e.g. in China) and it would be great if you could support them.

[binarybucks]

Yes, but there currently isn't a way around using the Play Services and tbh I don't see that this will change in the future.

[binarybucks]

Yes, but there currently isn't a way around using the Play Services and tbh I don't see that this will change in the future.

[jpmens]

Current status is we cannot do without Play Services (particularly not in view of an optional premium feature we're adding for Hosted) and won't be able to in any foreseeable future.

[jpmens]

Current status is we cannot do without Play Services (particularly not in view of an optional premium feature we're adding for Hosted) and won't be able to in any foreseeable future.

[mbirth]

Just for the record: There's the microG Framework which implements location services compatible to Google's API, but lets you select which backends to use for non-GPS-localisation.

[mbirth]

Just for the record: There's the microG Framework which implements location services compatible to Google's API, but lets you select which backends to use for non-GPS-localisation.