What this adds

A new Instagram patch — Rename package — that lets the user install the patched build alongside the original Play Store Instagram, by renaming the package and label at patch time.

Two patch options:

• packageName (default com.pikogram.android) — must be a valid Java package with at least 3 segments
• appLabel (default Pikogram) — display name

How it works

The patch derives a namespace prefix from the user's package by stripping the last segment (com.pikogram.android → com.pikogram) and applies it to every word-boundary com.instagram reference. That covers:

• the app package itself (com.instagram.android.*)
• sibling sub-namespaces (com.instagram.fileprovider, com.instagram.barcelona.*, com.instagram.contentprovider.*, com.instagram.quicksnap.*, etc.) — these are system-wide-unique ContentProvider authorities; renaming them is what unblocks side-by-side install with Play Store IG
• custom permissions, intent actions, notification channel ids, launcher activity-alias names

Implementation splits into a user-facing bytecodePatch (carries the options, rewrites dex string literals) and an internal resourcePatch (rewrites the manifest in finalize{}, derives the application-label string-resource name dynamically from <application android:label>).

Smali / dex behaviour (re: "is this just a package name change?")

It does rewrite at the smali level — every const-string literal across every dex file is checked against the namespace regex, with one important exception. A pre-pass indexes every com.instagram.* class type descriptor in the dex (Lcom/instagram/X/Y;), and the rewriter skips any string literal that exactly matches one of those dotted names. Without that skip, reflection calls like Class.forName("com.instagram.process.instagram.InstagramApplicationForMainProcess") (which InstagramAppShell.onCreate actually does) would crash at startup, because we never rename type descriptors — only literals.

What the patch does not add is method-body hooks (intercepting getPackageName(), bypassing signature checks, replacing method bodies, injecting helpers). Held off on those because adding hooks without a known failure is speculative. Happy to add targeted hooks if the maintainers see something specific that breaks.

Manifest-side selectivity

Class-reference attributes are skipped during the manifest rewrite, since the actual Java classes stay at their original com.instagram.* paths in dex:

• <application> — android:name, android:backupAgent, android:appComponentFactory, android:zygotePreloadName
• <activity> — android:name, android:parentActivityName
• <service>, <receiver>, <provider>, <instrumentation> — android:name
• <activity-alias> — android:targetActivity
• <meta-data> — android:value (commonly a class ref for libraries like Google Cast)

<activity-alias android:name> intentionally stays in the rewrite — that's a logical component identifier, not a real Java class.

Tested

com.instagram.android v426.0.0.37.68 on a Galaxy S25 Ultra:

• Patching completes without smali errors
• Clone launches past WaitingForStringsActivity, reaches sign-in, login works
• Official Play Store Instagram installs alongside without ContentProvider authority conflicts
• Story regression: viewing, posting from camera and gallery, notifications, tap-to-open, replies — all pass
• Home-screen icon, install dialog, and App Info all read the chosen label

Known caveats

• No Play Store updates for the clone (expected for any package rename)
• A few Meta cross-product integrations (FCM push from Meta's servers, Family Center, deeplinks targeting com.instagram.android externally) may degrade silently — not crashes
• Play Protect may warn on install since the icon matches Instagram's but the signing cert is the patcher's

What's left out

• Dynamic version support: the patch reads the application-label string-resource name from the manifest at patch time, so the label override works across IG versions without a hardcoded resource id. Otherwise the patch is structure-driven and should survive most IG version bumps.