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.

11

Hey @Sergio_Gomez

Checking again.
Are you using the debug build of your app while checking the logs?

Warm Regards,
Ivy

12

Hi @Ivy @Ramachandran
I’m testing with the debug version. I also updated the SDK version—just in case—and updated the dependencies in the package.json (amzn → amazon-devices), but the command now returns nothing.

13

Thanks @Sergio_Gomez - could you help us provide below items to investigate further.

  1. Full logs ( capturing from : Debug vpkg install → sign-in → sign out → again sign-in )
  2. OS version details
  3. Manifest file if possible
14

Hi , attaching what you asked for.

  1. Full logs captured with logging started before the uninstall, then: uninstall → install debug vpkg → launch → sign in → sign out → sign in.
  • vega exec vda shell loggingctl log -f -v com.orange.es.amzftv
  1. Versions
  • Device: firestick-61dc7f4262e3ee0e
  • OS version: OS 1.2 (TV Ship/44)
  • Vega SDK: 0.24.9914
  • @amazon-devicesamazon-devices/kepler-media-account-login: 1.1.22
  • Build: Debug, armv7. Package declares os_versions [“1.2”], contract_package_version 1.0.323.0
  1. Manifest
15

Thanks for sharing this @Sergio_Gomez , wanted to double check on couple of things again

  1. can you please share complete OS version (similar to once you added in initial description)

  2. When you login with creds, were you able to see the buybox change in the content detail page in the universal search for titles from Orange TV ( subscribe → watch now)

Also, while we are checking internally with engineering team and get back on the same,

I am attaching an analysis

Accout_login_not_printing_status.md (8.9 KB) from our externalized builder tool MCP ( you can also try on your end to go through Content launcher and account login implementation in your code project to see if the implementation is correct)

16

Hi @Ramachandran,

  1. OS version:
  • OS 1.2 (TV Ship/44) — OS_VERSION=1.2, RELEASE_ID=23, OE_VERSION=4.0.0,
    BRANCH_CODE=TV Ship, VERSION_NUMBER=2301020004420
  • BUILD_FINGERPRINT=4.0.454119.0(3072cab629675a74)/44N:user/release-keys
  • BUILD_VARIANT=user, BUILD_TAGS=release-keys, inDeveloperMode: true
  • Fire TV Stick, product callie, armv7l, profile tv
  • Vega CLI 1.2.22, SDK 0.24.9914, kepler-media-account-login 1.1.22, Debug armv7

(My first post reported RELEASE_ID=21 / TV Ship/547; the device has since taken an OS
update.)

  1. Buybox: I cannot check it. No OrangeTV titles appear in universal search on this device
    at all, so there is no content detail page to open. A colleague running the same build on
    a whitelisted device does see our content.

From your analysis, the real finding was the manifest routing, now fixed:

before: override_attribute_component = { Status = “com.orange.es.amzftv.main.interface.provider” }
after: override_attribute_component = { Status = “com.orange.es.amzftv.interface.provider” }

With the app-side logging added, the push side passes. Capture from launch → sign in →
sign out (consecutive duplicate lines removed):

status 1 at launch (13:53:51), 0 on sign in (13:55:06), 1 on sign out (13:55:30). No
errors, and KeplerScriptAccountLogin::updateStatus completed. with no error following it.
handleReadStatus is still never invoked, even after the routing fix.

Could you confirm whether this device (firestick-61dc7f4262e3ee0e) is enrolled for the
OrangeTV catalog integration? If it is not, it explains what is still open: nothing
triggers a Status read, and our service component is a singleton started on demand, so it
never starts either.

17

Thanks @Sergio_Gomez , seems like we have a good improvement there. if you have a full logs that also would help confirm if status is correctly being set.

when you say your colleague can see the orange TV titles but you cannot, then we may need to allow-list your DSN for the orange tv catalog. can you share your DSN ( Settings → Fire TV → About → Device Serial Number) , we can double check and put in a request so that titles can appear and you can check the buybox ( subscribe to watch now) .
meanwhile, you can use your collegue’s device to test this buybox scenario if possible.

18

Hi @Ramachandran , thanks.

DSN:
Full logs:

Unfiltered, covering launch → sign in → sign out → sign in on the current debug build (SDK 0.24.9914, kepler-media-account-login 1.1.22, armv7), with the manifest routing fix in place.
The AccountLoginServer::updateStatus lines are printed by our own wrapper, following the convention from your sample apps, since KCP itself does not log the value.

19

Thanks @Sergio_Gomez , have put in request for allow-listing your DSN for orange tv catalog to test on vega devices. will update once it is done.

20

Hi @Ramachandran ,
We have performed a check on the whitelisted device and wanted to confirm if this behavior is correct so we can close the ticket.

After logging into the application and searching for content—specifically the series Watson—we see two screens:

Image (3)
Image (3)1920×1081 441 KB

Is this the expected behavior?

Thanks.

21

yes, this is the right behavior @Sergio_Gomez . we are good to close this