CVE-2026-28613 AI-generated analysis

platform/packages/apps/TV (Live TV), channel app links (src/com/android/tv/data/ChannelImpl.java)

AI-generated: written from the bulletin and the fixing diffs by claude-fable-5-1, then checked against the code by claude-opus-5-5 (5 corrections). Verify against the commit before relying on it.

ChannelImpl.initAppLinkTypeAndIntent in the Live TV app now refuses to build a channel app-link Intent whose resolved target activity is exported and declares an android:permission. This is in addition to the existing rejection of activities inside the TV app's own package.

Root cause

ChannelImpl.initAppLinkTypeAndIntent parses the channel's mAppLinkIntentUri with Intent.parseUri(..., Intent.URI_INTENT_SCHEME) and resolves it via intent.resolveActivityInfo(pm, 0). Before the fix, the only filter rejected targets whose packageName equals CommonConstants.BASE_PACKAGE or starts with it plus '.' (the TV app itself). Any other resolvable activity was accepted as mAppLinkIntent with mAppLinkType = APP_LINK_TYPE_CHANNEL. That included exported activities guarded by an android:permission. The commit title calls this 'Intent Redirection to permission protected Activities'.

How the fix works

• src/com/android/tv/data/ChannelImpl.java:initAppLinkTypeAndIntent: after resolving activityInfo, the method computes boolean isPermissionProtected = activityInfo.exported && (activityInfo.permission != null).
• If isPermissionProtected is true, it logs 'Attempt to add app link to permission protected activity: <uri>' and returns. mAppLinkType stays APP_LINK_TYPE_NONE and mAppLinkIntent stays null (the values set at the top of the method), so no app link is created for that channel.
• The existing isProtectedActivity (BASE_PACKAGE) check is kept and evaluated first. The new check is a second, independent early return placed before mAppLinkIntent is assigned and the EXTRA_APP_LINK_CHANNEL_URI extra is added.
• A code comment records a decision not to also restrict chooser Intents or ACTION_SEND. Its reasons: with Intent.parseUri an attacker cannot wrap Intent.EXTRA_INTENT in the app link, and ACTION_SEND was tested not to yield FLAG_GRANT_* here.
• Single commit, single hunk. The Log.w formatting change is cosmetic.

Completeness

• Covers: app-link targets resolved from mAppLinkIntentUri whose ActivityInfo is exported and has a non-null permission string. The existing check still covers any target inside the TV app's own package.
• Does not cover: exported targets with no permission attribute, which remain allowed. The check looks only at the resolved activity's own permission attribute. This diff does not sanitize Intent flags or extras in the parsed URI.
• Chooser and ACTION_SEND Intents are deliberately left unrestricted. The comment's justification is based on testing, not enforced in code.
• Only the APP_LINK_TYPE_CHANNEL branch shown in the diff changes. The rest of initAppLinkTypeAndIntent (after line 710) is not in the material, so other app-link type branches cannot be judged.

Behavior changes

• Channels whose app-link intent URI resolves to an exported, permission-protected activity now get no app link: getAppLinkType returns APP_LINK_TYPE_NONE and getAppLinkIntent returns null, instead of an Intent.
• A new Log.w warning, 'Attempt to add app link to permission protected activity: ...', is logged in that case.
• Any channel whose app link legitimately targeted an exported, permission-protected activity loses that app link.

Per major

• Android 14: Same fix: platform/packages/apps/TV e64e4b90fc77 in android-security-14.0.0_r29 (diff index 5be1179d..62c06cc2), carrying Cherrypick-From references to two internal changes.
• Android 15: Same fix: platform/packages/apps/TV 481a7a588acd in android-security-15.0.0_r17, identical diff and blob hashes.
• Android 16: Same fix: platform/packages/apps/TV 86fb106012ec in android-security-16.0.0_r8, identical diff and blob hashes.
• Android 17: Same fix: platform/packages/apps/TV a10682aac138 in android-security-17.0.0_r1, identical diff and blob hashes.

Unknowns

• Where mAppLinkIntentUri and mAppLinkText come from, and who can write them.
• Where and with what flags the Live TV app launches mAppLinkIntent (the startActivity call site is not in the material).
• Which permissions the Live TV app holds that made the redirection valuable. The bulletin only gives High / EoP.
• The rest of initAppLinkTypeAndIntent after line 710 (other app-link type branches).
• Details of the original report in bug 329233015 and of the two internal cherry-pick sources.

Back to September 2026 · Findings