Problems to observe login_status of AccountLogin

Vega Open Beta Q&A
1

We are verifying the Account Login status our app reports to Fire TV. The signal is the
ContentAppEndpoint: ... partner_id=... login_status= line emitted by kcs-lib, and we cannot capture it.

Environment

  • Device: Fire TV Stick running Vega — product callie, armv7l, profile tv

  • OS: OS 1.2 (TV Ship/547) — OS_VERSION=1.2, RELEASE_ID=21, OE_VERSION=4.0.0,
    VERSION_NUMBER=2101020054720

  • BUILD_VARIANT=user, BUILD_TAGS=release-keys, inDeveloperMode: true

  • Vega CLI 1.2.22, SDK 0.22.6150

  • kcp-cli-v2 <VERSION> (downloaded from the forum thread)

vda shell journalctl --follow --since now | grep -E 'ContentAppEndpoint.*<PARTNER_ID>.*login_status'

No output. Without the grep: WARNING: journalctl is not supported in developer mode shell. Please use loggingctl instead.

image
image1156×964 103 KB

This worked a few months ago during our initial Content Launcher and Account Login integration, though we were using kcp-cli-v2 then rather than the log line. Retrying that route now gives the
No endpoint found result above. We cannot tell whether something changed in the expected
implementation that we are not aware of, or whether we are doing something wrong.

Questions:

  1. What is the supported way to observe that line ?

  2. Are application logs expected to be unavailable to the developer-mode shell on BUILD_VARIANT=user?

    If so, is there a provisioning step or an engineering build that makes them visible on a
    developer-registered device?

I can attach our manifest.toml or service.js if that helps rule out a configuration problem on our
side.

Thanks in advance.

4

Hi @Sergio_Gomez,

Thanks for the detailed writeup and the attempts table.

On a User build device with developer mode enabled, Account Login status is observable via different workaround and which our team is looking to add to developer documentation in upcoming days (like through testing via inbuilt CLI). Can you please try below workaround and let us know if it works?

Prerequisites:

  1. The app build must be a debug build. These are INFO-level logs and are suppressed on
    Release builds
  2. The line to watch is AccountLoginServer::updateStatus (and journalctl isn’t supported in the developer-mode shell, loggingctl is the right logging tool)

Test Steps:

  1. Start log monitoring in a separate terminal: Replace <APP_PACKAGE_ID> with your package name (e.g. com.partner.app).
    vega exec vda shell loggingctl log -f -v <APP_PACKAGE_ID> | grep -E 'AccountLoginServer::updateStatus'
  2. Uninstall the app if already installed: vega device uninstall-app --appName <APP_PACKAGE_ID>
  3. Install the debug variant: vega device install-app --packagePath <path-to-debug.vpkg inside the device>
  4. Launch the app, you should see: AccountLoginServer::updateStatus invoked. status: 1 ← represents signed in status as false
  5. Log in → AccountLoginServer::updateStatus invoked. status: 0 ← represents signed in status as true
  6. Log out → AccountLoginServer::updateStatus invoked. status: 1 ← represents signed in status as false

Status values:

  • 1 = signed out ( signed in status is false)
  • 0 = signed in ( signed in status is true)

Pass Critieria:

  • Pass - status changes 1 → 0 on login, and 0 → 1 on logout.

Troubleshooting:

  • No logs at all - the app is a Release build (INFO suppressed), or Account Login isn’t implemented.
  • Status doesn’t change - Account Login is implemented but not updating state on login/logout events.
  • These INFO-level logs only appear on debug app builds, regardless of OS variant. We’re also updating the public documentation to reflect this. Please give it a try and let us know how it goes.
  • Rebuild the app with below commands if you see any errors like "Cannot update status until a handler has been set" against your app on the full logs
  npm install @amazon-devices/kepler-media-account-login@1.1.22
  rm -rf node_modules package-lock.json && npm install
  npm ls @amazon-devices/kepler-media-account-login

Warm Regards,
Ivy

6

Hi @Ivy,

We ran the verification test on our current debug build using the command provided:

vega exec vda shell loggingctl log -f -v com.orange.es.amzftv | grep -E 'AccountLoginServer::updateStatus'

Observed Sequence

Each status transition is immediately accompanied by an ERROR log:

  • Launch (status: 1) → AccountLoginServer::updateStatus invoked. status: 1
  • Login (status: 0) → AccountLoginServer::updateStatus invoked. status: 0
  • Logout (status: 1) → AccountLoginServer::updateStatus invoked. status: 1

Each invocation triggers the following error:

ERROR ... AccountLoginServer::updateStatus failed to update status, error=KeplerScriptAccountLogin::updateStatus error in updating status

Full Log Excerpt

Sep 02 11:23:04 ... INFO  ... AccountLoginServer::updateStatus invoked. status:  1
Sep 02 11:23:04 ... ERROR ... AccountLoginServer::updateStatus failed to update status, error=KeplerScriptAccountLogin::updateStatus error in updating status
Sep 02 11:24:22 ... INFO  ... AccountLoginServer::updateStatus invoked. status:  0
Sep 02 11:24:22 ... ERROR ... AccountLoginServer::updateStatus failed to update status, error=KeplerScriptAccountLogin::updateStatus error in updating status
Sep 02 11:24:50 ... INFO  ... AccountLoginServer::updateStatus invoked. status:  1
Sep 02 11:24:50 ... ERROR ... AccountLoginServer::updateStatus failed to update status, error=KeplerScriptAccountLogin::updateString error in updating status

Questions

  1. Does this sequence match the expected pass criteria (1 → 0 on login, 0 → 1 on logout)?
  2. Should we treat the failed to update status error as expected behavior on this build, or indicates an issue?

Thanks!

7

Hi @Sergio_Gomez

Answering the 2 questions you added here:

  1. Does this sequence match the expected pass criteria (1 → 0 on login, 0 → 1 on logout)?*
    A> Yes, the sequence should look like this.
  2. Should we treat the failed to update status error as expected behavior on this build, or indicates an issue?
    A> Along with the above sequence, we should not see this error. If we see this error, above status will not bind correctly. In this case you should run below to fix this error:
npm install @amazon-devices/kepler-media-account-login@1.1.22
rm -rf node_modules package-lock.json && npm install
npm ls @amazon-devices/kepler-media-account-login

Warm regards,
Ivy

8

Hi @Ivy,

Thanks again for the guidance so far — following up with the results after applying the fix you suggested, plus a new detail I’d like to confirm with you.

What we did

Our package.json had @amazon-devices/kepler-media-account-login pinned to the range ^1.1.0, which after a clean reinstall (rm -rf node_modules package-lock.json && npm install) resolved to 1.1.24 instead of 1.1.22. We pinned it to the exact version you recommended:

npm install @amazon-devices/kepler-media-account-login@1.1.22
rm -rf node_modules package-lock.json && npm install
npm ls @amazon-devices/kepler-media-account-login

npm ls now confirms 1.1.22 is installed. We rebuilt the debug variant, uninstalled/reinstalled on the Fire TV device, and re-ran the verification.

Result — the original error is gone

Running the exact command from your instructions:

vega exec vda shell loggingctl log -f -v com.orange.es.amzftv | grep -E 'AccountLoginServer::updateStatus'

Before (version 1.1.24), every transition looked like this:

Sep 02 11:23:04 ... INFO  ... AccountLoginServer::updateStatus invoked. status:  1
Sep 02 11:23:04 ... ERROR ... AccountLoginServer::updateStatus failed to update status, error=KeplerScriptAccountLogin::updateStatus error in updating status

After pinning 1.1.22, the ERROR ... failed to update status line no longer appears on launch, login, or logout.

New detail we’d like you to confirm

However, the log output itself looks different now, and we want to make sure we’re not missing something. With 1.1.22, using both the exact grep from your instructions and a broader case-insensitive one (grep -iE 'accountlogin|account\.login|account_login'), we no longer see:

  • The native line AccountLoginServer::updateStatus invoked. status: X (with the status value), or
  • Any log at all from the com.amazon.kepler.media.account.login component (the one that previously logged the error=... line).

Instead, the only lines we see on every login/logout are:

Sep 04 14:06:02.116931 ... INFO KeplerScript.TurboModule: KeplerScriptAccountLogin::updateStatus invoked.
Sep 04 14:06:02.119363 ... INFO KeplerScript.TurboModule: KeplerScriptAccountLogin::updateStatus completed.

No status value, and no line from the AccountLoginServer/account.login native provider at all — just the TurboModule bridge invoked/completed pair.

Questions

  1. Is this a known/expected change in logging format for 1.1.22 (i.e., the native provider-level status: X log line was replaced by the TurboModule invoked/completed pair in this version), or should we still expect to see the AccountLoginServer::updateStatus invoked. status: X line with the exact same format as before?
  2. Given completed. appears with no error, can we treat this as equivalent confirmation that the status update succeeded and is bound correctly — even without the explicit status: X value in the log — or is there another way to verify the actual 1→0 / 0→1 transition on this version?

We don’t want to close this out as fully verified until we’re sure the log change is expected and not masking a different issue.

Thanks again for your help, Sergio

9

Hi @Sergio_Gomez , to double check are you using the debug build of your app while checking the logs.