A ForegroundService for Lambdanative. #256

0-8-15 · 2019-08-19T14:18:43Z

Exports a single procedure: foreground-service!

A NOOP on anything but Android. On Android:

(foreground-service! #t) Start the service.

(foreground-service! #f) Stop the service.

The service will send EVENT_IDLE every 30 seconds to your application.

The main use is to prevent Android from aggressivly stopping the
application when it should keep running.

Exports a single procedure: `foreground-service!` A NOOP on anything but Android. On Android: (foreground-service! #t) Start the service. (foreground-service! #f) Stop the service. The service will send EVENT_IDLE every 30 seconds to your application. The main use is to prevent Android from aggressivly stopping the application when it should keep running.

mgorges · 2019-08-19T18:33:45Z

Doesn't loaders/android/bootstrap.java.in#L116 give you an EVENT_IDLE event every 1/4 second, which should keep things alive?

mgorges · 2019-08-19T18:38:30Z

Also we used to do that with a thread-sleep (as you can see in commit 89d4703), but then switched to using a Timer (see commit d06577f2) about two years ago. There was a good reason for it but its lost as institutional memory.

0-8-15 · 2019-08-19T18:56:04Z

Newer versions of Android are rather aggressive in killing services. To cope with the issue one needs to start a foreground service. See: https://stackoverflow.com/questions/53612307/foreground-notification-service-not-working-in-one-plus-devices/56195214#56195214 After submitting the pull request I learned that this might still not be enough. Though completely handling the problem will need at least API version 26. I'll update the branch when I managed to get that done. (Right now I need to re-learn what I did to install API version 19 and install 26 too. :-/ so much for memory.)

…

On Aug 19 2019, Matthias Görges wrote: Also we used to do that with a thread-sleep (as you can see in commit [89d4703](89d4703)), but then switched to using a Timer (see commit [d06577f](d06577f)) about two years ago. There was a good reason for it but its lost as institutional memory.

mgorges · 2019-08-19T19:04:12Z

Okay thanks for looking into this further. If you still have the SDK installed, simply change the ANDROIDAPI in the SETUP file, clear the android build cache (make scrub is a bit much) and you should be good to go.

0-8-15 · 2019-08-20T21:17:41Z

Am Mon, 19 Aug 2019 12:04:17 -0700 schrieb Matthias Görges <[email protected]>:

Okay thanks for looking into this further. If you still have the SDK installed, simply change the `ANDROIDAPI` in the SETUP file, clear the android build cache (`make scrub` is a bit much) and you should be good to go.

Yeah, except that it changes my ANDROIDAPI=26 to 24 and complains that 24 is not a target. Looks as if I'll have to install a different ndk.

0-8-15 · 2019-08-20T21:22:34Z

Am Mon, 19 Aug 2019 12:04:17 -0700 schrieb Matthias Görges <[email protected]>:

Okay thanks for looking into this further.

One issue/question looms already on the horizon: It looks like I'll need to call Android APIs not yet available in say version 19. Is there a paved route how to make the java compiler happy? As far as I can see it will complain about unknown classes/methods. And I really don't want to write code which works only for Android 8 and above.

mgorges · 2019-08-21T00:18:35Z

As for the SDK, you probably only will need to add the missing one with the sdk manager something like /opt/local/android-sdk-macosx/tools/bin/sdkmanager 'platforms;android-24' wherever you might have placed this in your system?

As for calling new APIs, there isn't and #ifdef equivalent in Java. You might be able to some Build.VERSION.SDK_INT tests, but if the functions are not declared before this won't compile on earlier SDKs. E.g. see modules/localnotification/ANDROID_java_activityadditions#L36

See comments in ANDROID_xml_permissions and ANDROID_java_activityadditions how to compile for older API versions and possible issues wrt. restrictions regarding google play store.

…danative into new-module-androidforeground

0-8-15 · 2019-08-28T15:15:17Z

There are still issues. After removing and reinstalling, at least one device with Android 8.1 does no longer start LN applications build with API version 26 at all. Reason: None of the permissions requested via Manifest are granted at all. They appear as requested, but are disabled.

By now I don't yet know how to fix this.

mgorges · 2019-08-28T15:44:14Z

Thanks for the update, and working on the battery optimization piece. I believe @bclayton05 also encountered permission problems over the summer, however, for camera permissions? I don't recall details, but it might be that the requestPermission(); call needs to be made explicitly now, while previously it was automatic?

bclayton05 · 2019-08-28T19:34:34Z

I never fully understood where the problem was coming from, but I ended up solving my permission issues by explicitly confirming permissions each time the user wanted to interact with the desired permission-blocked feature. As @mgorges mentioned, explicitly requesting permissions when they hadn’t been granted was the solution.

Since Marshmallow permissions are not automatically granted as specified in the Manifest. As a consequence LN apps die when accessing the SDCard, e.g. when unpacking embedded files. This patch adds a fragile hack to enable an ifdef-alike trick to exclude code portions when targeting older APIs and uses it to request the permission at startup. Plus create the system-directory if it does not already exists.

mgorges · 2019-08-30T16:53:01Z

If this really is required we should consider adding this to modules/eventloop/eventloop.scm, in the e.g. in eventloop/eventloop.scm#L264 for EVENT_TERMINATE and eventloop/eventloop.scm#L186 EVENT_INIT, and make the eventloop module depend on the androidforeground module? However, I don't know if this would break existing EVENT_RESUME and EVENT_SUSPEND functionality?

Alternatively, you could make at least the (foreground-service! #t) call automatic at the 'androidforeground/androidforeground.scm' function, but I don't know if it would get terminated by default when the parent app crashes or is closed?

0-8-15 · 2019-09-02T17:29:54Z

If this really is required we should consider adding this to modules/eventloop/eventloop.scm

I'm unsure. The eventloop is essentially always required on Android, isn't it? Many applications may not need to run all the time. I'd rather keep the foregroundservice separate.

Alternatively, you could make at least the (foreground-service! #t) call automatic at the 'androidforeground/androidforeground.scm' function, but I don't know if it would get terminated by default when the parent app crashes or is closed?

This might be easy enough to add at the cost of some flexibility. Especially when it comes to termination. (So far I'd seen the app die and the foregroundservice still in the notifications.)

However I'll have to understand more about termination and Android. Some docs indicate that one should abstain from ever explicitly terminating. Dragons ahead: Simply calling (terminate) leaves my app unable to restart. I have no idea why. Currently I'm overwriting terminate with a log output and have it do nothing. My code does never calls it, but still it's being called. ... I'll need to learn.

0-8-15 · 2019-09-02T19:37:59Z

@bclayton05: I'm trying to solve the camera permission here too.

Right now the app always dies, which permission did you request explicitely and when/where in the source. Right now my LN app still dies as son as I try to access the camera. Though this might be some other stupidity on my part.

mgorges · 2019-09-02T19:47:08Z

// make sure permissions are met. requestPermission() results in this being called for the specified permission.
@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
    super.onRequestPermissionsResult(requestCode, permissions, grantResults);

    switch (requestCode) {
        case REQUEST_CAMERA_PERMISSION_RESULT: // Camera access permission
            if(grantResults[0] != PackageManager.PERMISSION_GRANTED) { // If permission was not granted.
                Toast.makeText(getApplicationContext(),
                        "Application cannot run without access to camera", Toast.LENGTH_LONG).show(); // Tell user app can't run without it.
            }
            break;
        case REQUEST_WRITE_EXTERNAL_STORAGE_PERMISSION_RESULT: // Permission to write to storage. Necessary to make video and vital sign files.
            if(grantResults[0] != PackageManager.PERMISSION_GRANTED) { // If permission was not granted.
                Toast.makeText(getApplicationContext(),
                        "Application cannot run without permission to write to storage", Toast.LENGTH_LONG).show(); // Tell user app can't run without it.
            } else { // If permission was granted, update UI to make app seem snappier, even though the MediaRecorder still needs to start, 
                                                                                      //which takes a long time (relatively speaking)
                mRecordImageButton.setImageBitmap(squircle); // Show the "stop" button (squircle refers to square circle because it's a rounded square).
                oximeterStatus.setText("Recording"); // Notify user that the recording has begun.
                if(mPatientId == null) { // If patient ID doesn't exist (which is impossible, but checked here for robustness).
                    topToolbar.setBackgroundColor(0x00000000);
                    topToolbar.removeAllViews(); // Remove top toolbar to be more immersive.
                }
                timer.start(); // Start the timer that displays recording length.
                Toast.makeText(getApplicationContext(),
                        "Permission Granted Successfully", Toast.LENGTH_LONG).show(); // Notify user permission was successfully granted.
            }
            break;
        case REQUEST_INTERNET_PERMISSION_RESULT: // Internet USE permission
            if(grantResults[0] != PackageManager.PERMISSION_GRANTED) { // If permission isn't granted. (most phones don't even need to request for this one)
                Toast.makeText(getApplicationContext(),
                        "Application cannot run without access to internet", Toast.LENGTH_LONG).show(); // Tell user that the app needs it.
            }
            break;
        case REQUEST_ACCESS_NETWORK_STATE_PERMISSION_RESULT: // Internet CONNECTION state permission
            if(grantResults[0] != PackageManager.PERMISSION_GRANTED) { // If it isn't granted (most phones don't even need to request for this one)
                Toast.makeText(getApplicationContext(),
                        "Application cannot run without access to network state", Toast.LENGTH_LONG).show(); // Tell user app can't run without it.
            }
            break;
    }
}


// Connect camera using android.hardware.camera2 API
private void connectCamera() {
    CameraManager cameraManager = (CameraManager) getSystemService(Context.CAMERA_SERVICE); // Retrieve Camera Manager object.
    try {
        if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { // If our build is for marshmallow (API 23) or higher (which it always is, unless things have changed since 2019)
            if(getApplicationContext().checkSelfPermission(Manifest.permission.CAMERA) ==
                    PackageManager.PERMISSION_GRANTED) { // Check our permission for camera access. It's required for this step.
                cameraManager.openCamera(mCameraId, mCameraDeviceStateCallback, null); // open the camera!
            } else {
                if(shouldShowRequestPermissionRationale(Manifest.permission.CAMERA)) { // If we didn't get permission, check if the user has previously denied it.
                    Toast.makeText(this,
                            "VidOx requires access to camera", Toast.LENGTH_LONG).show(); // If they've denied it before, tell them again that we need it.
                }
                requestPermissions(new String[] {Manifest.permission.CAMERA}, REQUEST_CAMERA_PERMISSION_RESULT); // Ask for the permission again!
            }
        } else {
            cameraManager.openCamera(mCameraId, mCameraDeviceStateCallback, null); // Builds lower than API 23 don't need permission, so you can just open the camera.
        }
    } catch (CameraAccessException e){
        e.printStackTrace(); // Print the Exception to the stack trace.
    }

}

mgorges · 2019-09-02T19:47:23Z

There might be more pieces - this is from an app doing video things by @bclayton05

0-8-15 · 2019-09-03T17:28:36Z

Looks like the culprit is another pitfall in newer Android APIs (here 26), which makes the approach to use startActivityForResult to obtain a photo fragile.

Question: How would I redirect (log or log alike) messages from Java code to the LN logfile?

The exception I ran into with simply requesting CAMERA permissions (after those being granted):

Error android.os.FileUriExposedException: file:///sdcard/front/_camera_tmp.jpg exposed beyond app through ClipData.Item.getUri()
android.os.FileUriExposedException: file:///sdcard/front/_camera_tmp.jpg exposed beyond app through ClipData.Item.getUri()
        at android.os.StrictMode.onFileUriExposed(StrictMode.java:1960)
        at android.net.Uri.checkFileUriExposed(Uri.java:2356)
        at android.content.ClipData.prepareToLeaveProcess(ClipData.java:942)
        at android.content.Intent.prepareToLeaveProcess(Intent.java:9850)
        at android.content.Intent.prepareToLeaveProcess(Intent.java:9835)
        at android.app.Instrumentation.execStartActivity(Instrumentation.java:1610)
        at android.app.Activity.startActivityForResult(Activity.java:4501)
        at android.app.Activity.startActivityForResult(Activity.java:4459)
        at net.softeyes.front.front.startCamera(front.java:371)
        at net.softeyes.front.myRenderer.nativeEvent(Native Method)
        at net.softeyes.front.myRenderer.pointerEvent(front.java:548)
        at net.softeyes.front.xGLSurfaceView$2.run(front.java:477)
        at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1500)
        at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1270)

mgorges · 2019-09-04T00:47:09Z

I am currently not aware of a way to redirect Android crash dumps into LambdaNative through the JNI interface or any other approach. In the Debugging section of the Wiki we do refer only to logcat which is what you also used here.
In principle I do think this is something that would make things easier from our perspective, but it might also confuse people who use the typical Android approach and expect it to show there (too)? Thus if you come across something that allows us to get a redirected copy that would be great.

0-8-15 · 2019-09-05T10:59:13Z

Am Tue, 03 Sep 2019 17:47:14 -0700 schrieb Matthias Görges <[email protected]>:

I am currently not aware of a way to redirect Android crash dumps into LambdaNative through the JNI interface or any other approach. In the [Debugging](https://github.com/part-cw/lambdanative/wiki/Debugging) section of the Wiki we do refer only to `logcat` which is what you also used here.

Actually I did not yet bother to use adb.

In principle I do think this is something that would make things easier from our perspective,

That's been my feeling too. I just threw these lines into my apps `ANDROID_java_oncreate: try { java.text.SimpleDateFormat formatter = new java.text.SimpleDateFormat("yyyyMMdd_hhmmss"); String ts = formatter.format(new java.util.Date()); System.setErr(new java.io.PrintStream(new FileOutputStream("/sdcard/@SYS_APPNAME@/log/log_" + ts + ".j.txt"), true)); } catch (java.io.FileNotFoundException e) {} And catch exceptions which I print like this `e.printStackTrace(System.err);` However I'd rather like to use the very same log file and LN itself.

but it might also confuse people who use the typical Android approach and expect it to show there (too)? Thus if you come across something that allows us to get a redirected copy that would be great.

The open question for me is how I would achieve to use just one logfile.

0-8-15 · 2019-09-05T18:21:59Z

Am Mon, 02 Sep 2019 12:47:28 -0700 schrieb Matthias Görges <[email protected]>:

There might be more pieces - this is from an add doing video things by @bclayton05

This tends to go beyond my ability to dig out a reasonable solution. The issue is related to `android.os.StrictMode.onFileUriExposed`. All my attempts to contain it turned out to be futile. Internet search hints towards `androidx`'s `FileProvider` which is also provided by the support library. Hence the question: how bad would it be to require the support library. I understand it's not nice as it's a piece of regulary changing, unstable code. But at the other hand I'm short of solutions. Currently I'm back where I started. The camera works with API level 19, but Android kills my service all the time, thereby killing availability and responsiveness. Let alone that there is now again this anoing icon in the status line.

mgorges · 2019-09-05T19:01:36Z

The open question for me is how I would achieve to use just one logfile.

If you can get it into JNI, there is a log_c function, which you can call with a string.

mgorges · 2019-09-05T19:04:18Z

The issue is related to android.os.StrictMode.onFileUriExposed.

Did you look at this: https://stackoverflow.com/questions/44821017/fileuriexposedexception-using-android-7, in particular their workaround?

0-8-15 · 2019-09-05T20:11:29Z

< Am Thu, 05 Sep 2019 12:04:23 -0700 schrieb Matthias Görges <[email protected]>:

> The issue is related to `android.os.StrictMode.onFileUriExposed`. Did you look at this: https://stackoverflow.com/questions/44821017/fileuriexposedexception-using-android-7, in particular their workaround?

I'm afraid, I ran into this the past two day already.

Since Android 7, we don't use file: scheme as uri for intent, you have to use FileProvider ... a naughty way to do it without adding FileProvider...

StrictMode.VmPolicy.Builder builder = new StrictMode.VmPolicy.Builder(); StrictMode.setVmPolicy(builder.build());

…

This will simply ignore the URI exposure and you will get the access. ****** *this is not the best practice* ****** still, recommended way is by using FileProvider.

---- To summarize: I feel the work around is good enough for testing. My goal, however, is rather to get around bad user experience, unmaintainable code etc. (otherwise I'd document in screenshots how to get around Androids new limitations/optimizations by just granting all sorts of permissions frowned upon by google). Hence I'd consider tampering with StrictMode a viable solution at best if it was a single statement not affecting any state but the one in scope. 'setVmPolicy' --- Hm, I know only so much, but this looks to me like opening the pandora box, doen't it? Still I'd love to get around the need of the support library. :-(

0-8-15 · 2019-09-06T11:12:19Z

Am Thu, 05 Sep 2019 12:01:41 -0700 schrieb Matthias Görges <[email protected]>:

> The open question for me is how I would achieve to use just one > logfile. If you can get it into JNI, there is a [log_c](https://github.com/part-cw/lambdanative/blob/9f2403be16a75430d8839064fb137b6d978267e0/modules/ln_core/log.scm#L98) function, which you can call with a string.

This might do the trick once lambdanative is initialized. Unfortunately the things I needed to debug have been before that's the case. Probably I'll have to do it the other way around and test logdir's existence from Java and open the logfile at the Scheme side in append mode.

mgorges · 2020-10-08T19:05:57Z

It seems that this is becoming a needed feature for #339, however it has merge conflicts in loaders/android/boostrap.java.in and also unrelated changes to packtool, some more of the ifdef API23 pieces we already have? Can I rebase this against master in a branch I don't own to start a new clean copy or would you have to?

0-8-15 · 2020-10-08T22:28:28Z

Am Thu, 08 Oct 2020 12:06:13 -0700 schrieb Matthias Görges <[email protected]>:

It seems that this is becoming a needed feature for #339, however it has merge conflicts in loaders/android/boostrap.java.in and also unrelated changes to packtool, some more of the ifdef API23 pieces we already have? Can I rebase this against master in a branch I don't own to start a new clean copy or would you have to?

Ah, forget the aged PR here. Those updates are only local here. Not yet polished and pushed.

mgorges · 2020-10-08T22:54:16Z

Okay, then I will await an update and in the meantime leave this untouched. Thanks.

0-8-15 · 2020-10-12T16:40:18Z

Am Thu, 08 Oct 2020 15:54:29 -0700 schrieb Matthias Görges <[email protected]>:

Okay, then I will await an update and in the meantime leave this untouched. Thanks.

While my code now works for <whatever-has-changed-recently> it no longer works for older API versions. Supporting all the differences between the Android API versions challenges the limits of what can be done using the simple `substool`. Assuming gambit new a bit more about the build environment - as #367 proposes - there should be a way to do this. We need to discuss (or simply inform me) however where Android API specific files (.java, .java.in, .jar etc.) should be dropped of which **will have to be** created while the module is compiled and what's a good spot to copy those over into the build directory.

mgorges · 2020-10-13T08:31:18Z

Maybe some of the others on our team can help with this guidance? Otherwise we'll have to defer this by two weeks as I need to focus on a grant submission deadline. Sorry, but I simply don't have the capacity left as I am already behind.

… new-module-androidforeground

Please don't remove support for older versions. I still need to compile for at least API 19.

0-8-15 · 2020-11-30T18:39:40Z

BTW: I have to blame myself wrt. this module/PR no longer working since two days.

Apparently I managed to NOT include all the required files AND delete them after the move from the development directory into the pull request. Which amounts to me loosing a couple of days of research and testing.

I still need this to be resolved, but ... I'll have to redo it. This testing area was yet under version control even in the private branch. Too bad. My bad.

mgorges · 2020-11-30T19:31:20Z

Sorry to hear that - I can relate how frustrating this is; the last time I did something like it TimeMachine saved me but that was lucky as my work machine didn't have it.

0-8-15 · 2020-12-02T13:07:24Z

Replacement version in PR #404

0-8-15 · 2020-12-02T13:24:20Z

Closing in favor of #404

0-8-15 added 3 commits August 28, 2019 14:46

Improve handling of battery optimization.

e1c7758

See comments in ANDROID_xml_permissions and ANDROID_java_activityadditions how to compile for older API versions and possible issues wrt. restrictions regarding google play store.

Improve handling of battery optimization.

9334b10

See comments in ANDROID_xml_permissions and ANDROID_java_activityadditions how to compile for older API versions and possible issues wrt. restrictions regarding google play store.

Merge branch 'new-module-androidforeground' of github.com:0-8-15/lamb…

d3ed90f

…danative into new-module-androidforeground

0-8-15 added 4 commits August 29, 2019 17:33

Use trick to conditionally compile some code for ANDROIDAPI>22.

72ec450

Do not break syntax highlighting by ifdef alike trick.

0d3f3d0

Slightly improve the generated comments.

09167de

0-8-15 mentioned this pull request Aug 29, 2019

Handle compilation and permissions for ANDROIDAPI>22. #257

Merged

mgorges mentioned this pull request Oct 8, 2020

Redirect log messages from Java into LambdaNative log file #358

Open

mgorges mentioned this pull request Oct 8, 2020

ANDROID: No longer receiving EVENT_IDLE for API26+ #339

Open

karliwalti mentioned this pull request Oct 8, 2020

CAMERA / ANDROID: external services no longer available #354

Closed

0-8-15 mentioned this pull request Oct 12, 2020

BUILD: export well known build parameters to gambit compiler #367

Merged

0-8-15 added 2 commits October 13, 2020 16:08

Merge branch 'master' of https://github.com/part-cw/lambdanative into…

d4089a9

… new-module-androidforeground

ANDROID: a foreground service

38875f8

Please don't remove support for older versions. I still need to compile for at least API 19.

0-8-15 mentioned this pull request Dec 2, 2020

ANDROID: new module androidforeground (replace #256) #404

Open

0-8-15 closed this Dec 2, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

A ForegroundService for Lambdanative. #256

A ForegroundService for Lambdanative. #256

0-8-15 commented Aug 19, 2019

mgorges commented Aug 19, 2019

mgorges commented Aug 19, 2019

0-8-15 commented Aug 19, 2019 via email

mgorges commented Aug 19, 2019

0-8-15 commented Aug 20, 2019 via email

0-8-15 commented Aug 20, 2019 via email

mgorges commented Aug 21, 2019

0-8-15 commented Aug 28, 2019

mgorges commented Aug 28, 2019

bclayton05 commented Aug 28, 2019

mgorges commented Aug 30, 2019

0-8-15 commented Sep 2, 2019 •

edited

Loading

0-8-15 commented Sep 2, 2019

mgorges commented Sep 2, 2019

mgorges commented Sep 2, 2019 •

edited

Loading

0-8-15 commented Sep 3, 2019

mgorges commented Sep 4, 2019

0-8-15 commented Sep 5, 2019 via email

0-8-15 commented Sep 5, 2019 via email

mgorges commented Sep 5, 2019 •

edited

Loading

mgorges commented Sep 5, 2019

0-8-15 commented Sep 5, 2019 via email

0-8-15 commented Sep 6, 2019 via email

mgorges commented Oct 8, 2020

0-8-15 commented Oct 8, 2020 via email

mgorges commented Oct 8, 2020

0-8-15 commented Oct 12, 2020 via email

mgorges commented Oct 13, 2020

0-8-15 commented Nov 30, 2020

mgorges commented Nov 30, 2020

0-8-15 commented Dec 2, 2020

0-8-15 commented Dec 2, 2020

A ForegroundService for Lambdanative. #256

A ForegroundService for Lambdanative. #256

Conversation

0-8-15 commented Aug 19, 2019

mgorges commented Aug 19, 2019

mgorges commented Aug 19, 2019

0-8-15 commented Aug 19, 2019 via email

mgorges commented Aug 19, 2019

0-8-15 commented Aug 20, 2019 via email

0-8-15 commented Aug 20, 2019 via email

mgorges commented Aug 21, 2019

0-8-15 commented Aug 28, 2019

mgorges commented Aug 28, 2019

bclayton05 commented Aug 28, 2019

mgorges commented Aug 30, 2019

0-8-15 commented Sep 2, 2019 • edited Loading

0-8-15 commented Sep 2, 2019

mgorges commented Sep 2, 2019

mgorges commented Sep 2, 2019 • edited Loading

0-8-15 commented Sep 3, 2019

mgorges commented Sep 4, 2019

0-8-15 commented Sep 5, 2019 via email

0-8-15 commented Sep 5, 2019 via email

mgorges commented Sep 5, 2019 • edited Loading

mgorges commented Sep 5, 2019

0-8-15 commented Sep 5, 2019 via email

0-8-15 commented Sep 6, 2019 via email

mgorges commented Oct 8, 2020

0-8-15 commented Oct 8, 2020 via email

mgorges commented Oct 8, 2020

0-8-15 commented Oct 12, 2020 via email

mgorges commented Oct 13, 2020

0-8-15 commented Nov 30, 2020

mgorges commented Nov 30, 2020

0-8-15 commented Dec 2, 2020

0-8-15 commented Dec 2, 2020

0-8-15 commented Sep 2, 2019 •

edited

Loading

mgorges commented Sep 2, 2019 •

edited

Loading

mgorges commented Sep 5, 2019 •

edited

Loading