Okay i've tested this once now for Oreo and it did't work right;
Probably something concerning Broadcasts & JobSheduler.
Should also give an option to reenable refreshing onCreate or even onResume.

This commit could be applied as is and work correctly if you would be ready to roll back to targeting SDK Version 25 again @ligi.
If there are any implications in that (e.g. Google Play related) or if you just really want to target android 8 then let me know and I'll update my patches to work with oreo.

Otherwise I don't see any reason to target Oreo and since it's majorly breaking app refreshing functionality as it is implemented right now (even on master) so rolling back and merging this would really be better in my opinion. [The lazy solution]

Unfortunately I need to target 26 now if I want to upload to google play:
https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html

Just saw it in Android Lint too .-.

I see three options:

• Release this to F-Droid and push a Version to Google Play that updates in onResume() untli Oreo compliance is implemented
• Release this to F-Droid and skip one release on Google Play until Oreo compliance is implemented
• Implement Oreo compliance right away for everything

I would really like to let f-droid version and google play not drift apart - this only makes problems in the long run.
I only see option #3 as the way to go

Okay, digging into it.

If anyone can, please test this patch so it will prove to be stable enough for merge.

I consider this patch complete now. This means it is not ready for merge but should be fully functional and that any changes from this point will only be code cleanup and bug fixes.
Once the testing build has been thoroughly tested and once someone has reviewed my changes, possibly spotting bad practices or code mess, i will go on and polish it up for merge.

Another thing: As you can see in the change listing, some changes in my commit result from using the "Reformat Code" action in Android Studio (with default settings). Of course this is out of scope of this commit and will be removed before merge. I would nontheless welcome it if generally all FAST code would be reformatted in a dedicated commit to follow at least some code style. After all, it should make life easier for everyone working with FAST source code.

What do you think @ligi? Is this a good suggestion or do you want to keep all existing code as is and only apply style guidelines to newly contributed code?

Side note... I F*in love this app, and now SebiderSushi too for all your efforts! :D