Great question! Let's break down how to tackle line/branch coverage testing and static analysis for the entire AOSP codebase—even with 2018's modern tooling—and walk through how to integrate this into your Jenkins pipeline. I've worked with AOSP CI setups before, so I'll share practical, actionable steps below:

Recommended Tools #

• gcov/lcov: The default choice for C/C++ code in 2018 AOSP (most components used GCC then). It integrates directly with the build system and generates easy-to-read HTML reports.
• llvm-cov: If you're compiling AOSP with Clang (already supported in 2018), this is the LLVM ecosystem's equivalent to gcov/lcov, with better support for modern C++ features.
• Jacoco: For Java/Kotlin code (Framework, system apps, etc.), Jacoco is the standard tool to capture line and branch coverage. AOSP has built-in support for it.

Implementation Path (Simple to Complex) #

Quick Local Testing (For Validation) #

1. Enable coverage flags during compilation:
   • For C/C++ code: Add these lines to your target's Android.mk or Android.bp (or globally in build/core/config.mk for full codebase coverage):

     LOCAL_CFLAGS += -fprofile-arcs -ftest-coverage
     LOCAL_LDFLAGS += -fprofile-arcs -ftest-coverage
     

   • For Java code: Inject the Jacoco agent with:

     mma WITH_JACOCO=true
     

2. Run your tests: This could be unit tests, manual system/feature testing, or automated instrumented tests.
3. Generate reports:
   • C/C++: Use lcov to collect data and generate HTML output:

     lcov --capture --directory . --output-file coverage.info
     genhtml coverage.info --output-directory out/coverage-report
     

   • Java: Use the Jacoco CLI to parse execution data into a report:

     java -jar jacococli.jar report jacoco.exec --classfiles out/target/common/obj/JAVA_LIBRARIES/your-module_intermediates/classes --html out/java-coverage-report
     

Jenkins Pipeline Integration (Full CI/CD) #

1. Prepare Jenkins Nodes: Ensure your nodes have enough resources—AOSP requires at least 16GB RAM (32GB+ recommended) and 200GB+ disk space. Install all AOSP build dependencies (Python 2.7, GCC/Clang, etc.).
2. Write Your Pipeline Script:
   • Step 1: Sync the latest AOSP code with repo sync.
   • Step 2: Compile with coverage flags—pass them via environment variables to avoid modifying build files:

     export EXTRA_CFLAGS="-fprofile-arcs -ftest-coverage"
     export EXTRA_LDFLAGS="-fprofile-arcs -ftest-coverage"
     m WITH_JACOCO=true
     

   • Step 3: Run automated tests—use atest to execute unit/instrumented tests, or spin up an emulator to run system-level tests.
   • Step 4: Collect and archive reports: Use Jenkins' archiveArtifacts step to save coverage reports and test logs.
   • Step 5: Optional: Integrate with a code quality platform (like SonarQube) to track coverage trends over time.

Tools & Execution #

• clang-tidy: For C/C++ code, enable it during compilation with:

  mma CLANG_TIDY=true
  

• Checkstyle: AOSP has a built-in Checkstyle config for Java code—run it with:

  m checkstyle
  

• SpotBugs: Scan Java code for potential bugs (replaced FindBugs in 2018) with:

  mma WITH_SPOTBUGS=true
  

• Android Lint: For Android-specific issues in Framework and app code, generate reports with:

  m lint
  

Best Practices #

• Module-wise Execution: AOSP is massive—running full static analysis takes hours. Split it into modules (e.g., Framework, Kernel, System Apps) and run them in parallel in your pipeline.
• Threshold Alerts: Set up Jenkins to fail the pipeline if static analysis finds new critical issues (like null pointer dereferences or memory leaks).

You don't need Android Studio or any IDE for CI/CD workflows—all tools work via the command line, which is ideal for Jenkins pipelines. That said:

• Android Studio can help with local debugging: Import the AOSP project (using the official AOSP import plugin) to view coverage reports and static analysis results directly in the IDE.
• VS Code with AOSP plugins can handle code browsing and basic static analysis, but core build/test/coverage tasks still rely on command-line tools.

CTS is great for compliance, but there are other options for custom testing:

• ATest: AOSP's official test runner—supports unit tests, instrumented tests, and custom test suites. It's more flexible than CTS for targeted testing.
• Trade Federation: The underlying framework for CTS. You can use it to build your own system-level test suites tailored to your AOSP modifications.
• Robolectric: Runs Android Java unit tests without an emulator/real device—perfect for fast, iterative testing and coverage data collection.
• Custom Instrumented Tests: Write your own instrumented tests, install them via adb, and run them on emulators/devices to collect coverage for specific components.

• Incremental Builds: Use m instead of make clean to leverage incremental builds—this cuts down build time drastically. Do a full clean build occasionally to ensure coverage data is accurate.
• Parallelize Tasks: Run static analysis, test execution, and report generation in parallel stages to reduce overall pipeline duration.
• Resource Management: Use Jenkins node labels to assign AOSP builds to dedicated high-resource nodes—don't waste resources on underpowered machines.
• Alerting: Set up email/Slack alerts for pipeline failures, test failures, or critical static analysis issues to catch problems early.

内容的提问来源于stack exchange，提问作者Ventto