How Android Dev Teams Use ChatGPT for Code Audits

Android code audits in Kuala Lumpur are rarely glamorous. You sit on a 180,000-line codebase in Cyberjaya or Bangsar South, facing a payment module that needs to comply with Bank Negara Malaysia’s RMi-T controls, or a logistics app that has been collecting GPS points in a SQLite table for two years. ChatGPT will not replace your senior Android engineer. But it does change how the pre-audit triage loop works — provided you treat it as a strict, structured first-pass sweeper rather than a conversational code buddy. The following workflow is what teams in KL are running in practice.

Step 1: Scope the Diff and Load the Build Context

The first mistake is pasting a whole repository into the prompt. Token costs skyrocket, and the model drowns in `res/` XML files and generated `R.java` classes. A full re-audit of a 200,000-line codebase is also operationally useless because half of those findings are already dead code.

Pick a unit of work. Most teams in Klang Valley run this via a small Python script on the CI runner: `git fetch origin main && git diff origin/main…HEAD — ‘.kt’ ‘.java’`. That produces a 400 to 600-line diff, which is the right size for a single ChatGPT audit pass. The script then grabs two supporting files — `gradle/libs.versions.toml` (the version catalog) and `app/build.gradle.kts` — and concatenates them with the diff into one prompt.

The regional trick is to inject regulatory constraint into the system prompt. For a fintech client, the prompt should read: “You are a senior Android auditor at a Malaysian e-payment provider. Mapping findings to BNM RMi-T control RIT/PL-PS/001 (application security). Base all recommendations on the dependency versions in the provided catalog.” That single sentence curbs the model’s tendency to suggest Flutter rewrites or exotic Jetpack libraries your `minSdk 26` cannot handle.

The model’s job is not to explain the code. It is to read the diff with a specific threat model in mind.

Step 2: Ask for a Narrow, Structured Hit List

Generic prose is the enemy of the audit. When the model starts writing paragraphs beginning with “The codebase demonstrates good use of modern Android practices,” you have wasted your API credits. You need a JSON array, nothing else.

Your prompt should explicitly say:

The `rule_id` field is what separates a professional audit from a chatbot session. In KL teams, these IDs map to the OWASP MobileTop 10 categories that the Malaysian Security Policy (MAMPU) or BNM expects: `allowBackup` manifest flags, `usesCleartextTraffic` misconfigurations, `WebView.addJavascriptInterface` without an URL allow-list, `TrustManager` stubs that ignore SSL certificate validation, and hard-coded API keys in default `BuildConfig` fields.

For logistics teams — the ones building rider tracking for delivery fleets across Shah Alam or Johor Bahru — the rule list should include a performance rule: unindexed `SQLiteDatabase.rawQuery` calls over a 100,000-row GPS table, which causes the UI to freeze on low-end Chinese-market phones that Malaysian gig riders often use.

At the end of this step, you will have a list of 20 to 40 raw hits. You do not fix anything yet.

Step 3: Route Findings Through a Local Validator

ChatGPT is not a linter. It does not have a deterministic view of your Gradle build. If you send its raw output straight to a Jira board, your lead developer will spend all morning closing false positives and writing snarky comments.

The correct workflow uses the local Android toolchain as the final judge. Each finding in the ChatGPT JSON is cross-checked against `./gradlew lint` and `./gradlew detekt` results from your CI job, which runs on a runner in Singapore (`ap-southeast-1`) or from a bare-metal machine in Cyberjaya when you need to keep data inside Malaysia.

The practical integration is straightforward: ask ChatGPT to also generate a small Python script that converts its output JSON into an Android Lint-compatible XML file. This lets you merge the model’s findings into the existing `build/reports/lint-results-debug.xml` that your CI portal already knows how to render. Findings that do not appear to match the actual compiler output — for example, the model guessed a line number wrong — get dropped immediately.

There is a hard rule in KL: a finding is only promoted if a human reviewer, opening the actual file in Android Studio, reaches a similar conclusion. Roughly 30 percent of ChatGPT’s flagged items fail this manual verification step, which is why you cap the confidence bar internally at 80 percent and log everything else to the `#code-audit-fp` channel.

Step 4: Export Findings Into Triage Tickets

The final output of a proper audit is not a conversation. It is a set of sprint-ready tickets that your developer in Bandar Utama can start working on at 9 AM without a stand-up meeting.

So re-run the ChatGPT prompt a second pass, but this time with the original JSON fed back in and the instruction: “For every finding, rewrite the JSON with a `fix_estimate_minutes` field and include a minimal diff snippet that resolves the issue.” This is where the model pays for itself. Writing the exact `android:exported=”false”` fix or the correct `NetworkSecurityPolicy` XML block is mechanical, but it takes your average mid-level dev fifteen minutes per ticket to get right.

For a fintech audit, store the ChatGPT-generated report file in the repository’s `docs/audit/` folder as a supplementary artifact. Your external security reviewer will not accept it as a replacement for manual testing — they will use it to cross-reference their own findings and check whether the fix for `RIT/PL-PS/001` was actually applied. The senior engineer signs off, and the tickets go into the sprint.

Teams that skip the JSON structure end up with chatbot paragraphs pasted into Notion and a follow-up meeting to “discuss the findings.” Teams that use the structure above compress the post-audit backlog from 40 vague tasks to 5 to 8 high-confidence tickets per sprint.