Skip to content

Align log configuration to three-input model #139

@AlexSc

Description

@AlexSc

Summary

Local and remote log configuration is closer to the target model than iOS but has several issues:

  • Bug: DebugConfiguration constructor line 61 uses this.logLocal for both parameters to setLoggingEnabled() — the second should be this.logRemote
  • Teak.forceDebug (from ?teak_log=true URL parameter) is folded into the initial SharedPreferences read but lost on the first setLogPreferences call from a server response, making it unreliable
  • setLogPreferences persists the forceLocalLogging-adjusted value rather than the raw server value, creating stale state if the force resource is later removed
  • No equivalent of iOS's TeakSetDebugOutputEnabled (this is fine — keeping it simple)

Target Model

Three clear inputs, OR'd together:

effectiveLogLocal = isDevelopmentBuild
                  | forceLocalLogging (Android resource io_teak_force_debug_output)
                  | server["verbose_logging"] (persisted, updated on server response)

Same model for remote logging:

effectiveLogRemote = isDevelopmentBuild
                   | server["log_remote"] (persisted, updated on server response)

Key changes

  1. Fix constructor bug. Line 61 of DebugConfiguration.java:

    // Current (bug):
    Teak.log.setLoggingEnabled(this.logLocal || this.isDevelopmentBuild, this.logLocal || this.isDevelopmentBuild);
    // Fixed:
    Teak.log.setLoggingEnabled(this.logLocal || this.isDevelopmentBuild, this.logRemote || this.isDevelopmentBuild);
  2. Remove Teak.forceDebug / ?teak_log=true support. It only works for cold launches and gets silently overridden by the first server response. The problems it solves are already covered by isDevelopmentBuild (integration) and forceLocalLogging (QA builds). Removing it simplifies the init path.

  3. Persist raw server values, not the forceLocalLogging-adjusted ones. In setLogPreferences, persist logLocal before applying this.forceLocalLogging, not after. This prevents stale true values in SharedPreferences when the force resource is later removed.

  4. Evaluate effective state from current inputs. The pattern should be:

    • setLogPreferences stores raw server values to SharedPreferences and to layer 2 fields
    • setLoggingEnabled is called with (rawLogLocal || forceLocalLogging || isDevelopmentBuild, rawLogRemote || isDevelopmentBuild)
    • Same evaluation at init when reading persisted values

Current behavior to preserve

  • isDevelopmentBuild (FLAG_DEBUGGABLE) is a floor — dev builds always log, server can't turn it off
  • forceLocalLogging (io_teak_force_debug_output resource) is a floor for local logging — survives server responses
  • Server can both enable AND disable logging (last-write-wins, which is already correct)
  • Persisted preferences provide logging continuity across cold starts
  • isLoggable gate for local output (Android convention, no change needed)
  • Log listener fires regardless of local/remote config (orthogonal, no changes needed)

Related

This is being done in coordination with GoCarrot/teak-ios to align both platforms to the same model.


Repo: teak-android

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions