If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/yixia/VitamioBundle shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 9y ago

• 8 active contributors
• Other licensed
• Tests present
• ⚠ Stale — last commit 9y ago
• ⚠ Concentrated ownership — top contributor handles 76% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live yixia/VitamioBundle repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/yixia/VitamioBundle.

What it runs against: a local clone of yixia/VitamioBundle — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in yixia/VitamioBundle | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 3332 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of yixia/VitamioBundle. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/yixia/VitamioBundle.git
#   cd VitamioBundle
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of yixia/VitamioBundle and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "yixia/VitamioBundle(\\.git)?\\b" \\
  && ok "origin remote is yixia/VitamioBundle" \\
  || miss "origin remote is not yixia/VitamioBundle (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 3332 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3302d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/yixia/VitamioBundle"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Vitamio is a hardware-accelerated multimedia framework for Android that wraps FFmpeg 2.0 with native binaries (libvinit.so) to enable video/audio playback with features like adaptive bitrate streaming, subtitle support, playback speed control (0.5x–2.0x), and local video caching. It eliminates the need to bundle full FFmpeg by providing pre-compiled ARM, x86, and MIPS decoder libraries across multiple architecture flavors (arm_x86, arm_x86_mips, online_arm) distributed in dist/. Two-module structure: vitamio-sample/ is a reference Android app demonstrating playback, while the core library binaries live in dist/ organized by architecture flavor (dist/arm_x86/, dist/arm_x86_mips/, dist/online_arm/), each containing platform-specific libvinit.so files under libs/{armeabi,armeabi-v7a,x86,mips}/ and a raw resource libarm.so. The top-level build.gradle and gradle.properties define the project version and group; vitamio-sample/build.gradle imports the library.

Android app developers building media players or video streaming apps who need production-grade hardware decoding without writing native C/FFmpeg bindings themselves. Specifically those targeting multiple CPU architectures (ARMv6, ARMv7, x86, MIPS) and requiring features like HTTPS/RTMPS streaming and custom HTTP headers.

This is a mature but aging project (last visible activity unclear from file timestamps, but FFmpeg 2.0 base is from ~2013–2014 era). The codebase contains 304KB of Java code and pre-compiled binaries for multiple Android architectures, suggesting production use. However, no visible CI/CD configuration, test directory, or changelog entries beyond CHANGELOG.md indicate declining maintenance. The README references an external wiki and Google+ community, suggesting it was actively maintained 5–10 years ago but may lack active development now.

High risk for modern Android development: depends on a 10-year-old FFmpeg version (2.0) with unpatched CVEs, no visible dependency management beyond Gradle, and targets deprecated Android tooling (gradle 0.12.+, legacy project.properties in vitamio-sample/). The dist/ architecture contains pre-compiled .so binaries with no visible build scripts or source, making it impossible to audit or rebuild them. Single-maintainer risk is evident (yixia org with no visible org structure).

No active development visible from the file list. The CHANGELOG.md and README suggest this was a feature-complete project circa 2013–2014 (FFmpeg 2.0 integration, MIPS/x86 support, subtitle handling). No open PRs, issues, or recent commits are evident from the static snapshot. The repository appears to be in maintenance mode or abandoned.

git clone https://github.com/yixia/VitamioBundle.git
cd VitamioBundle
./gradlew build
# or to build the sample app:
cd vitamio-sample
../gradlew assembleDebug

Daily commands: The library itself is not runnable; instead, integrate it into your app or run the sample: ```bash cd vitamio-sample ../gradlew installDebug adb shell am start -n io.vov.vitamio.demo/.MainActivity

• build.gradle: Root Gradle configuration defining the project version, group, and build classpath; essential for understanding how vitamio-sample and distribution variants are assembled.
• vitamio-sample/AndroidManifest.xml: Sample app manifest showing required permissions (INTERNET, WRITE_EXTERNAL_STORAGE) and the main activity entry point for demonstrating Vitamio playback.
• vitamio-sample/build.gradle: Sample app build script; shows how to depend on the Vitamio library and which architecture flavor (arm_x86, arm_x86_mips, online_arm) to include.
• dist/arm_x86/libs/armeabi-v7a/libvinit.so: The primary Vitamio decoder library for ARMv7 devices; this is the actual multimedia engine wrapping FFmpeg.
• dist/arm_x86/res/raw/libarm.so: Embedded ARM decoder binary distributed as a raw resource; loaded at runtime to enable hardware-accelerated playback on ARM devices.
• gradle.properties: Project-wide Gradle properties file; likely contains VERSION_NAME and GROUP referenced in build.gradle, defining the library version.
• README.md: High-level overview of features (FFmpeg 2.0, HTTPS/RTMPS, subtitles, caching, speed control) and link to external wiki documentation.

For sample app changes: Edit vitamio-sample/src/main/java and vitamio-sample/res/. For library integration into your own app: Add dist/{arm_x86,arm_x86_mips,or online_arm}/ as a dependency in your build.gradle and call Vitamio APIs (see vitamio-sample/ for usage patterns). Warning: Core libvinit.so binaries in dist/*/libs/ cannot be modified without rebuilding FFmpeg native code (no build scripts provided).

No source code for native binaries: dist/ contains only pre-compiled .so files with no visible build scripts (e.g., Android NDK makefiles, CMakeLists.txt, or build instructions). Rebuilding or patching FFmpeg is not possible from this repo alone. Gradle version mismatch: build.gradle specifies gradle 0.12.+, which is obsolete; modern Android Studio will reject this or require migration. Architecture flavor selection: You must choose one flavor (arm_x86, arm_x86_mips, or online_arm) for your app build; mixing or conditional loading logic is not visible in the file list, requiring manual configuration. No test suite: No src/test/ or androidTest/ directory visible, meaning no unit or integration tests to validate library behavior. Missing dependency declarations: build.gradle does not show explicit Android SDK version, support library versions, or FFmpeg/OpenSSL version constants.

• Hardware Video Decoding (MediaCodec) — Vitamio's core value is hardware-accelerated decoder support via native binaries; understanding MediaCodec (Android's hardware codec interface) helps explain why libvinit.so can offload decoding to the SoC instead of the CPU.
• NDK Native Binaries (.so files) — Vitamio ships as pre-compiled ARM/x86/MIPS .so libraries, requiring understanding of how the Android NDK packages and loads native code; critical for debugging crashes or adding custom FFmpeg features.
• Adaptive Bitrate Streaming (ABR) — Vitamio's feature list highlights support for adaptive bitrate streaming; understanding HTTP-based ABR (HLS, DASH) helps explain why Vitamio bundles OpenSSL for HTTPS/RTMPS and custom HTTP headers.
• FFmpeg Codecs and Containers — Vitamio wraps FFmpeg 2.0, which decodes hundreds of video/audio codecs and containers (MP4, MKV, WebM, HLS, RTMP, etc.); knowing which codecs FFmpeg 2.0 supports is essential for troubleshooting playback failures.
• APK Binary Compression and Architecture Selection — Vitamio offers three dist/ variants (arm_x86, arm_x86_mips, online_arm) to balance APK size vs. device coverage; understanding multi-architecture APK strategies (AAB, per-ABI splits) affects deployment decisions.
• CPU Instruction Sets (ARMv6, ARMv7, x86, MIPS) — Vitamio's multi-architecture support (libvinit.so compiled for armeabi, armeabi-v7a, x86, mips) requires understanding processor instruction set compatibility; critical for selecting the right flavor and debugging arch-specific crashes.
• Subtitle Rendering and External Subtitle Files — Vitamio's feature list mentions improved subtitle support including external bitmap subtitles; understanding how subtitle tracks are demuxed, parsed, and overlaid on video frames is important for media player features.

• google/ExoPlayer — Modern Android video player library with hardware decoding, media composition, and DRM support; the recommended replacement for Vitamio on current Android versions.
• bilibili/ijkplayer — Fork of FFmpeg/FFplay optimized for Android video streaming with similar architecture (native binaries + Java wrapper); active community alternative to Vitamio.
• mpv-android/mpv-android — Android wrapper around libmpv with hardware acceleration; another mature FFmpeg-based player for comparison.
• FFmpeg/FFmpeg — The upstream multimedia framework that Vitamio bundles as native binaries; understanding FFmpeg options and filters is essential for extending Vitamio's codec/streaming capabilities.
• android/media-samples — Official Google Android media samples demonstrating MediaPlayer, MediaCodec, and ExoPlayer; useful for understanding modern Android multimedia APIs beyond Vitamio's legacy approach.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions CI workflow for building and testing sample app

The repo has outdated Gradle config (gradle:0.12.+) and multiple dist variants (arm_x86, arm_x86_mips, online_arm) but no CI pipeline. New contributors can't verify builds work across variants. Adding a GitHub Actions workflow would catch build breakages early, especially important given the complex native library dependencies across different CPU architectures.

• [ ] Create .github/workflows/android-build.yml
• [ ] Add build steps for vitamio-sample/build.gradle with each dist variant configuration
• [ ] Configure matrix strategy to test arm_x86, arm_x86_mips, and online_arm variants
• [ ] Add linting checks using vitamio-sample/lint.xml rules
• [ ] Document in README.md how to run builds locally for each variant

Create architecture-specific unit tests for native library loading

The dist/ folder contains multiple CPU architecture variants (armeabi, armeabi-v7a, x86, mips) with native .so files. There are no visible tests verifying that libvinit.so and libarm.so load correctly on each architecture. This is critical since the README mentions 'Support more hardwares, e.g. X86 or MIPS' but there's no test coverage.

• [ ] Create vitamio-sample/src/androidTest/ directory
• [ ] Add NativeLibraryLoadingTest.java to verify libvinit.so loads on current device architecture
• [ ] Add architecture detection tests to verify arm/x86/mips detection logic
• [ ] Document expected behavior for each architecture variant in vitamio-sample/README.md
• [ ] Add test configuration to vitamio-sample/build.gradle to run instrumentation tests

Add Gradle dependency version documentation and modernization guide

The build.gradle uses deprecated Gradle plugin 0.12.+ and references old Android build tooling. New contributors and maintainers need clarity on what versions to use. The repo has gradle.properties and settings.gradle but no version strategy documentation. Create a migration guide showing how to upgrade to modern Android Gradle Plugin while maintaining compatibility across the 3 dist variants.

• [ ] Create CONTRIBUTING.md with Gradle/Android SDK version requirements (e.g., minimum AGP version, target SDK)
• [ ] Document in gradle.properties the minimum versions for gradle, AGP, and Android SDK
• [ ] Add a MIGRATION.md documenting breaking changes when upgrading from older Gradle versions
• [ ] Update build.gradle and vitamio-sample/build.gradle with version variables from gradle.properties
• [ ] Reference these docs in the main README.md troubleshooting section

• Migrate build.gradle from Gradle 0.12.+ to current Android Gradle Plugin (7.x+): update classpath and syntax to modern standards, then test sample app assembly on recent Android Studio.
• Create architecture selection documentation in README.md explaining the differences between dist/arm_x86, dist/arm_x86_mips, and dist/online_arm flavors and when to use each (e.g., online_arm for reduced APK size).
• Add unit tests under vitamio-sample/src/androidTest to verify that Vitamio MediaPlayer instances can initialize and call basic APIs (play, pause, seek, getMetadata) without crashing on emulated devices.

The Vitamio codebase presents several significant security concerns, primarily stemming from the use of severely outdated build tools (Gradle 0.12 from ~2014) which lack modern security protections. The distribution of native libraries without apparent integrity verification mechanisms poses supply-chain risks. The inclusion of OpenSSL without documented versioning or update procedures is concerning for a framework handling HTTPS and encrypted streams. Sample applications lack visible input validation for media sources. No dependency verification or lock file mechanism exists. Overall, this appears to be a legacy project that requires substantial security modernization, particularly around build toolchain updates, dependency management, and native code integrity verification.

• High · Outdated Gradle Build Plugin — build.gradle. The build.gradle file specifies 'com.android.tools.build:gradle:0.12.+' which is extremely outdated (released around 2014). This version contains numerous known security vulnerabilities and lacks modern security features like Certificate Pinning support, TLS 1.2+ enforcement, and proper dependency verification. Fix: Update to the latest stable Android Gradle Plugin (currently 8.x). Use specific version pinning instead of '+' to ensure reproducible builds: 'com.android.tools.build:gradle:8.1.2' or latest stable version.
• High · Missing Dependency Verification — build.gradle, gradle.properties. No dependency verification mechanism (gradle.lockfile, verification-metadata.xml, or similar) is present. This allows for dependency confusion attacks and supply chain compromises where malicious versions of dependencies could be injected. Fix: Implement Gradle dependency verification using 'gradle.lockfile' or configure dependency verification metadata to lock transitive dependency versions and verify checksums.
• Medium · Native Libraries Without Signature Verification — dist/*/libs/*/libvinit.so, dist/*/res/raw/libarm.so. Multiple native .so libraries (libvinit.so, libarm.so) are distributed without apparent signature verification or integrity checks. These compiled binaries could potentially be tampered with during distribution or installation. Fix: Implement cryptographic signature verification for native libraries at runtime. Use APK signing with v2+ scheme and consider additional runtime integrity verification for critical native code.
• Medium · Lack of Input Validation in Sample Applications — vitamio-sample/src/io/vov/vitamio/demo/. The sample applications (MediaPlayerDemo*.java, VideoView*.java) handle media URLs and streaming without visible input validation. This could allow for protocol confusion attacks or injection of malicious media sources. Fix: Implement strict URL validation and whitelisting for media sources. Validate URI schemes, use HTTPS for remote content, and implement certificate pinning for sensitive endpoints.
• Medium · OpenSSL Bundled Without Update Mechanism — vitamio/libs/, README.md. The README mentions 'OpenSSL included' but there's no apparent update mechanism or version tracking. OpenSSL frequently receives critical security patches that need to be applied promptly. Fix: Document the exact OpenSSL version included. Establish a process for monitoring and updating OpenSSL security patches. Consider using system OpenSSL or implementing dynamic library loading where possible.
• Low · Insufficient ProGuard Configuration — vitamio-sample/proguard-project.txt. The proguard-project.txt exists but typical patterns suggest it may not be properly configured for all sensitive code paths in a multimedia framework that handles sensitive protocols like HTTPS/RTMPS. Fix: Enhance ProGuard configuration to specifically protect cryptographic code, authentication handlers, and native JNI interfaces from reverse engineering.
• Low · Missing Security Documentation — Repository root. No explicit security policy, vulnerability disclosure process, or security guidelines are documented in the repository. Fix: Create a SECURITY.md file documenting vulnerability disclosure procedures, supported versions for security updates, and security best practices for users of the library.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.