Skip to content

[Bug]: cap run fails with renamed outputs #8040

@davidgeary

Description

@davidgeary

Capacitor Version

Latest Dependencies:

@capacitor/cli: 7.4.0
@capacitor/core: 7.4.0
@capacitor/android: 7.4.0
@capacitor/ios: 7.4.0

Installed Dependencies:

@capacitor/ios: not installed
@capacitor/cli: 7.2.0
@capacitor/android: 7.2.0
@capacitor/core: 7.2.0

[success] Android looking great! 👌

Other API Details

`npm --version` output: 10.9.2
`node --version` output: v22.14.0

Platforms Affected

  • iOS
  • Android
  • Web

Current Behavior

In preparation for publishing an app to F-Droid, I've configured my gradle build to use a more descriptive output name, so the APK includes the version. To do this, I've added the following line to ~\android\app\build.gradle:

android {
    defaultConfig {
        ...
        archivesBaseName = "$applicationId-v$versionCode"
        ...

This means that the output APK is now named io.ionic.starter-1-debug.apk (for example), rather than app-debug.apk.

However, when I try to run the app via npx cap run android, it now fails with the error:

× Deploying app-debug.apk to 28231FDH200GGJ - failed!
[error] Selected hardware device 28231FDH200GGJ
        Error: ENOENT: no such file or directory, open 'C:\Dvt\myApp\android\app\build\outputs\apk\debug\app-debug.apk'

Expected Behavior

I would expect the CLI to determine the name of the APK built and use that, rather than expecting it to be app-debug.apk.

Project Reproduction

https://github.com/davidgeary/hardcoded-apk

Additional Information

A similar error about the CLI hardcoding the APK name was reported (and fixed) in #4740, but this was in regard to the configuration of flavours resulting in different APK names being generated and as such, the fix was very specific to the use of flavours.

But since the APK name can also be changed via the archivesBaseName setting and other ways, a more generic fix is required. For example, @dragermrb's suggestion of parsing ~\android\app\build\outputs\apk\debug\output-metadata.json appears to be a much more robust way of identifying the output from the build and would work regardless of the way the output filename was set.

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions