tree: c6f9e23d5ca6a9e2d0737e0b3ca2b10eb10581fd [path history] [tgz]
  1. files/
  3. nnapi-0.0.2-r3.ebuild
  4. nnapi-9999.ebuild

NNAPI Updating Instructions

Quick Note

If you're just updating code within platform2/nnapi, skip down to Uprev the ebuild.


To fully update the NNAPI dependencies, the following repos need to be addressed:

  • aosp/platform/frameworks/native
  • aosp/platform/system/core/libcutils
  • aosp/platform/system/core/libutils
  • aosp/platform/system/libbase
  • aosp/platform/system/libfmq
  • aosp/platform/system/libhidl
  • aosp/platform/system/logging

Most of these can be updated by merging the upstream branch of the repo into the master branch. There are however, two cases where this does not apply.

The Two Copybara Cases

The NNAPI package depends on some repo‘s that are copybara’d from another repo.

Specifically, the following repos:

  • aosp/system/core/libcutils
  • aosp/system/core/libutils

Are updated by a copybara process from aosp/platform/system/core.

You can see the status of this process on the Copybara dashboard.

In short, whenever the master branch of aosp/platform/system/core is updated, the copybara process will (at some point in the future), propagate those changes into aosp/system/core/libcutils and aosp/system/core/libutils.

This means that we can't directly control when the downstream repo will get updated by the copybara process. It is possible that builds of NNAPI will start failing if the infrastructure tries to uprev NNAPI to use updated versions of libcutils and libutils that are possibly incompatible.

Due avoid this, and ensure we have explicit control over which version of these copybara‘d directories is built, we have introduced CROS_WORKON_MANUAL_UPREV to the NNAPI package which means we need to manually update the commit and tree id’s of the non-9999 ebuild. This decouples the updating of aosp/platform/system/core from the NNAPI package.


Update the forked repositories

RepoLocal DirUpstream Branch


  1. Change into the repo local directory
  2. Create a merge branch from master
  3. Do a non-ff git merge from the upstream branch into master
  4. repo upload to gerrit and process the CL as normal
  5. At this stage you don‘t need to make any code changes due to CROS_WORKON_MANUAL_UPREV. The package won’t use this updated code yet.


cd src/aosp/system/libbase
git checkout -b merge cros/master
# This will ask for an appropriate commit msg
git merge cros/upstream/master --no-ff
# This may give you a scary warning about the number of commits. Say 'y'.
repo upload --cbr . --no-verify

Update the aosp/system/core repo

As described earlier, aosp/system/core/libcutils and aosp/system/core/libutils are updated by merging upstream into the master of aosp/platform/system/core. This is a bit more involved than the previous cases, since this repo isn‘t mapped into the ChromeOS tree. It’s quite similar though...


  1. Check out the core repo.
  2. Create a merge branch from origin/master.
  3. Do a non-ff git merge from origin/upstream.
  4. Upload to gerrit.
  5. Force submit / ‘chump’ the change since CQ won't process it.
  6. Within a few minutes, copybara should update libcutils and libutils.
  7. Check the Copybara dashboard.
cd /tmp
git clone
# Set up the commit hooks
cd core
f=`git rev-parse --git-dir`/hooks/commit-msg
mkdir -p $(dirname $f)
curl -Lo $f
chmod +x $f
# Done setting up the repo
git checkout -b merge
git merge origin/upstream --no-ff
# This will ask for an appropriate commit msg
git commit
# This will upload to gerrit
git push origin HEAD:refs/for/master

Uprev the ebuild

Once you have any code changes and dependencies submitted via CQ, do a repo sync and you‘ll be able to uprev the ebuild. This is important, since you will not be able to get the git commit id’s you need until this is done.

There is a script in this directory, that will print out the two lines you need to replace.


  1. Run
  2. Rename nnapi-0.0.2-r<N>.ebuild to nnapi-0.0.2-r<N+1>.ebuild.
  3. Replace CROS_WORKON_COMMIT and CROS_WORKON_TREE in that ebuild with the output of the script.
  4. Fix any build issues by creating ebuild patches (see the files dir).
  5. Upload to gerrit and review as normal.