Forem: Prabhakar Thota

I Set Up My AI Coding Tool Properly for an Android Project - Here's What Changed

Prabhakar Thota — Sat, 28 Feb 2026 15:18:07 +0000

Whether you use Claude Code, GitHub Copilot, Gemini, or Codex — most Android developers are burning tokens and getting inconsistent results. I fixed that with 28 files.

I've been building Apps Manager — a production Play Store app with 163 Java files, Firebase, AdMob, Google Billing, WorkManager, widgets, and a gamification system. Yes, it's Java — not Kotlin, not Compose. A migration is on the roadmap, but if you've maintained a legacy app, you know that's a "when we have bandwidth" task. The codebase works, ships, and earns revenue.

I use Claude Code, Codex, and Gemini in Android Studio daily. They've helped me fix data races, modernize deprecated APIs, and ship features faster. But here's the part nobody talks about: these tools don't actually know your project.

You open a session, ask the AI to add a feature, and it suggests converting your Java to Kotlin. Or proposes Compose when your UI is XML. Or autocompletes a Hilt injection when you have zero DI. My project has 3 Retrofit clients — the AI picks the wrong one every time. I have a theme system where ThemeUtil.applyTheme() must be called before super.onCreate() — the AI puts it after.

I was spending the first 3-4 messages of every session just correcting the AI. And when a teammate started using these tools? Same problem. Every developer having the same "no, this is Java" conversation independently. Claude Code, Copilot, Gemini — didn't matter. The problem was the same: no project-level context.

Then I discovered 5 features in Claude Code that most developers never set up — and the principles apply to every AI coding tool.

The 5 Features Nobody Talks About

Claude Code isn't just a chat window. It has a proper configuration system:

1. CLAUDE.md — A file at your project root that Claude reads automatically every session. Think of it as your project's identity card. Your architecture, conventions, tech stack, build commands, things to never do — all in one place.

2. Skills — On-demand expertise files that Claude loads only when relevant. Unlike CLAUDE.md (always loaded), Skills activate contextually. A "Firebase patterns" skill loads when you're working with Firebase. An "AdMob patterns" skill loads when you touch ad code. This keeps your context window clean.

3. Sub-agents — Isolated Claude instances for focused tasks. Need a code review? Spawn a sub-agent. It reviews the code, returns results, and doesn't pollute your main conversation.

4. Hooks — Automated guardrails that fire on specific events. Edit a file? Run lint automatically. Try to commit to main? Block it. Create a model class? Remind about ProGuard rules. No manual intervention needed.

5. MCP Servers — Connections to external services. Claude can create GitHub PRs, check Firebase data, and interact with your actual development tools — not just your codebase.

When you combine all five, Claude Code transforms from a chatbot into a configured development partner.

A note for Copilot/Gemini/Codex users: While I'm demonstrating this with Claude Code (because it has the most mature configuration system right now), every AI coding tool is moving in this direction. GitHub Copilot has custom instructions and .github/copilot-instructions.md. Gemini in Android Studio reads project context. Codex supports system prompts. The concept of giving your AI tool project-level memory is universal — the implementation details differ, but the mindset is the same. What you learn here applies everywhere.

What I Actually Built

Here's the full setup I created for my Android project — every file tailored to my real codebase, not a demo project.

CLAUDE.md — The Foundation

This is the single most impactful file. Here's what mine includes:

# Project: Apps Manager by MyInnos

## Architecture
- Single-module Android app (app/ only)
- Pattern: MVC (Activity-based)
- Language: Java only (no Kotlin files in project)
- UI: XML layouts with ViewBinding + DataBinding (no Jetpack Compose)
- Gradle: Groovy DSL (build.gradle, not .kts)

## Important Rules
- NEVER suggest Kotlin — this is a Java-only project
- NEVER suggest Jetpack Compose — this uses XML layouts
- NEVER suggest Hilt/Dagger — no DI framework in use
- NEVER suggest Room — data is in SharedPreferences + Firebase
- BaseActivity is 63.5KB — don't add more to it
- Always handle ad-free state (isAdFree()) when touching ad code

That last section is the game-changer. Without it, Claude would suggest Kotlin every other response. With it, Claude stays in Java mode and follows my actual patterns.

My full CLAUDE.md includes the package structure, all 3 Retrofit client URLs, SharedPreferences key constants, build commands, git conventions, and testing notes. It's about 200 lines — comprehensive but not bloated.

8 Skills — Context-Aware Expertise

Instead of generic skills, I built ones that match my exact codebase:

Skill	What It Knows
retrofit-api-patterns	My 3 separate Retrofit clients, endpoint patterns, Gson model conventions
firebase-patterns	My Analytics events, RemoteConfig flags, Realtime DB write structure
activity-ui-patterns	ViewBinding setup, ThemeUtil.applyTheme() before super.onCreate(), edge-to-edge
admob-patterns	Banner lifecycle, interstitial dual-frequency control, rewarded ads memory guard
billing-subscription	BillingClient singleton, purchase acknowledgement, points-based theme unlocking
leaderboard-gamification	7-day streak cycle, badge unlocks, referral system, coupon redemption
widget-receiver-patterns	goAsync(), AtomicInteger task tracking, PendingIntent flags
workmanager-patterns	Weekly report worker, snapshot comparison, notification channels

Each skill is a SKILL.md file inside .claude/skills/{name}/. When I ask Claude to "add a new API endpoint," it auto-loads the retrofit-api-patterns skill and knows to use @SerializedName, check which of my 3 Retrofit clients to use, null-check response.body(), and log failures to Crashlytics.

Here's a snippet from my AdMob skill:

## Interstitial Ad — Dual Frequency Control
Two gates must pass before showing:
1. Time gap — ad_interstitial_timegap seconds since last show (from RemoteConfig)
2. Interaction gap — ad_interstitial_interaction_gap interactions since last show

## Rules
- NEVER show ads without checking isAdFree() first
- NEVER show ads without consent (canRequestAds())
- NEVER load rewarded ads on low-memory devices

This means Claude will never accidentally break my ad logic. Every ad-related change respects the consent flow, subscription state, and memory constraints.

5 Sub-agents — Isolated Specialists

These are my favorite. Each agent has a focused job:

Agent	Role
code-reviewer	Reviews Java/XML for memory leaks, lifecycle issues, thread safety, null safety
architecture-analyst	Finds God classes, circular dependencies, code duplication
security-auditor	Checks cleartext traffic, unencrypted storage, WebView risks, permission issues
performance-analyzer	Spots main-thread blocking, RecyclerView inefficiency, widget refresh cost
api-contract-validator	Verifies Retrofit endpoints match model classes, checks ProGuard coverage

When I ask "review the leaderboard package for security issues," Claude spawns the security-auditor in isolation. It scans the files, returns findings categorized as HIGH/MEDIUM/LOW severity, and doesn't clutter my main conversation.

My code-reviewer agent is specifically tuned for Java (not Kotlin), checks for Android-specific issues like isFinishing() guards, and knows about my ad system's isAdFree() requirement.

6 Hooks — Automatic Guardrails

These run without me doing anything:

Hook	Trigger	Action
prevent-main-commit	`git commit` on main/develop	Blocks with error message
commit-message-format	Any `git commit`	Enforces `type(scope): description` format
manifest-validation	Edit AndroidManifest.xml	Validates XML structure
proguard-reminder	Edit any model class	Checks if ProGuard rules cover it
post-edit-lint	Edit any Java/XML file	Runs lint check
test-reminder	Claude stops working	Reminds that zero tests exist

The commit message hook is surprisingly useful. My project uses conventional commits (feat(leaderboard): add streak badges), and now Claude can't commit with a lazy "updated files" message.

The ProGuard reminder has already saved me. I added a new API model class, and the hook immediately flagged that it wasn't in proguard-rules.pro. Without this, the release build would crash with Gson deserialization errors.

MCP Servers — External Connections

I connected 3 external services:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "firebase": {
      "command": "npx",
      "args": ["-y", "firebase-tools@latest", "mcp"]
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"]
    }
  }
}

Now I can say "create a GitHub issue for the streak reset bug" and Claude actually creates it on my real repo. No copy-pasting, no switching tabs.

6 Slash Commands — Repeatable Workflows

For tasks I do often:

/create-activity UserInsightsActivity — scaffolds Activity + XML + manifest entry
/create-model AppRatingModel — creates Gson model + ProGuard rules
/create-adapter WeeklyStatsAdapter — RecyclerView adapter with ClickerInterface
/create-api-endpoint get-user-stats — endpoint + model + error handling
/review-module leaderBoard — triggers code review sub-agent
/version-bump patch — increments versionCode/versionName

Each command follows my exact project conventions. /create-activity knows to call ThemeUtil.applyTheme() before super.onCreate(), use CoordinatorLayout as root, and register in the manifest. Every time. Consistently.

The Token Savings Are Real

Before this setup, a typical session started with 3-4 messages just establishing context. "This is Java." "We use ViewBinding." "Don't suggest Kotlin." "Here's how our API clients work." Each message costs tokens — both in what you send and what Claude processes.

Now? First message, first task. Claude already knows everything. For a team of developers, multiply that saving across every session, every day.

But the bigger win is consistency. When my teammate uses Claude Code on this project, they get the same conventions, same patterns, same guardrails. No more "Claude suggested Kotlin to me but Java to you." The CLAUDE.md is committed to git — it's shared across the team.

How to Set This Up for Your Project

The complete folder structure:

your-android-project/
├── CLAUDE.md                          # Always-loaded project rules
├── .mcp.json                          # MCP server connections
├── .claude/
│   ├── settings.json                  # Hooks configuration
│   ├── settings.local.json            # Personal overrides (gitignored)
│   ├── commands/                      # Slash commands
│   │   ├── create-activity.md
│   │   ├── create-adapter.md
│   │   └── ...
│   ├── skills/                        # On-demand expertise
│   │   ├── retrofit-api-patterns/
│   │   │   └── SKILL.md
│   │   ├── firebase-patterns/
│   │   │   └── SKILL.md
│   │   └── ...
│   ├── agents/                        # Sub-agents
│   │   ├── code-reviewer.md
│   │   ├── security-auditor.md
│   │   └── ...
│   └── hooks/                         # Automated guardrails
│       ├── prevent-main-commit.sh
│       ├── proguard-reminder.sh
│       └── ...
└── app/

Start with CLAUDE.md — it gives you the biggest immediate improvement. Write your actual project rules, not aspirational ones. If your project is Java, say Java. If it's a monolith, say monolith.

Then add Skills for the patterns you repeat most. Look at your last 10 Claude conversations — what did you explain more than once? That's a skill.

Hooks come next — start with the commit protection ones. They prevent mistakes with zero effort.

Sub-agents and MCP servers are the advanced layer. Add them when you're comfortable with the basics.

The Decision Matrix

Situation	Feature
Always applies to every task?	CLAUDE.md
Needed sometimes, context-specific?	Skill
Need isolated, focused work?	Sub-agent
Want automatic enforcement?	Hook
Need external data/services?	MCP Server
Repeatable multi-step workflow?	Slash Command

What This Means for Android Teams

Most Android developers are using AI coding tools like a chat window — type a question, get an answer, repeat. Whether it's Claude Code, Copilot, Gemini, or Codex — they're leaving 80% of the tool's capability on the table.

The problem isn't the AI. It's the setup. Or rather, the lack of it.

Setting up project-level context takes about an hour. The payoff is immediate: fewer wasted tokens, consistent code patterns, automatic guardrails, and a shared knowledge base that every team member benefits from. Commit the configuration files to git, and every developer on the team gets the same AI experience from day one.

My Apps Manager project went from "the AI sometimes suggests Kotlin on a Java project" to "it knows every convention, catches ProGuard mistakes automatically, and creates GitHub PRs without me switching tabs."

28 files. One hour of setup. Every session after that is faster, cheaper, and more consistent.

The Bigger Picture

We're at an interesting moment in Android development. AI coding tools are becoming essential, but most developers treat them like Stack Overflow with autocomplete. They ask questions, get answers, and move on.

The developers who will get ahead are the ones who configure their AI tools — who invest an hour upfront to save hundreds of hours over the lifetime of a project. This isn't about which AI tool you use. Claude Code, Copilot, Gemini, Codex — they all benefit from project-level context. The specific features I showed (CLAUDE.md, Skills, Hooks, Sub-agents, MCP) are Claude Code's implementation, but every tool has its equivalent:

Concept	Claude Code	GitHub Copilot	Gemini	Codex
Project context	CLAUDE.md	.github/copilot-instructions.md	Project context	System prompts
On-demand rules	Skills	—	—	—
Automated checks	Hooks	Pre-commit hooks	—	—
External tools	MCP Servers	Extensions	Extensions	Plugins

The tool-specific features will converge over time. The mindset of "configure your AI before you use it" is what matters.

If you're using any AI coding tool for Android development without project-level setup — you're doing it wrong. Start with one file. Write your project's rules. Watch everything change.

The setup I showed is tailored for a Java/XML codebase, but the same approach works for any Android project — Kotlin, Compose, multi-module, whatever your stack is. Adapt the files to your project's conventions and you're good to go.

Check out Apps Manager: appsmanager.app

If you found this useful, share it with your Android team. This is the kind of setup that saves everyone tokens and headaches.

Follow me for more Android development + AI tooling content.

Tags: #AndroidDev #ClaudeCode #AI #Automation #AndroidStudio #GitHubCopilot #Gemini #Codex #Productivity #DeveloperTools

Prompt Engineering Context Engineering: An Android Engineer's Perspective

Prabhakar Thota — Sun, 22 Feb 2026 15:10:20 +0000

As Android engineers, we understand one thing very clearly:

Behavior is driven by state.

Now apply that to AI.

For a while, we treated LLMs like simple input-output functions:

Input (Prompt) → Model → Output`

So we optimized the input string.

But if you think like an Android engineer, this approach feels… incomplete.

Because we know:

Apps don’t work because of a single method call.They work because of architecture + state + data flow.

That’s where context engineering comes in.

Prompt Engineering Is Like Writing a Better Function Call

Imagine this:

fun generateSummary(text: String): String

You can improve how you call it:

generateSummary( "Summarize this article in bullet points with a technical tone...")

Sure - better instruction gives better output.

But what if the function doesn’t know:

Who the user is
What reading level do they prefer
Their past interactions
The domain context
App state

Then you’re just polishing the argument.

That’s prompt engineering.

Android Reality: State Is Everything

In Android, we don’t design apps like this:

Button Click → API Call → UI Update

We design systems like:

UI → ViewModel → Repository → Local DB / Network → StateFlow → UI

Why?

Because:

State survives configuration changes
Data flows predictably
Business logic is separated
Context is preserved

Now map this to AI.

LLM Without Context = Activity Without ViewModel

Calling an LLM with only a prompt is like:

Writing everything inside an Activity No ViewModel No Repository No SavedStateHandle No caching No offline support

It works in the demo.

It breaks in production.

Context Engineering in Android Terms

Let’s say you’re building an AI-powered feature inside your Android app.

❌ Prompt Engineering Approach

User clicks:

“Plan my Thailand trip”

You send:

"Plan a 5-day Thailand trip."

Model responds generically.

✅ Context Engineering Approach

Before calling the model, your app gathers:

User budget (from Room DB)
Previous trips (from local history)
Preferred airlines (saved preference)
Current location (FusedLocationProvider)
Passport nationality (profile data)
Live flight prices (API response)
Cached hotel recommendations

Then you assemble:

TripContext( budget = 80000, preferredAirlines = listOf("Singapore Airlines"), location = "Bangalore", travelHistory = beachesOnly, ...)

Now your model call is powered by:

State + memory + live data.

That’s context engineering.

It’s Basically MVI for AI

If you’re using MVI or Clean Architecture:

You already understand context engineering.

Instead of:

Intent → Prompt → Response

It becomes:

Intent → State Reduction→ Context Builder→ Model Call→ Validator→ State Update→ Render

The prompt is just one layer in the pipeline.

Real Android Parallel

Think of it like Glide or Coil.

You don’t just do:

loadImage(url)

You configure:

Memory cache
Disk cache
Transformation
Placeholder
Lifecycle binding

Why?

Because the environment matters.LLMs are the same.The environment (context) determines output quality.

Why This Matters for Android Engineers

As mobile engineers, we are naturally good at:

Managing lifecycle
Handling state
Caching data
Orchestrating APIs
Optimizing performance

That skillset maps perfectly to context engineering.

AI isn’t about writing better English.

It’s about designing better data flow.

The Shift in Thinking

Prompt Engineering mindset:

“How do I phrase this better?”

Context Engineering mindset:

“What does my system already know that the model should know too?”

As Android engineers, we don’t build screens.

We build state-driven systems.

AI systems should be no different.

Designing a Scalable OTA Strategy in Android Applications

Prabhakar Thota — Fri, 13 Feb 2026 05:52:56 +0000

In Android development, OTA (Over-The-Air) updates are often misunderstood as simply “publishing a new build to the Play Store.”

At scale, OTA is not a release action.
It is an architectural control system.

In production-grade applications - especially commerce, fintech, or high-traffic platforms - how you design OTA directly impacts release velocity, revenue stability, and operational risk.

Let’s break it down.

1. Store-Based OTA: Binary Replacement Layer

When we:

Increment versionCode
Upload AAB to Google Play Store
Use staged rollout
Monitor crash-free sessions

We are replacing the entire app binary.

This is mandatory for:

Native code changes
Dependency upgrades
SDK updates
Permission changes
Architecture refactors
Major UI changes (Compose/XML)

Limitations

Users may delay updates
Rollback is slow
Review delay risk
Emergency hotfix pressure

Binary OTA alone is not sufficient for high-scale apps.

2. In-App Updates: Version Enforcement Layer

Using the Play Core In-App Updates API, we can trigger:

Immediate Updates (blocking)
Flexible Updates (background download)

A clean architecture pattern:

Backend:

minSupportedVersion = 120
recommendedVersion = 125

App Launch:

if currentVersion < minSupportedVersion:
    triggerImmediateUpdate()
else if currentVersion < recommendedVersion:
    showFlexibleUpdate()

This avoids hardcoded force-update logic.

It also gives product and backend teams controlled rollout authority.

3. Runtime OTA: Remote Config & Feature Flags

The real maturity layer.

Instead of shipping logic changes through Play Store:

We separate:
Binary Layer → Structural changes
Config Layer → Business rules
Experiment Layer → Feature flags

Using runtime configuration, we can control:

Cashback calculation toggles
Discount stacking logic
Payment provider routing
Checkout flow variants
UI experiments
Kill switches for risky modules

This reduces emergency releases significantly.

4. Production-Grade OTA Architecture

A scalable startup sequence:

App Start
   ↓
Load Cached Config
   ↓
Fetch Remote Config (Async)
   ↓
Validate App Version
   ↓
Apply Feature Flags
   ↓
Render UI

With:

Safe defaults
Config expiry control
Kill switches
Version-based flag targeting
Rollback capability

This transforms OTA into:

A risk management layer
A velocity enabler
A runtime control system

5. Engineering Insight

In mature Android systems:

Deployment ≠ Release
Release ≠ Exposure

You can:

Deploy code → Keep feature OFF
Enable feature → 5% users
Scale to 100% → Monitor metrics
Instantly disable → If anomaly detected

This is how large-scale mobile systems operate safely.

Final Thought

If your OTA strategy is only “push a new build”, you are operating at a surface level.

If your OTA strategy includes runtime control, version gating, and safe rollout architecture, you are building production-grade mobile systems.

If you’re designing large-scale Android systems, OTA should be treated as architecture, not deployment.

Send WhatsApp Messages using the Android SDK

Prabhakar Thota — Mon, 30 May 2022 05:35:24 +0000

Before jumping into using the SDK, let's follow the below steps to create the project on developers.facebook.com to claim the phone number id.

Step 1: Create a WhatsApp App

Give your app a descriptive name (do not use any Facebook trademarks like WhatsApp or Facebook in the app name) and click the Create App button to create the app.

On the next screen, you will be required to link your WhatsApp app to your Facebook business account. You will also have the option to create a new business account if you don’t have one yet.

Step 2: Add Recipient’s phone number

Your WhatsApp app will provide you with a temporary access token that will be valid for 23 hours. Make a note of this token as we’ll need it in a later step.

Use below Android SDK to Send WhatsApp Messages using the WhatsApp API

Kindly use the following links to use this library:

In settings.gradle (Project)

dependencyResolutionManagement {
    repositories {
        …….
        maven { url 'https://jitpack.io' }
    }
}

And then in the other gradle file(maybe your app gradle or your own module library gradle, but never add in both of them to avoid conflict.)

dependencies {
    implementation 'com.github.myinnos:WhatsApp-SDK:<latest-version>'
}

How to use

Step 2: implement App Icon Name Changer method : #Example - MainActivity.kt

WhatsAppInitialization.sendMessage(
                "token", //token
                "version", //ex: v13.0
                "phone_number_id", //ex: 103075932423434
                "customer_phone_number",
                "template_name", //ex: hello_world
                "language_code", //ex: en_US
            ) { wResult ->
                Handler(Looper.getMainLooper()).post {
                    if (wResult?.getMessage() == null) {
                        // failed results
                    } else {
                        // success results
                        Log.d("RESULTS", wResult.getMessage())
                    }
                }
            }

Any Queries? or Feedback, please let me know by opening a new issue!

PS: Images in the article are taken from labnol

Let me know your thoughts on Twitter.

Google code scanner API -scanning codes without camera permission

Prabhakar Thota — Thu, 19 May 2022 06:02:51 +0000

The Google code scanner API provides a complete solution for scanning codes without requiring your app to request camera permission, while preserving user privacy. This is accomplished by delegating the task of scanning the code to Google Play services and returning only the scan results to your app. All image processing occurs on the device and Google doesn't store the results or image data.

Kindly use the following links to use this library:

This API requires Android API level 21 or above. Make sure that your app's build file uses a minSdkVersion value of 21 or higher.

In your top-level settings.gradle file, include Google's Maven repository and Maven central repository in under the dependencyResolutionManagement block:

dependencyResolutionManagement {
 repositories {
 google()
 mavenCentral()
 }
}

Add the Google Play services dependency for the play-services-code-scanner SDK to your module's Gradle build file, which is commonly app/build.gradle:

dependencies {
 implementation 'com.google.android.gms:play-services-code-scanner:16.0.0'
}

You can configure your app to have Google Play services automatically download the scanner module to the device while your app is installed from the Play Store. If you skip this step, Google Play services will download the scanner module the first time it is used, if it has not already been installed for another use case.

<application …>
 …
 <meta-data
 android:name="com.google.mlkit.vision.DEPENDENCIES"
 android:value="barcode_ui"/>
 …
</application>

How to use
- - -
(Optional) Configure the code scanner
If you know which barcode formats you expect to read, you can improve the speed of the barcode detector by configuring it to only detect those formats. For example, to detect only Aztec code and QR codes, build a GmsBarcodeScannerOptions object as in the following example:

//**** java ****
GmsBarcodeScannerOptions options = new GmsBarcodeScannerOptions.Builder()
 .setBarcodeFormats(
 Barcode.FORMAT_QR_CODE,
 Barcode.FORMAT_AZTEC)
 .build();

//**** kotlin ****
val options = GmsBarcodeScannerOptions.Builder()
 .setBarcodeFormats(
 Barcode.FORMAT_QR_CODE,
 Barcode.FORMAT_AZTEC
 )
 .build()

Get an instance of GmsBarcodeScanner

//**** java ****
GmsBarcodeScanner scanner = GmsBarcodeScanning.getClient(this);
// Or with a configured options
// GmsBarcodeScanner scanner = GmsBarcodeScanning.getClient(context, options);

//**** kotlin ****
val scanner = GmsBarcodeScanning.getClient(this)
// Or with a configured options
// val scanner = GmsBarcodeScanning.getClient(this, options)

Request a code scanning by calling startScan()

//**** java ****
scanner
    .startScan()
    .addOnSuccessListener(
        barcode -> {
          // Task completed successfully
        })
    .addOnCanceledListener(
        () -> {
          // Task canceled
        })
    .addOnFailureListener(
        e -> {
          // Task failed with an exception
        });

//**** kotlin ****
scanner.startScan()
    .addOnSuccessListener { barcode ->
        // Task completed successfully
    }
    .addOnCanceledListener {
        // Task canceled
    }
    .addOnFailureListener { e ->
        // Task failed with an exception
    }

Handle the resulting Barcode

//**** java ****
String rawValue = barcode.getRawValue();

//**** kotlin ****
val rawValue: String? = barcode.rawValue

Watch the code here (MainActivity.java) and ref Google code scanner (Beta)

Let me know your thoughts on Twitter.

Android Dev Tools - Become a Master with these Tools, Collaborate Better

Prabhakar Thota — Mon, 05 Jul 2021 04:22:33 +0000

You'll be well on your way to developing Android apps like a pro.

That’s why I’ve compiled this big list of Android development tools so you can find all you might need in one place.

Accessibility Scanner

Accessibility Scanner is an Android app that scans through your apps UI and makes accessibility recommendations based on the content of your screen. It lets you know what your app is missing in terms of content descriptions if your colours don’t contrast well enough or the tap targets are too small. It is a great tool for improving the accessibility of your app.

Window VQA

Window VQA (Visual Quality Assurance) is an app for measuring views on screen. It provides a useful overlay on top of your app which allows you to click on the views and get the measurements of them in px or dp.

vysor.io

Vysor is an extension for the Google Chrome browser that connects to an app on your smartphone, enabling you to control your phone from your PC or Mac using the mouse/trackpad and keyboard. Everything happens via a USB cable, which you'll need to connect the phone to your computer's USB port.

Chucker

Chucker simplifies the inspection of HTTP(S) requests/responses fired by your Android App. Chucker works as an OkHttp Interceptor persisting all those events inside your application and providing a UI for inspecting and sharing their content.

Apps using Chucker will display a push notification showing a summary of ongoing HTTP activity. Tapping on the notification launches the full Chucker UI. Apps can optionally suppress the notification, and launch the Chucker UI directly from within their own interface.

Stetho

Stetho is a tool that connects to Chrome Developer Tools and gives access to a bunch of app information as if it were a webpage you were debugging. You can get access to on-device databases, update SharedPreferences and monitor network requests and responses.

LeakCanary

LeakCanary helps you pick up any memory leaks that you may have in your applications. It does some pretty complex magic to analyse heaps and helps narrow down the cause of your memory leaks.

Shape Shifter

ShapeShifter is my favourite tool for creating AnimatedVectorDrawable animations. It takes the guesswork away from creating cute animations, helps fix paths and generate all the required XML for creating an AVD. If you want to see a quick overview of how to use it, check out my talk on animations here.

Charles Proxy

Charles Proxy is a tool for network debugging. It allows you to intercept network requests and change the response or requests. Charles Proxy is a great tool for testing error conditions or just recording what your app is doing.

Screen Recorder

Say no more, every Android Developer needs a screen recording app. This one is my favourite because there are no ads and it is super easy to use.

DevTiles

DevTiles is an app that allows you to easily access some developer options right from your devices shortcuts/tiles. Options include a tile for showing touches, enabling/disabling demo mode, toggling animator durations etc.

Nimble Droid

NimbleDroid is a testing platform that allows you to check your finished Android app for memory leaks, bugs, and other issues prior to publishing on Google Play. Using NimbleDroid helps to free up app developers’ time and speed up the overall QA process, helping to get the app to market faster.

Companies such as Mozilla, Yahoo, and Pinterest have all used NimbleDroid to test their applications. Personalized pricing is available based on customers’ specific needs and the number of users.

ML Kit

ML Kit is an Android developer tool that allows you to add machine learning functionality to your app from Google. That means adding things like computer vision and OCR without needing a giant budget and heaps of big data. Start with this simple tutorial.

AinD: Android (Anbox) in Docker

AinD launches Android apps in Docker by nesting Anbox containers inside Docker.

Unlike VM-based similar projects, AinD can be executed on IaaS instances without support for nested virtualisation.

Let me know your thoughts on Twitter.

Review of your Twitter developer account application

Prabhakar Thota — Fri, 18 Jun 2021 05:39:34 +0000

As of July 2018, you must now apply for a Twitter developer account and be approved before you can create any new apps. All new developers must apply for a developer account to access Twitter APIs. Once approved, you can begin to use Twitters standard APIs and new premium APIs.

For this article(which I found from various resources), am going to assume you have a great idea for Twitter automation and are just looking for a little bit of help with your proposal. Then we’re going to show you how we applied, and eventually became approved.

Steps to process the Twitter developer account

Go to developer.twitter.com
Click on Apply in the navbar section
Just fill in the details and submit (a very simple process)
Once the application submitted you need to confirm the email to kickstart the process

*Now you just need to wait for the replay from Twitter *

I received a replay from Twitter within 1hr

I have no idea what to give replay since I applied without any plan, then I have just given replay like

After 1hr again I got a replay from Twitter saying

Googled and I found some useful info, Just written blindly (of course with some thoughts)

Now I just waited for what is going to happen, post 2hrs I received a email saying

**Yes your reading correct, Application approved. As simple as it is. **

The approval took a day, which is too good considering Twitter’s moderation program is young and the spammers and social engineers are still out there in full testing this new gated system.

Hope this info helped those who stuck with mail processing with Twitter.

Have a nice day!

Startup Hack

Prabhakar Thota — Sat, 05 Jun 2021 03:53:19 +0000

Be nice to people.