I would like to determine which third-party SDKs (like Mixpanel, Google Analytics, Facebook SDKs) are being used in an app, if any. Is there a way to find this out?
Assume for the purposes of this question that I am not the developer of the app, and therefore I don't have access to the source code.
You can use a service like Appbrain to find that out. It's free for the first few lookups.
It's not possible to reliably enumerate the libraries used by an application, for a few reasons.
The main reason is obfuscation: If a user turns on Proguard or R8, they will rename the library's classes, potentially in such a way as to make them unrecognizable.
Another reason is that there's simply not a comprehensive list of every Android library in existence, or a mapping of class names to libraries.
However, if you did want to try to do this, you'd want to retrieve the application's class files and then hunt through them for the start of package names from libraries you care about (as obfuscators are less likely to rename the entirety package names, though they still might). For example, if you wanted to see if an application uses okhttp3, you'd look to see if there are is an okhttp/okhttp3 folder (for the package okhttp.okhttp3).
You could maybe even automate this by finding a list of popular Maven/Gradle packages, downloading them, extracting the class names, and using that as your dataset.
Related
I would like to determine which third-party SDKs (like Mixpanel, Google Analytics, Facebook SDKs) are being used in an app, if any. Is there a way to find this out?
Assume for the purposes of this question that I am not the developer of the app, and therefore I don't have access to the source code.
You can use a service like Appbrain to find that out. It's free for the first few lookups.
It's not possible to reliably enumerate the libraries used by an application, for a few reasons.
The main reason is obfuscation: If a user turns on Proguard or R8, they will rename the library's classes, potentially in such a way as to make them unrecognizable.
Another reason is that there's simply not a comprehensive list of every Android library in existence, or a mapping of class names to libraries.
However, if you did want to try to do this, you'd want to retrieve the application's class files and then hunt through them for the start of package names from libraries you care about (as obfuscators are less likely to rename the entirety package names, though they still might). For example, if you wanted to see if an application uses okhttp3, you'd look to see if there are is an okhttp/okhttp3 folder (for the package okhttp.okhttp3).
You could maybe even automate this by finding a list of popular Maven/Gradle packages, downloading them, extracting the class names, and using that as your dataset.
Since it's popular to have both a free and a paid version in the android market of the same app, I had decided to do the same. Initially I just duplicated the complete codebase and adapted some code here and there (added ads, built in some limitations etc) since there was no option to do library projects at that time, but that left me with two projects that are horrific to manage fixes to bugs as I need to do those twice.
Since r14 we can use library projects with resources, so that would be a great solution to this particular problem as far as I can tell. Therefore I've read up on library projects and conciderations, and I'm curious to know what the minimum amount of files needed in the projects of the different versions are. My questions therefore are;
Could I have all of the code in the shared project, and have bare bone project with basically just a manifest?
If so, should I? is this the optimal way conceptually? (so apart from the fact that it depends on my code base)
How should I deal with library package naming, are there specific rules?
Are there tools about that can compare code from two different projects and perhaps merge them auto-magically or auto-manually, and which one is preferred?
If I understand your problem correctly, you want to create multiple Android apps that are similar to one another (i.e., have a lot of the same source code), but which are different in particular (minor) ways, and you want each of these apps to have a distinct package, so that it can be separately uploaded and distributed on an app store such as Google Play. A Project Library is an excellent facility for accomplishing those goals.
I'm assuming that the differences between your various versions are minor, involving things like resources and the app name and package, and a switch that turns on certain features for a paid version while leaving them off for a free version.
Even if that is not the case, by using polymorphism in the ways described below, your various apps could differ in significant ways and still share a common Project Library.
A Project Library can be defined in Eclipse in the same way as any Android project can be defined, but it is marked as a Project Library (by checking the "Is Library" box near the bottom of the Android page of the library's Project Properties dialog) and cannot be compiled and run on its own. Instead, it is intended to be included by reference in one or more other projects which are actual apps (by adding a reference to it on the Android page of each such app's Project Properties dialog). These apps will use the Project Library, and thus will share its code and capabilities.
Each such referencing app will have its own manifest file (where their respective, different packages can be declared), and they can also define their own classes (including classes derived from the Activity and/or Application classes of the Project Library), so that these classes can be specialized polymorphically for each app that uses the Project Library (e.g., by overriding methods or by providing definitions for methods that are defined as abstract within the Project Library's Activity- or Application-derived classes), although you can also use those Library classes without modification (provided that they are not abstract) by simply referencing them within the manifest file (e.g., in an activity or application tag) of each app that uses the Library, just as you would reference Activity or Application-derived classes defined within the app itself.
If you decided to use this approach, then you would put your main source files in a Project Library, and would create a separate project for each app you want to produce, each of which would reference the Project Library. The manifest file of the Project Library would be overridden by the manifest of whatever project is being created using that Library (actually, I think that the Project Library's own manifest is completely ignored, not just overridden, but nonetheless it is useful to create a manifest for the Library, so that you can manually template - copy and edit - the manifest of each project that uses it from the Library's own manifest).
I have used this approach to create multiple android apps that share some of the same capabilities, and it has worked very well for me.
Regarding package naming, any old package name will work for a library project, but of course it makes sense to use the same prefix for the Library Project's package as you use for your various individual (e.g., free vs. paid) apps that use it, with something like ".library" as the last part of the name, while the various apps could have endings like ".myappfree" and ".myapppaid". Naturally, you would want to use your reverse domain name convention for the library's package prefix to prevent conflicts, just as you would for a package name of a released app.
In Windows, a nice, open-source tool for comparing code bases is WinMerge:
http://winmerge.org/
If I were in your position, however, I would only use this tool to manually identify differences, and would not attempt to use it to automate the refactoring of your code into a Library Project. That would be best done under your own (manual) control.
Finally, as an alternative, you might consider using a single app that is free and that has your free app's capabilities by default, with an option to upgrade to your full app's capabilities (delivered within the same APK) via an in-app payment, rather than having separate free and paid apps. In-app payments have improved a great deal in the past several months (with the release of version 3 of IAB), and although there are still some glitches, they have become a more practical alternative to the free/full dichotomy than they were at first.
Yes, you can have a project that is basically just a manifest specifying app name, name space, icon etc, with all the actual code and 99% of the resources in the library project.
Yes, I think you should use this approach. It's very common to use library projects to deal with the Free/Paid app problem.
I've not had any problems with naming, though you should be careful with any resources in separate projects to avoid using the same names.
I'm not aware of any tools, and if it were me I'd want to do it manually to be sure I'm merging what needs merging and keeping separate what needs to be separate. you've one significant refactor to do, but once all the duplication is removed I'm sure it'll be much easier.
I am working on a set of novelty applications that share their fundamental behavior (picking random words from a database and combining them). Because they all work BASICALLY the same, I tried to treat the base of the code as a template of some sort, with mixed results.
As I am working on an update, I wanted to make the project a little more MVC friendly and started looking into using a ContentProvider instead of a straight SQLiteOpenHelper. I am leaning this way because Google's documentation is INCREDIBLY adamant about using them. My issue is in the realm of naming collision.
TL;DR Skip here for the question.
If two 3rd party Android applications (made by the same developer) both want to use the same ContentProvider, but not rely on another application being installed, can they both include a copy of the ContentProvider (with the same authority and everything) and be allowed to be installed at the same time (using the highest version of the ContentProvider available)?
I am not sure if this is possible with the way content providers are set up, which seems monolithic. I can't imagine Google didn't see this as a potential problem or desired feature. Yes, some complexities could arise, but we have overcome dll hell and other similarly named problems... it can't be all that difficult to do right.
I am leaning this way because Google's documentation is INCREDIBLY adamant about using them.
Not all Googlers agree with that position, let alone other schmucks like me. I only use a ContentProvider for sharing data between processes.
If two 3rd party Android applications (made by the same developer) both want to use the same ContentProvider, but not rely on another application being installed, can they both include a copy of the ContentProvider (with the same authority and everything) and be allowed to be installed at the same time (using the highest version of the ContentProvider available)?
AFAIK, the first ContentProvider registered would win, not the highest version. In fact, I'm not sure the second app will install if it attempts to redefine an existing ContentProvider.
Moreover, if the user uninstalls the current ContentProvider, the other app is screwed, since its data now goes "poof".
Ultimately I wish to produce a compressive Contact Manager with some specific features.
I thought it would be good to experiment by extending Contact.
So using git I checked out froyo-release and tried to build it.
That didn't work so well as it contains things like
import
com.android.internal.telephony.CallerInfo;
and friends.
I'm considering the following two approaches:
Suppress the internal stuff under
the assumption that I really don't
need it.
Start with a toy Contact Manager
and implement (reinvent) everything.
My guess is that I am going about this incorrectly.
"I want that third alternative" --kirk.
Just for completeness, the new special behavior is to provide
an action list for a contact based on the types of that entities data.
A lot of the applications that ship with the platform unfortunately make use of non-public api's, which means they require a lot of hacking to build as sdk apps.
You can build them as part of a full platform build, or you can modify them to connect to the private api's via reflection or by including stubs for the private api functions that will get automatically stripped out later (as their names conflict with the real ones) - but if you want the result of your work to be something you can portably and reliably distribute other than as part of a rom upgrade, you probably need to rework things to use only public APIs.
If I needed to build an android SDK that other developers can integrate into their android apps, is jarring my SDK the only way to go about it? As far as I have learnt, jarring has the following considerations:
If your app uses a layout, then you have to create it programmatically. Since jar files cant carry any resources.
The jar will needs to be placed in the lib/assets folder and added to the build path (in Eclipse) -- Learnt here: Android - Invoke activity from within jar
The main app will have to create an Intent object and specify the package and class name in the jar to start the activity.
Any one have other ideas of going about any of the above steps?
Thanks
George
Creating a JAR is, in my opinion, a very bad decision. Android has specific features just for the kind of thing you're looking for. If your JAR:
provides some sort of (structured) data to be used in other applications, use a ContentProvider;
does some backround processing and makes that processing's results available to other applications, use a Service;
provides an Activity that gets some input from the user (or shows some information about something), eventually processes it and returns it to the calling Activity, just create that Activity and any application will be able to start your Activity as long as it's installed on the phone.
If you use one of the three solutions above, third party apps will be able to probe for whether your application is installed and, if not, prompt the user to install it. Only if your application does not fall into one of the three bullet points mentioned above should you use a JAR. Otherwise, using a ContentProvider, Service or Activity provides:
More standardized interaction between components
Better maintainability -- if you update your SDK you won't have to call everyone who uses it and tell them to upgrade.
No duplication -- if you were to provide a JAR and multiple applications that use it would be installed on a device, multiple copies of the JAR would be present on that device, thus using more memory than it has to. If you provide one of the three components mentioned above, one copy will satisfy all applications that need to use it.
Again, these components are specifically designed and provided by the Android OS for creating such SDKs. Please, only use a JAR if you really, really have to. Otherwise, provide a standardized ContentProvider, Service or Activity and document the way it's supposed to be used (i.e. how to use/query/integrate it).