CCE-ANDROID

CCE School Edition — Android

A native Android WebView shell around the existing CCE Software v1.0 web app (Continuous & Comprehensive Evaluation for Maharashtra schools). The HTML/CSS/JS you already built lives unmodified under app/src/main/assets/www/ — this project just wraps it in a hardened native app so it can be distributed as an APK / installed on school tablets and phones.

Project layout

CCE-School-Android/
├── app/
│   ├── build.gradle                  # release signing, minify, R8 config
│   ├── proguard-rules.pro
│   └── src/main/
│       ├── AndroidManifest.xml       # allowBackup=false, no cleartext, etc.
│       ├── java/.../MainActivity.kt  # hardened WebView shell
│       ├── res/xml/                  # network security + backup config
│       └── assets/www/
│           ├── index.html            # your CCE_School_Edition.html
│           └── xlsx.full.min.js
├── keystore.properties.sample        # copy → keystore.properties, fill in
├── .github/workflows/android-build.yml
└── gradlew / gradlew.bat

Building

1. Open the project root in Android Studio (Giraffe/Koala or newer), let it sync, and press Run — this is the easiest path and needs no extra setup.
2. Or from the command line:

   ./gradlew assembleDebug     # unsigned debug APK
   ./gradlew assembleRelease   # release APK (needs keystore.properties, below)
   

Release signing

Release builds are only signed if keystore.properties exists at the project root (it’s git-ignored on purpose — never commit a real keystore or its passwords).

cp keystore.properties.sample keystore.properties
# edit keystore.properties with your real keystore path + passwords
keytool -genkey -v -keystore release.keystore -alias cce-release \
  -keyalg RSA -keysize 2048 -validity 10000
./gradlew assembleRelease

CI

.github/workflows/android-build.yml builds a debug APK on every push/PR to main and uploads it as a workflow artifact, so you get an installable build from GitHub without needing a local Android Studio setup.

Security notes

This wraps a client-side web app in a WebView, so it’s worth being precise about what “secure” does and doesn’t mean here.

What this project actually hardens:

• No file:// origin. Local assets are served over a virtual https://appassets.androidplatform.net/assets/... origin via androidx.webkit.WebViewAssetLoader, instead of the classic file:///android_asset/.... This sidesteps the well-known WebView file-scheme vulnerabilities (arbitrary local file read via crafted pages, broken same-origin behavior) entirely, rather than trying to patch around them.
• Locked-down WebView settings: allowFileAccess, allowContentAccess, allowFileAccessFromFileURLs, and allowUniversalAccessFromFileURLs are all explicitly false. Mixed content is blocked (MIXED_CONTENT_NEVER_ALLOW). Safe Browsing is on.
• No cleartext traffic, anywhere (network_security_config.xml + usesCleartextTraffic="false"). Every remote resource the page loads (Firebase, Google Fonts) is already https://, so nothing needed an exception.
• Navigation is pinned to the app’s own origin. shouldOverrideUrlLoading refuses to navigate the WebView itself to any host other than the app’s virtual origin — so a compromised/malicious link can’t hijack the app into displaying an arbitrary external site in place of your UI. It does not block the page’s own <script src="https://..."> resource loads (Firebase SDK, fonts), since those aren’t top-level navigations.
• Remote debugging is debug-build-only (BuildConfig.DEBUG gate on setWebContentsDebuggingEnabled), so a release APK can’t be inspected via chrome://inspect.
• No Android auto-backup (allowBackup="false"), so device backups (Google One, adb backup) can’t be used to lift the app’s local storage (license data, cached login info) off a device.
• R8/ProGuard minification + resource shrinking on release builds.

What this does not and cannot protect against, and you should plan around rather than assume away:

• The JavaScript is fully readable. Almost all of the app’s real logic — the login flow, the license/trial checks, the admin panel — lives in index.html/xlsx.full.min.js, not compiled code. Unzipping the APK (unzip app-release.apk) gets you the exact source. ProGuard only obfuscates the thin native Kotlin shell, not the web app. If you need to keep evaluation logic or license validation truly private, it has to be enforced server-side, not client-side — any client-side “unlock code” scheme can be patched out of a decompiled/rebuilt APK by a determined user, regardless of how the code is packaged.
• The default login has a hardcoded fallback password (“Admin123”) pre-filled in the login form in the current HTML. That’s fine for a demo, but before distributing this to real schools, remove the pre-filled default and require every school to set their own password on first run — a visible-in-source default credential is a real risk once the APK is out in the world.
• Firestore security is entirely a server-side concern: this app just calls the Firebase SDK with the config already embedded in the page (cce-software.firebaseapp.com). Make sure your Firestore security rules, not this app, are what actually stop one school from reading or writing another school’s data.
• Signing your APK with a real, private keystore is what makes Play Store / users trust future updates actually come from you — this project sets up the plumbing for that (keystore.properties) but can’t generate or protect the keystore itself; treat that file/keystore like a password, not like source code.

Permissions

Only INTERNET and ACCESS_NETWORK_STATE are requested — no storage, camera, contacts, or location access, since the app doesn’t need any of those.

This site is open source. Improve this page.