feat(Instagram): Add Rename package patch#1262
Conversation
Renames the patched app's package and label so the build installs alongside the original Instagram instead of replacing it. Manifest + launcher labels are rewritten, and matching string literals across every dex file are rewritten too. A pre-pass indexes every com.instagram.* type descriptor in the dex, so reflection class references stay intact. Sibling sub-namespaces (com.instagram.fileprovider, com.instagram.barcelona.*, etc.) are renamed because they're ContentProvider authorities, and Android enforces system-wide uniqueness on those at install time. Without renaming them, the official Instagram fails to install alongside. Two options: packageName (default com.pikogram.android) and appLabel (default Pikogram). Package follows standard Java package format. Tested on com.instagram.android v426.0.0.37.68 on a Galaxy S25 Ultra: clone launches, login works, story flow (view/post/notification/tap/reply) passes with no crashes over 3 minutes of active use, official Instagram installs alongside.
…n value matches a real dex class IG declares activity-aliases whose android:name is the FQCN of a real Java class, e.g. com.instagram.url.InstagramShortenDeeplinkAliasActivity and com.instagram.url.InstagramHelpDeeplinkAliasActivity. The renamer was rewriting those manifest names to com.<new>.url.…, but the dex code references them via ComponentName(Context, Class) — which uses Class.getName() under the hood — and the Class object is loaded from the original com.instagram.* type descriptor path that the patch never rewrites. Result: setComponentEnabledSetting crashes with RemoteException because the manifest name and the dex-side ComponentName no longer match. Fix: share the dex class-name set with the manifest patch and skip rewriting activity-alias android:name when the value is in the set. Aliases whose name is purely logical (no real class behind it) still get renamed.
|
There are still too many unnecessary changes being made to AndroidManifest.xml. Instead of blindly replacing "com.instagram", you should investigate the minimum necessary changes to avoid package conflicts with the official app. Also, in smali, all that's needed is to replace the instruction "com.instagram.android", so why is the bytecode patch so complicated? What the hell is going on there? And the source code is still AI sloppy. Btw, I already know the minimum changes required, so I can help if you need it. |
|
Understood, closing this one. Thank you for the time on this review. Happy to test against my device if useful when your PR is up. |
|
Thank you for your understanding. I know that contributing via pull requests is supposed to be whoever takes it first gets it. Now that you’ve entrusted this to me, I’ll work on it with responsibility! |
What
Adds a Rename package patch under Instagram. The patched build installs alongside the official Play Store Instagram instead of replacing it — different package name, different signing cert, two icons on the home screen.
Two options:
packageName(defaultcom.pikogram.android) andappLabel(defaultPikogram).How
Two patches.
A user-facing
bytecodePatchrewritescom.instagram.*string literals across every dex file. A pre-pass indexes everycom.instagram.*class type descriptor in the dex first, and the rewriter skips literals that exactly match — that keepsClass.forName("com.instagram.X")calls working.An internal
resourcePatchrewrites the manifest infinalize{}: package attribute,com.instagramreferences in identifier attributes (authorities, permissions, intent actions), and launcher activity-alias labels. Class-reference attributes like<application android:name>,<activity android:name>,<activity-alias android:targetActivity>, and<meta-data android:value>are left alone, because the Java classes those point at still live at their originalcom.instagram.*paths in dex.The two patches share package + label state via top-level vars; the bytecode side writes, the resource side reads in
finalize. Morphe's resource and bytecode contexts are separate APIs so this is the path of least resistance for a feature that needs both.Differences from the prior attempt (#1261)
Took the feedback and slimmed:
strings.xmlapplication-label override. App Info reads "Instagram" again; home-screen icon still shows the chosen label via the activity-alias path. Cosmetic regression only.Kept what the review flagged as unneeded, but that on-device testing shows is load-bearing:
com.instagramnamespace rewrite (not justcom.instagram.android). Sibling sub-namespaces likecom.instagram.fileprovider,com.instagram.contentprovider.*,com.instagram.barcelona.*,com.instagram.liteprovider.*and others are ContentProvider authorities. Android enforces system-wide uniqueness on authorities at install time. If the patched app keeps claiming them, installing the official Instagram alongside fails with an authority-already-claimed error. Verified on device both ways: with the narrow rewrite Play Store install fails, with the broader rewrite it succeeds.Smali / dex behavior
This isn't just a manifest rename. Every
const-stringliteral across the dex is checked against the namespace regex and rewritten when it matches, with the class-name spare above keeping reflection refs intact. There's no method-body hook (nogetPackageNameinterception, no signature-check bypass, no injected helper class). Held off on those because the cases we tested work without them. Happy to add targeted hooks if specific failures show up.Tested
com.instagram.androidv426.0.0.37.68 on a Galaxy S25 Ultra:SecurityExceptionfromcom.facebook.katana.liteprovider.FirstPartyUserValuesLiteProviderandcom.facebook.messaging.liteprovider.FamilyAppsUserValuesLiteProviderrejecting calls from the clone. Those are FB and Messenger refusing the clone because their providers pin on Meta's signing cert. No clone can pass those checks regardless of approach.Caveats