1.aar是源码什么意思
2.AAR 包中的依赖
3.Android-gradle plugin
4.android开发aar安全么
5.发布库AAR至mavenCentral看这篇文章就可以了

aar是什么意思

       AAR是归档文件的扩展名。

       以下是替换关于AAR的详细解释：

       1. AAR文件的基本含义

       AAR是Android项目中用于存放编译后的类文件的归档文件的扩展名。它包含了应用程序的源码所有编译代码，是替换Android开发过程中非常重要的文件之一。开发者在开发过程中会经常与AAR文件打交道，源码因为它涉及到项目的替换碗底源码公式构建和依赖管理。

       2. AAR文件的源码作用

       在Android开发中，AAR文件主要用于以下几个方面：

       集成库依赖：开发者可以将第三方库或模块编译成AAR文件，替换然后在自己的源码项目中通过依赖的方式引入这些库或模块，无需关心其源代码。替换这样做的源码好处是简化了依赖管理，提高了开发效率。替换

       代码复用和模块化开发：AAR文件可以作为代码复用的源码媒介。开发者可以将一些通用的替换功能封装成模块，制作成AAR文件，源码然后提供给其他开发者使用。这种方式可以极大地提高开发效率和代码质量。

       跨平台兼容性：由于AAR文件是feed源码针对Android平台的，因此它具有跨平台的兼容性。无论是在哪个版本的Android设备上，只要安装了相应的应用程序，就可以使用AAR文件所包含的功能。

       3. AAR文件的创建和使用

       要创建和使用AAR文件，开发者需要使用Android Studio等开发工具进行编译和打包。在项目中，可以通过添加依赖的方式引入AAR文件。此外，还可以使用构建工具（如Gradle）来管理和处理AAR文件。在使用过程中，开发者需要注意文件的兼容性和版本问题，以确保项目的正常运行。

       总的来说，AAR文件在Android开发中扮演着重要的角色，它简化了依赖管理，提高了开发效率，云集 源码并促进了代码的复用和模块化开发。了解和使用AAR文件对于Android开发者来说是非常必要的。

AAR 包中的依赖

        在 aar 的源码中不论使用 implementation 或者 api ，打成 aar 包之后，当我们通过 gradle脚本上传到服务器时，我们可以通过 pom.project 来将 aar 源码中的依赖生成 pom.xml 文件。这些依赖配置项会通过脚本，被转义成 maven中的依赖配置项。脚本片段如下：

        上面是我们工程中的配置。在 pom.project 的配置中其实还可以添加 scope 配置选项，如果未显示指明，那么 scope 就是 compile 。因此，在未显示指明 scope 的情况下，aar 源码中无论是使用 implementation 还是 api ，最终在 maven中都会变为 compile 。

        所以在默认配置下，依赖在 maven 的 pom.xml 文件中都是存在的，且表述为 compile 。因此，当项目中通过 gradle使用 maven上的 aar 包时， pom.xml 文件中的依赖项就会被 gradle解析。而此时 gradle发现 maven上的依赖配置是 compile ，于是 gradle会将其解析为 api 配置。

        这就造成了，当我们在工程中直接依赖 aar 包时，aar 包中的依赖项因为被 gradle解析为 api ，因此在我们的工程中可以「看到」这些依赖项。

        但是，当我们在工程中通过源码直接使用 aar 的源码工程时，如果 aar 工程中的依赖是通过 implementation 配置的，那么我们工程中就「看不到」aar 中的依赖项了。

        这就导致了工程直接依赖 aar 和通过源码依赖 aar 时，他两的 gradle DAG不同，从而导致了一些编译上的不方便。

Android-gradle plugin

       agp,即Android-Gradle-Plugin的缩写，项目配置主要在根目录下的build.gradle文件中的dependencies中，配置classpath "com.android.tools.build:gradle:xxx"。在根目录的build.gradle文件中配置好agp后，就可以在任意module的build.gradle文件中apply Android提供的各种plugin。常见的有com.android.application和com.android.library。apply了com.android.application的module使用assemblexxx执行构建命令可打出来一个apk，而apply了com.android.library的module产物则是一个aar。apply java的module表示是个纯java的模块，打出的产物是个jar。

       基于gradle构建的项目基本结构包括根目录下的settings.gradle，用来配置项目中的子模块，使用include来引入子模块。如果子模块不在项目目录内，则可以在include之后使用project(":xxx").projectDir = new File("...")来指定外部module的蓝牙 源码路径。项目根目录下还有一个build.gradle文件，用来配置整个项目的基本依赖，如插件依赖，aar依赖的maven仓库地址等。

       根目录和每个module中都会有一个gradle.properties文件，用于配置一些key-value。构建脚本文件可以直接使用gradle.properties中的key-value配置，例如配置DEV_MODE=true，可在gradle文件中直接使用if ("true" == DEV_MODE) { xxx}。但需要注意的是，gradle.properties中配置的value会被当作字符串类型，即使写的是数字或true/false，也会被当作字符串处理。同时，配置的key-value被视为常量，不可修改，因此配置KEY的jsonpath源码名字时，应使用全大写。

       在项目根目录和每个module的gradle.properties文件中配置的key-value存在读范围问题和覆盖问题。子module可以读取本目录和父级目录下的gradle.properties中的key-value，但外部目录不能直接读取子目录下的gradle.properties文件。如果子目录下的gradle.properties文件中有相同的key值，则子目录中的value值将覆盖父级目录文件中的value值。在构建一个源码/aar切换的Andrid gradle项目时，可以通过在根目录的gradle.properties中配置全局参数，如构建用的Andrid SDK版本号、构建工具版本号和最低支持的系统版本号，而每个module的gradle.properties则可以为每个module配置其aar所需要的maven参数。

       应用插件源码中，一般来说只有壳module的build.gradle中会apply application插件，用于打出一个apk供用户安装。应用插件的实现类为AppPlugin，继承自AbstractAppPlugin，最终调用basePluginApply方法，其中重点调用ThreadRecorder创建了三个线程任务。ThreadRecorder#record中的逻辑是通过create方法设置各种id，并使用block.call方法调用write方法，write方法中调用了ProcessProfileWRiter的writeRecord方法，将GradleBuildProfileSpan添加到span队列中，最后在ProcessProfileWriter的finish方法中将相关信息全部写到日志文件中。

       BasePlugin中逻辑清晰，threadRecorder.record的逻辑就是调用最后一个lambda参数，包括configureProject、configureExtension和createTaskts。configureProject中创建了AndroidBuilder对象和初始化了DataBindingBuilder成员变量，配置了Java工程应该有的能力，如source、configureSourceSetDefaults、configureOutputDirectoryForSourceSet、createProcessResourcesTask、createCompileJavaTask、configureJavaDoc和configureTest等。

       configureBuildNeeded和configureBuildDependents方法分别配置了buildNeeded task和buildDependents task，确保build之后才能执行buildDependents。configureProject方法最后使用gradle.addBuildListener注册了构建监听器，在buildFinished回调中关闭所有进程。

       configureExtension创建了buildTypeContainer、productFlavorContainer、signingConfigContainer和buildOutputs四个容器，构建了一个extension对象，并用这个extention创建了variantFactory，为变体配置了buildType、productFlavor、signingConfig和buildOutputs。createTasks方法分为两部分，createTasksBeforeEvaluate构建前的准备工作，createAndroidTasks为真正的构建task。createAndroidTasks方法中，为每个变体调用了createTasksForVariantData方法，判断变体类型后调用taskManager.createTasksForVariantScope(variantScope)为变体配置了众多task，如assembleXXX的相关task，实现多渠道的核心功能。

android开发aar安全么

       èµ„源命名最好统统加上你的项目名字前缀，比如图片资源、string、color、dimens、layout等等，反正res目录下所有文件最好都使用统一的加前缀命名，防止跟宿主app下的资源重复

       å› ä¸ºaar引用跟源码引用起到的效果一样一样的，所有很容易出现资源重复引用的问题，所以加上前缀非常有必要。

发布库AAR至mavenCentral看这篇文章就可以了

       发布库AAR至mavenCentral看这篇文章就可以了

       在继续这篇文章内容之前，我们先回顾一下最初我们是怎么去打包一个aar，然后再复制粘贴到项目里面，如此反复的复杂操作，通过本文以后就不用再每次都单独拷贝aar出来了

       如何打包AAR在上篇已有详细介绍，具体参考：打包完成以后我们来接着介绍发布aar至中央仓的3种方式

       一：发布AAR至Bintray（不再推荐）

       采用bintray发布的方案，这种方式的引用需要配置jcenter()依赖关系。bintray是属于JFrog这家公司的，Google当年也是有很多开发库发布在这里的。随着jcenter的关闭，用bintray发布aar的方式我不再推荐，但是原文章我也保留纪念了。

       二：发布AAR至jitpack（推荐）

       采用github的分发方式，该方式的引用需要配置maven { url "jitpack.io" }的依赖。github是代码托管平台，大部分的项目都是发布至github.com的。这也是我推荐的一种方式。

       三：发布AAR至MavenCentral（推荐）

       需要配置mavenCentral依赖关系。由sonatype运营，重要性凸显，对于源代码有所保留的可以使用这种方式来发布你个人的开发库。操作步骤包括：

       注册sonatype账号

       创建一个issue

       创建GPG秘钥

       准备配置文件

       执行打包AAR和上传

       验证使用刚刚发布的Livery

       三方案总结：

       bintray：不再推荐，国内不可用，已停止维护。

       jitpack：利用github作为依托，易于分发。

       MavenCentral：安全性要求高，操作步骤详细，重要性提高。

       使用刚刚发布的库的步骤：

       在项目根目录的build.gradle中配置依赖

       在Item/app Module的build.gradle中引用库

       执行打包AAR和上传任务

       验证结果

       注意事项：

       注册账号时使用真实邮箱，密码复杂。

       创建GPG秘钥，保存相关信息。

       确保配置文件地址正确，注意网络问题。

       避免使用最后一个版本号作为依赖。

       综上所述，通过使用jitpack或MavenCentral，可以更高效、便捷地发布AAR至合适的仓库，以供团队使用。在选择发布方式时，应综合考虑项目需求、安全性要求和操作复杂度。