Global on/off toggle?

[Aditya94A]

I like to use monkey to stress test my UIs and if used with Hyperion, the monkey keeps getting distracted, so to speak, by Hyperion most of the time and doesn't actually spend much time on the actual app's UI.

I would love a global on/off switch. Either as a gradle property or by referencing Hyperion somewhere in code.

[ToxicBakery]

This sounds like something you should be using build variants for instead of depending on the library directly for support.

https://developer.android.com/studio/build/build-variants

[tir38]

I have a similar situation and build variants wont' help us. Our use case is that we need to turn Hyperion on for a select few "real" users of our Play Store apk.

[ToxicBakery]

Sounds like you mean non dev users which means people that should not really be using Hyperion. Hyperion is for devs not for end users to help report issues.

[Aditya94A]

@ToxicBakery I was thinking more along the lines of something like Hugo's implementation.

https://github.com/JakeWharton/hugo

hugo {
  enabled false
}

If you want to toggle logging at runtime, use Hugo.setEnabled(true|false)

This is pretty much perfect and should serve all use cases including @tir38's

Sounds like you mean non dev users which means people that should not really be using Hyperion. Hyperion is for devs not for end users to help report issues.

I send a hyperion enabled build to the QA team at my workplace so they can easily record and report bugs.

Yes, they can record using something else. But that's not the point. The point is to keep an open mind about what hyperion can mean in different circumstances and if a minor change can help serve a larger audience, then what's the harm?

[mrk-han]

I send a hyperion enabled build to the QA team at my workplace so they can easily record and report bugs.

QA are definitely considered under the dev blanket, and are a perfect use-case of Hyperion. QA are not end users.

FWIW, Hugo is specifically stated to be used in Debug builds.

[ToxicBakery]

Yes, they can record using something else. But that's not the point. The point is to keep an open mind about what hyperion can mean in different circumstances and if a minor change can help serve a larger audience, then what's the harm?

It's not "harm", it's adding a feature that can already be accomplished by other means.

I have a similar situation and build variants wont' help us. Our use case is that we need to turn Hyperion on for a select few "real" users of our Play Store apk.

This is the real issue to be solved. Why exactly will build variants not work for you? As for targetting real users, you can accomplish this with beta/alpha channels. I'm assuming you mean you want to do something like if (user.isHyperionEnabled) Hyperion.setEnabled(true) however you can not simply turn Hyperion off due to how its implementation works. At best the service could have its enabled flag turned off after install and then the notification removed but you would initially still be delivering it to all users even if only very briefly.

---

Does anyone have a precise example of why build variants are not a suitable solution? And continuing, a precise example of how/why a gradle flag or runtime method would circumvent the defined issue?

[tir38]

This is probably specific to my case so...

Like @AdityaAnand1 I send builds to QA and designers, but I do it through the Play Store alpha/beta channels, so it has to be a release variant. Our other build variants can't go on the play store (either cause they have different appIDs, signing keys, or we just don't want to risk them getting out into the wild).

I don't fully understand how Hyperion hooks into my app ATM, but IIUC it's all about starting or not starting HyperionService, right? You start that service at app launch. Can you just "wait" and start that service inside your hypothetical Hyperion.setEnabled(true)?

[tir38]

Although... the more I think about it, I don't really want Hyperion code adding to my apk size for all users (which will happen). So I probably need a different way to solve my problem (which is ultimately not Hyperion related).

[ToxicBakery]

You can create multiple release variants so a hyperion release variant is possible though I understand any related concerns here and I would note some features of hyperion are going to work poorly combined with obfuscated code typical of a release build.

As for how hyperion generally works you can read my explanation in issue 96. When I said service before I meant content provider and because of the order of operations content providers are started even before your application class is created meaning a runtime opt in is not possible without first allowing hyperion to build itself up then 'turn it off' and thus tear it all down again at least on the first app start.

[tir38]

I know I wasn't the original poster but you've addressed my concerns; I'd be ok if you chose to close this issue.

[eduardbosch-jt]

I was having problems launching the UI tests with Hyperion because it was reporting that there was a leak after each test with ActivityScenario. Sometimes the UI tests crashed when I had Hyperion enabled too.

I've removed the Hyperion library when the executing Gradle task is an AndroidTest task:

dependencies {
...
    if (!isAndroidTest()) {
        debugImplementation libs.bundles.hyperion
    }
...
}

def isAndroidTest() {
    Gradle gradle = getGradle()
    String tskReqStr = gradle
            .getStartParameter()
            .getTaskRequests()
            .toString()

    return Pattern
            .compile("AndroidTest")
            .matcher(tskReqStr)
            .find()
}

Just in case someone wants to disable the library without creating a new flavor or release variant.