将供应商的Android更改集成到aosp中 [英] integrating vendor Android changes into aosp

问题描述

我试图将AOSP设备更改集成到标准的AOSP本地镜像中。这有点令人困惑，但我会尽可能地澄清。

1. 我创建了AOSP回购的本地镜像在服务器上（不同的本地计算机）




2. 供应商补丁基于标签android-4.3_r2.1。所以我初始化了一个本地仓库并修改了清单文件。

repo init -u ssh：// localserver / git / aosp / mirror / platform / manifest -b android-4.3_r2.1

更改.repo / manifest.xml如下：

 < remote name =aosp
 fetch =ssh：// localserver / git / aosp / mirror/> 
< default revision =refs / tags / android-4.3_r2.1
 remote =aosp
 sync-j =8/> 
  

3. repo sync成功完成。应用供应商提供的补丁。这为每个由修补程序修改和/或添加的git项目创建了一个分支供应商。

现在我有一个基于标签android-4.3 _r2.1，一些项目有一个分支供应商。没有一个项目有master分支！




您如何将所有这些结合在一起以创建一个可用的存储库？我仍在学习。这是正确的吗？

 回购签出refs / tags / android-4.3_r2.1 
回购forall -c git checkout -b master 
 repo forall -c git merge vendor 
  







5. 最后一个问题是使用repo将更改推送到本地镜像。看起来，只有在使用gerrit服务器时，repo upload才有效。这真的有必要吗？



TIA

解决方案

无需更改清单以指向您的Git服务器。 android-4.3_r2.1清单中的 .. URL意味着git URL将与清单的URL相关。换句话说，如果你从你的本地镜像克隆了清单，剩下的git也会从你的本地镜像中获取。





当你在讨论供应商和主分支我假设你在谈论本地分支（即在 git分支输出中可见）。在这个答案中，我将忽略这些，只会谈论遥控器上的分支。他们是重要的。通过回购，您在默认情况下不会获得任何本地分行，任何本地分行的名称都取决于每个人。





我很确定您的每一个分行项目有一个主分支 - 在aosp远程。我建议你从你的供应商那里选择另一个分支名称作为你的修改和补丁。事实上，完全选择一个不同的命名空间是明智的。如果您的公司或组织被命名为Acme，则可以将所有分支置于acme /，acme / master，acme / vendor等。 （我更喜欢这样做，即将上游分支填充到单独的命名空间中，如aosp /和caf /。这样，实际上工作的分支没有前缀，并且可以有多个上游。）





将所有这些都放到工作仓库中将涉及更新清单以指向您正在工作的分支。如果您将本地供应商分支推送至acme / vendor，则清单应该指向acme / vendor。您需要决定是否在每个git中创建一个acme / vendor分支，并更改清单中的缺省修订版本，或者如果您只想将分支推到实际需要的地方，并有选择地覆盖这些gits的修订版本。 p>



后者显然需要您每次分支git时更新清单。另一方面，你不会乱丢所有不必要的分支，你可以快速浏览清单文件，看看哪些分支是分支，哪些分支是直接来自上游。另外，如果你分支所有的gits，从上游抓取一个新版本可能需要更多的工作。请记住，上游可能切换到另一个分支作为git，因此即使对于尚未触及的gits，您也可能获得非快速前向更新。下面的例子显示了如何无法将acme / master从1.2.3更新为1.2.4，因此您需要进行非快速转发更新（通常不推荐），从1.2开始合并。 3转换为acme / master（可能的结果和冲突，永远无法进行快速更新），或者创建一个基于1.2.4的新分支。



 < code ---- ----- 1.2.3（acme / master）----- 1.2.4 
 // 
 -------------- ---------------------- 
  

不要忘记分支清单。 Repo以一种特殊的方式处理manifest git，它假设所有更改都是在名为default的分支上进行的。因此，只需编辑清单文件，提交更改，然后用例如 git push origin HEAD：refs / heads / acme / master 。之后，您可以使用 repo init -u ... -b acme / master 来初始化一个新的工作空间。





是的， repo upload 用于Gerrit，你当然不需要（虽然我推荐它用于代码审查功能）。你可以像平常那样用Git来推动。我发现你已经找到了 repo forall 命令，这非常有用。




I am trying to integrate AOSP device changes into a standard AOSP, local mirror. This is a bit confusing but I will try to be as clear as possible.

1. I created a local mirror of the AOSP repo on a server (different local computer)

2. The vendor patches are based on a tag "android-4.3_r2.1". So I initialized a local repo and modified the manifest file.

repo init -u ssh://localserver/git/aosp/mirror/platform/manifest -b android-4.3_r2.1

Changed .repo/manifest.xml as follows:

  <remote  name="aosp"
           fetch="ssh://localserver/git/aosp/mirror" />  
  <default revision="refs/tags/android-4.3_r2.1"
           remote="aosp"
           sync-j="8" />

3. "repo sync" completed successfully. Applied the patch provided by the vendor. This created a branch "vendor" for each git project modified and/or added by the patch.

4. Now I have a repo based on tag "android-4.3_r2.1", some projects have a branch "vendor". None of the projects have a "master" branch!

How do you bring all this together to make a workable repository? I am still learning. Would this be correct?

repo checkout refs/tags/android-4.3_r2.1
repo forall -c git checkout -b master
repo forall -c git merge vendor

5. The last issue is using repo to push the changes to our local mirror. It appears that repo upload only works if you are using a gerrit server. Is this really necessary?

TIA

解决方案

There's no need to change the manifest to point to your Git server. The .. URL that's in the android-4.3_r2.1 manifest means that the git URLs will be relative to the manifest's URL. In other words, if you clone the manifest from your local mirror the remaining gits will also be fetched from your local mirror.

When you're talking about vendor and master branches I'm assuming you're talking about local branches (i.e. visible in the git branch output). In this answer I'm going to ignore those and only talk about branches on the remote. They're the ones that matter. With Repo you don't get any local branches by default and the name of any local branches is up to every individual.

I'm pretty sure every single one of your projects have a master branch – on the "aosp" remote. I suggest you pick another branch name for your adaptations and the patches you get from your vendor. In fact, it's wise to choose a different namespace altogether. If your company or organization is named Acme you can place all your branches under acme/, so acme/master, acme/vendor, and so on. (I prefer doing it the other way around, i.e. stuffing the upstream branches into separate namespaces, like aosp/ and caf/. That way the branches that you actually work on don't have a prefix and you can have multiple upstreams.)

Getting all this into a working repository will involve updating the manifest to point to the branches on which you're working. If you push your local vendor branch to acme/vendor, then the manifest should point to acme/vendor. It's up to you whether to create an acme/vendor branch in every single git and change the default revision in the manifest or if you want to push the branch only where it actually needs to exist and selectively override the revision for those gits.

The latter obviously requires you to update the manifest every time you branch a git. On the other hand you won't be littering all gits with unnecessary branches, and you can quickly glance over the manifest file and see which gits are branches and which ones come straight from the upstream. Also, grabbing a new release from the upstream will likely require more work if you branch all gits. Keep in mind that the upstream might switch to another branch for a git so you may get non-fast forward updates even for gits that you haven't touched. The example below shows how how can't update acme/master from 1.2.3 to 1.2.4 as a fast forward, so you'll either have to make a non-fast forward update (generally not recommended), merge from 1.2.3 into acme/master (possible resulting and conflicts and forever making fast forward updates impossible), or create a new branch based off of 1.2.4.

         -----1.2.3 (acme/master)     -----1.2.4
        /                            /
 ------------------------------------

Don't forget to branch the manifest. Repo handles the manifest git in a special way where it assumes that all changes are made on the branch named "default". So, just edit the manifest file, commit your changes, and push it with e.g. git push origin HEAD:refs/heads/acme/master. After that you can initialize a new workspace with repo init -u ... -b acme/master.

Yes, repo upload is for use with Gerrit, which you certainly don't need (though I recommend it for its code review features). You can just push with Git like you normally would do. I see you've already found the repo forall command which is quite useful.

这篇关于将供应商的Android更改集成到aosp中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！