Daemon quits?

[kabukky]

In #4 it sounds like the daemon is running independently from the android app process.

On my Nvidia Shield TV, the daemon seems to quit automatically after a while (let's say after an hour, haven't measured it yet). I'm not downloading anything, it is just idling.

In the browser, I get a connection error (i. e. the server is not running):

Communication error!

Cannot establish connection to NZBGet.

When I open the NZBGet app after this, I can start the daemon again - meaning it really is closed by then.

The nzbget.log is not showing any error. Just the start message.

Are you sure the the process is not being killed by Android (see #4)? Since the Process is started by a ProcessBuilder (https://github.com/nzbget/android/blob/master/app/src/main/java/net/nzbget/nzbget/Daemon.java#L69), could it be that it is started as a child process of the android app that is terminated with the app?

I will try to investigate more. Would the debug daemon help with this?

[hugbug]

First of all I must say that I don't use NZBGet on Android. The android app was written on user requests a few years ago. The feedback has been so little that I have an impression that no one uses it.

When the app was initially developed for Android 2.3-4.0 the daemon process wasn't terminated when the app was closed. With the recent version of app on Android 7 the daemon terminates if the app exits. I don't know if that's the Android version or because the startup code has been changed.

Previously it was:

Process proc = Runtime.getRuntime().exec(cmdLine);

and now it's:

ProcessBuilder builder = new ProcessBuilder(DAEMONSH, command);
builder.redirectErrorStream(true);
Process process = builder.start();

If you know how to solve the problem, either by changing the startup code or by preventing the app from terminating, I'll be happy to merge your PR.

[kabukky]

@hugbug I'll look into it, thanks!

[kabukky]

I've create a foreground Service that lives in a separate process and handles starting/stopping the daemon.

I think this is the way to go, since Android will rarely stop foreground processes.

I've also set the Service to START_REDELIVER_INTENT which in theory should restart the service if it is stopped by the system. However, I couldn't test it yet:

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        // Handle command
        String command = intent.getExtras().getString("command");
        switch (command) {
            case "start":
                startDaemon();
                break;
            case "stop":
                stopDaemon();
                break;
            default:
                showMessage("NZBGet daemon service received an unknown command.");
                break;
        }

        // If we get killed, restart and redeliver the intent
        return START_REDELIVER_INTENT;
    }

The only downside would be a permanent notification icon in the status bar (required for foreground services I think).

[kabukky]

This and other things are implemented in #9. Sadly, some meta files were changed by my Android Studio that were not caught by the .gitignore. Please tell me if I should do something to make the PR less verbose (update .gitignore).

[hugbug]

Merged your PR and removed unnecessary user specific files from source control. Thanks for your work!

One question: currently click on the notification icon opens Android system dialog for the running process. Is it possible to make the click open the app instead? That'd be handy since the app offers shutdown button (for proper shutdown) and a button to open web-ui.

[kabukky]

That should be possible. I'll look into it and create another PR.

[hugbug]

OK, closing this issue then.

Unrelated: would you like to contribute more? What about making the UI nicer? It's strictly functional at the moment. I have no Android dev experience and my design taste is almost non-existent. If you interested we could open an issue to discuss improvement ideas.

[kabukky]

Sure, I'd like that. Don't count on me when it comes to design, I'm probably as bad as you. But I have quite a bit of Android dev experience that I can contribute.