Why does this project contain Android Internals?

[hhff]

Hi folks,

Thank you for all the hard work. This project has been immensely useful for us!

I wanted to ask something I don't quite understand. This project appears to contain Android internal classes, like: https://github.com/klinker41/android-smsmms/blob/16deabc32353374c483e4182cae790951476c7b1/library/src/main/java/com/android/internal/telephony/EncodeException.java, etc.

Why is that?

Some context - we build our App against a custom framework_all.jar file (meaning we've exported all of the classes from our custom build of Android, and we develop against it).

We've just updated Gradle, amongst other things, at least a few versions, and when we go to build this library against our main codebase (using that framework_all.jar), and we mergeDex for the release, we get errors like this:

D8: Program type already present: com.android.internal.util.ArrayUtils
com.android.builder.dexing.DexArchiveMergerException: Error while merging dex archives:
Learn how to resolve the issue at https://developer.android.com/studio/build/dependencies#duplicate_classes.
Program type already present: com.android.internal.util.ArrayUtils

I'd love to understand why we have these classes duplicated here in the lib, so that I can either fork and delete them, or move forward in some other way.

Thank you!

[sredman]

From my studying of it, the answer to "why" is that Klinker needs to access classes (mostly data structures) which are hidden in Android. I would argue this is a bug in Android, since any app wanting to send MMS would need these data structures, and Android is supposed to be a phone OS so having support for "phone things" should be easy (IMO).

Unfortunately, I don't know if this gets you any closer to solving your problem. Most of the internal code that has been copied has been put into a different package (for instance android.mms.pdu becomes android.mms.pdu_alt), which I guess would avoid this problem. Maybe you could rename the packages giving you trouble to use the same pattern? (and submit a PR to this library)

[hhff]

Thanks @sredman - for anyone else who runs into this, I:

• forked the lib
• added the repo as a submodule to our mono-repo
• changed the buildstep to build our android-smsmms fork against our own framework_all.jar (rather than the official android sdk)
• one-by-one deleted the internals from our fork and ensured we could still build
• there were a few internals that are different in our framework_all.jar to the "duplicated" files in this repo, so I renamed those duplicated android internals (similar to how you suggested above) so they wouldn't collide with the true internals we're building against

Of course, this is a bit of a liability, because we now have duplicate android internals being built just to run this lib. But hey, it works and it works great! So I'm gonna pretend it's not a code smell.

Thank you for your note, this library has saved us a ton of work. Hopefully my note above can help someone in the future.