当前位置: 首页 > 知识库问答 >
问题:

Android wear项目有3种风格、3种构建类型和2个应用程序补丁

翟越
2023-03-14

当我构建我的项目后,试图结合WeadApp口味和构建类型与应用程序IdSuffix,我得到以下错误消息:

Error:Execution failed for task ':app:handleFirstCustomerTestMicroApk'.
> The main and the micro apps do not have the same package name.

从我的应用程序/构建。格雷德尔:

buildTypes {
    debug {
        applicationIdSuffix '.debug'
        debuggable true
        embedMicroApp = true
    }
    customerTest {
        applicationIdSuffix '.customertest'
        debuggable true
        embedMicroApp = true
    }
    release {
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        minifyEnabled true
        embedMicroApp = true
    }
}

productFlavors {
    first {
        applicationId 'com.my.app.first'
    }
    second {
        applicationId 'com.my.app.second'
    }
    third {
        applicationId 'com.my.app.third'
    }
}

dependencies {
    firstWearApp project(path: ':wear', configuration: 'firstDebug')
    firstWearApp project(path: ':wear', configuration: 'firstCustomerTest')
    firstWearApp project(path: ':wear', configuration: 'firstRelease')

    secondWearApp project(path: ':wear', configuration: 'secondDebug')
    secondWearApp project(path: ':wear', configuration: 'secondCustomerTest')
    secondWearApp project(path: ':wear', configuration: 'secondRelease')

    thirdWearApp project(path: ':wear', configuration: 'thirdDebug')
    thirdWearApp project(path: ':wear', configuration: 'thirdCustomerTest')
    thirdWearApp project(path: ':wear', configuration: 'thirdRelease')
}

从我的穿着/身材来看。格雷德尔:

buildTypes {
    debug {
        applicationIdSuffix '.debug'
        minifyEnabled false
    }
    customerTest {
        applicationIdSuffix '.customertest'
        minifyEnabled false
    }
    release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
}
productFlavors {
    first {
        applicationId 'com.my.app.first'
    }
    second {
        applicationId 'com.my.app.second'
    }
    third {
        applicationId 'com.my.app.third'
    }
}

android {
    publishNonDefault true
}

从这些代码中我知道

  • Android wear应用程序打包失败,味道不佳
  • 佩戴应用程序,并使用applicationIdSuffix定制构建类型
  • https://code.google.com/p/android/issues/detail?id=74658

如果我删除了ApplicationIDSuffix,那么保持以上9个wearApp依赖项都会起作用,但不管我在Android Studio中选择哪种构建类型,它仍然会为每个构建类型构建一个wear apk,我真的需要ApplicationIDSuffix。

有人能解决这个问题吗?从今天起,每当我需要更改构建类型和/或风格时,我都会手动添加和删除wearApp依赖项,从长远来看,这并不是一个我满意的解决方案。

编辑:一开始我并没有注意到这一点,但出于某种原因,firstDebug、secondDebug和thirdDebug版本的变体在版本中与所有9个wearApp依赖项都很好。格雷德尔。但firstCustomerTest、firstRelease、secondCustomerTest、secondRelease、thirdCustomerTest和thirdRelease的错误消息保持不变。所有变体每次编译9个WearApp,将其精简为1个。


共有1个答案

庄萧迟
2023-03-14

根据这篇帖子

试试这个

configurations {
    firstDebugWearApp
    firstCustomerTestWearApp
    firstReleaseWearApp
    secondDebugWearApp
 ...//  And all the others
}
  dependencies {
        firstDebugWearApp project(path: ':wear', configuration: 'firstDebug')
        firstCustomerTestWearApp project(path: ':wear', configuration: 'firstCustomerTest')
        firstReleaseWearApp project(path: ':wear', configuration: 'firstRelease')

        secondDebugWearApp project(path: ':wear', configuration: 'secondDebug')
        secondCustomerTestWearApp project(path: ':wear', configuration: 'secondCustomerTest')
        secondReleaseWearApp project(path: ':wear', configuration: 'secondRelease')

        thirdDebugWearApp project(path: ':wear', configuration: 'thirdDebug')
        thirdCustomerTestWearApp project(path: ':wear', configuration: 'thirdCustomerTest')
        thirdReleaseWearApp project(path: ':wear', configuration: 'thirdRelease')
    }
 类似资料:
  • 对于 SELinux 来说,所选择的策略类型直接决定了使用哪种策略规则来执行主体(进程)可以访问的目标(文件或目录资源)。不仅如此,策略类型还决定需要哪些特定的安全上下文属性。通过策略类型,读者可以更精确地了解 SELinux 所实现的访问控制。 SELinux 提供 3 种不同的策略可供选择,分别是 Targeted、 MLS 以及 MiNimum。每个策略分别实现了可满足不同需求的访问控制,因

  • (1). 项目使用技术 基于Python语言,版本:>=3.5及以上。 使用Django框架,版本:1.11.11的LTS版本。 MySQL数据库 连接数据库:pymysql=0.8.0 图像处理: Pillow=5.0.0 Web前端技术:HTML、CSS、JavaScript和Jquery等 (2). 项目的目录结构 本次项目共计四个应用:myadmin、web、common和ueditor

  • 我在symfony 3中遇到了防火墙问题。三天以来,我一直在努力解决这个问题。我已经阅读了文档,并根据它做了所有事情,但应用程序并没有像我预期的那个样工作。 目标:所有页面(登录页面除外)都需要登录用户。如果用户未登录,则应将其重定向到/login页面。这就是全部。 根据这几页: http://symfony.com/doc/current/book/security.html http://sy

  • 通过前面的讲解,我们了解了 Sanic 的运行方式以及编写一个好的配置方案,是不是想要立马编写一个应用练练手呢?别急,请先看完这一章节,了解一下你要写的应用得用什么样的结构。 在 github 上也看了不少的 Python 项目吧,相信你也清楚,一个项目,在最外层他们应该是一样的,简单概括下,大概是下面这样的结构: pro_name ├── docs # 项目文档说明 ├

  • 程序目录结构 SpeedPHP框架的目录结构比较简单,秉承了SpeedPHP快速学习的理念。 新版的sp框架,由于加入了mudules开发模式,所以在目录结构方面,趋于更精炼,更固定化。 3.1版及之前的sp框架,目录结构是可以通过配置进行修改。 但是新版的情况不一样了。 之所以我们要用固定的目录结构,理由如下: 加入mudules开发模式,使得多个应用可以集成到一个程序里面,也就是传统的模块开发

  • 问题内容: 任何人都可以向我解释,除了主要的和特定于风味的java / src目录之外,我如何能更多地用于每种风味?我的目标是拥有不只一种口味但并非全部使用的目录。 例如,我有3种口味:A1,A2和B。 所有忙都使用main / src(默认的主src目录) A1使用A1 / src(默认的src目录) A2使用A2 / src(默认的src目录) B使用B / src(默认的src目录) A1和