Android实现同时安装测试环境与生产环境包,及区分app名和图标

简介: 众所周知,相同包名的APP,是不能同时安装的,但是我们实际开发中,测试同学往往在测试环境没问题,上了生产环境,却发现了bug,这时候就只能卸载生产环境的包,再去安装测试环境。

***Android***实现同时安装测试环境与生产环境包

众所周知,相同包名的包名的APP,是不能同时安装的,但是我们实际开发中,测试同学往往在测试环境没问题,上了生产环境,却发现了bug,这时候就只能卸载生产环境的包,再去安装测试环境。如果没有开发流程中缺少自动化打包或者测试同学不保存蒲公英二维码,这时候就会产生多余时间成本。那么有没有一种可能,同时安装测试与生产环境的包呢?

这个当然是可以的,我们更换包名就行了,Android Studio早已为我们准备了相应的操作:

很简单,就一句,给你的app, buildTypes -debug下面增添加如下代码:

applicationIdSuffix ".debug"

相当于在打包时,会为debug的包原包名后增加 .debug.

实际代码演示

    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            debuggable true
            zipAlignEnabled true  //是否支持zip
            resValue("string", "ENVIRONMENT", "RELEASE")
            buildConfigField "boolean", "LOG_DEBUG", "false"
            resValue "string", "name", "release"
            resValue "int", "logo", "release"
            signingConfig signingConfigs.release
        }
        debug {
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            minifyEnabled false
            zipAlignEnabled true
            debuggable true
            applicationIdSuffix ".debug"
            resValue("string", "ENVIRONMENT", "DEBUG")
            resValue "string", "name", "debug"
        }
    }

以上操作适用于大部分同学,但如果你的APP中含有 ContentProvider或者FileProvider(Android7.0文件适配必备),也就是和包名相关的;或者你想更直接点,直接区分测试与生产的app名及图标,那么你可能需要如下操作了:

常见问题

APP含有ContentProvider

实际场景:华为推送
<provider
            android:name="com.huawei.hms.update.provider.UpdateProvider"
            android:authorities="com.test.app.hms.update.provider"
            android:exported="false"
            android:grantUriPermissions="true" /> <!-- 应用下载服务 -->

当我们的项目中包含华为push时,往往会有如上代码,此时如果不处理包名,就会出现同时只能安装一个APP,否则adb就会提示 com.huawei.hms.update.provider.UpdateProvider 已存在(使用adb命令,adb install …apk 这样会详细提示)。

处理方式:

       <provider
            android:name="com.huawei.hms.update.provider.UpdateProvider"
            android:authorities="${applicationId}.hms.update.provider"
            android:exported="false"
            android:grantUriPermissions="true" /> 

APP含有FileProvider

实际场景:Android7.0文件适配
<provider
            android:name="androidx.core.content.FileProvider"
            android:authorities="${applicationId}"
            android:exported="false"
            android:grantUriPermissions="true">
            <meta-data
                android:name="android.support.FILE_PROVIDER_PATHS"
                android:resource="@xml/filepaths" />

适配也很简单,将 authorities="" 里的包名改为 ${applicationId} 即可

补充进阶

动态替换app名,图标

都到这一步了,那不如更友好点,让测试同学更好辨认:

修改app.build文件

 buildTypes {
        release {
            ...
            manifestPlaceholders = [icon: "@mipmap/logo",
                                    //这里也可以加入FileProvider的不同包名
                                    //例如: fileProvider: "com.petterp.release.provider"
                                    //根据自己的需求来定
                                    name: "生产环境"]
            ...
        }
        debug {
            ...
            manifestPlaceholders = [icon: "@mipmap/logo_debug",
                                    //这里也可以加入FileProvider的不同包名
                                    //例如: fileProvider: "com.petterp.debug.provider"
                                    //根据自己的需求来定
                                    name: "测试环境_debug"]
            ...
        }
    }

这里不同的配置,区分线上和测试。当然照葫芦画瓢,我们还可以定义更多测试与生产的不同数据,这个根据自己的需求即可。


然后修改AndroidManifest如下

image.png

效果如下:

image.png

好了,实现了,还是挺简单,是不是很直观了。

需要注意的地方

叮叮当

如果你的APP内含含有分享或者推送,那么测试版如果与线上用的是同一个appid与servert,那么测试版可能都会失败,当然这也很正常(如果不是同一个,自己处理下即可,怎么处理呢,楼下截图)。所以这点需要注意,逻辑上的功能都没什么问题。

如果不是同一个id,处理方式如下

同样是buildType下更改debug和release,分别对应的不同id,

  ...
  buildConfigField "String", "BaseUrl", "\"https://www.google.com/\""
  buildConfigField "String", "webUrl", "\"https://www.google.com/""
   buildConfigField "String", "wxAppid", "aasdadasdadadasda"

使用时如下:

class Test {
    fun test() {
        BuildConfig.webUrl
        BuildConfig.BaseUrl
    }
}

这样在打包时相应的id就会自动对应。省的自己判断了。

目录
相关文章
|
1月前
|
测试技术
软件测试区分:条件组合覆盖、语句覆盖、判定覆盖、条件覆盖、路径覆盖
本文解释了软件测试中的不同覆盖标准,包括语句覆盖、判定覆盖、条件覆盖、条件组合覆盖和路径覆盖,并讨论了每种覆盖标准的特点、优点和缺点。
464 62
|
2月前
|
IDE Android开发 iOS开发
深入解析Android与iOS的系统架构及开发环境差异
本文旨在探讨Android和iOS两大主流移动操作系统在系统架构、开发环境和用户体验方面的显著差异。通过对比分析,我们将揭示这两种系统在设计理念、技术实现以及市场策略上的不同路径,帮助开发者更好地理解其特点,从而做出更合适的开发决策。
155 2
|
7天前
|
Java 测试技术 持续交付
【入门思路】基于Python+Unittest+Appium+Excel+BeautifulReport的App/移动端UI自动化测试框架搭建思路
本文重点讲解如何搭建App自动化测试框架的思路,而非完整源码。主要内容包括实现目的、框架设计、环境依赖和框架的主要组成部分。适用于初学者,旨在帮助其快速掌握App自动化测试的基本技能。文中详细介绍了从需求分析到技术栈选择,再到具体模块的封装与实现,包括登录、截图、日志、测试报告和邮件服务等。同时提供了运行效果的展示,便于理解和实践。
33 4
【入门思路】基于Python+Unittest+Appium+Excel+BeautifulReport的App/移动端UI自动化测试框架搭建思路
|
1月前
|
安全 Android开发 数据安全/隐私保护
探索安卓与iOS的安全性对比:哪个更适合企业环境?
在数字化时代,移动设备已成为企业日常运营不可或缺的一部分。选择合适的操作系统对于保障企业数据安全至关重要。本文深入分析了Android和iOS两大主流操作系统的安全性,从系统架构、安全功能、应用生态及更新频率四个维度进行全面比较,旨在为企业提供一个清晰的决策依据,帮助企业在Android的开放性与iOS的封闭性之间找到最适合自身需求的平衡点。
57 6
|
2月前
|
Dart 开发工具 Android开发
在 Android 系统上搭建 Flutter 环境的具体步骤是什么?
在 Android 系统上搭建 Flutter 环境的具体步骤是什么?
|
2月前
|
测试技术
基于LangChain手工测试用例转App自动化测试生成工具
在传统App自动化测试中,测试工程师需手动将功能测试用例转化为自动化用例。市面上多数产品通过录制操作生成测试用例,但可维护性差。本文探讨了利用大模型直接生成自动化测试用例的可能性,介绍了如何使用LangChain将功能测试用例转换为App自动化测试用例,大幅节省人力与资源。通过封装App底层工具并与大模型结合,记录执行步骤并生成自动化测试代码,最终实现高效自动化的测试流程。
|
2月前
|
测试技术 Shell Android开发
Android 性能测试初探 (六)
本节聊聊性能测试的最后一项- 流量,当然我所指的性能测试是针对大部分应用而言的,可能还有部分应用会关注网速、弱网之类的测试,但本系列文章都不去一一探讨了。
54 6
|
2月前
|
JavaScript 测试技术 Android开发
Android 性能测试初探 (四)
本文介绍了GPU在移动端性能测试中的重要性,并详细解释了过度绘制、帧率和帧方差的概念。针对GPU测试,文章列举了三项主要测试内容:界面过度绘制、屏幕滑动帧速率和平滑度。其中,过度绘制测试需遵循特定标准,而帧速率和平滑度测试则可通过软件或硬件方法实现。在软件测试中,使用Systrace插件和高速相机是两种常用手段。对于不同机型,帧率及帧方差的测试标准也需相应调整。
50 5
|
2月前
|
测试技术 Shell Android开发
Android 性能测试初探 (三)
本文承接《Android性能测试初探(二)》,深入探讨CPU与内存测试。介绍了移动端内存测试的重要性及其测试目标,并详细列举了不同状态下应用内存消耗情况的测试项目。此外,还提供了多种内存测试方法,包括使用`procrank`等工具的具体操作步骤。最后,文章也简要提及了CPU测试的相关内容,帮助读者更好地理解Android性能测试的关键要素。
49 5
|
2月前
|
测试技术 Shell 定位技术
Android 性能测试初探 (五)
聊聊大家不常关注的测试项- 功耗
48 3

热门文章

最新文章