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".
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.
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.
An Android application that I am interested in (OpenSudoku) has become unmaintained by the original author, who last updated the application just under a year ago, in addition they have rejects offers of help from others to contribute directly to the hosted SVN repository.
I am interested enough in the project to seriously consider forking it (I am already familar with many arguments for and against forking in general), but I do have a couple of questions related to best practice with forking Android applications, specifically:
I understand that I will have to change the package name/namespace, is there an easy method I can use to do this (without breaking the Eclipse project files and associated references)?
Is there a way to help users that may want to migrate to the new application, recover settings/data from the original application? (My understanding is that the permissions model that Android enforces would make this impossible)?
Are there any other issues that I should be aware of that comes with forking an Android application that I would need to plan for?
AndroidManifest.xml, various build system files, layouts that use your own views, each Java source file, and the directory tree. That's what you have to change. I use vim -p glob glob glob for changes like this, and mv, which is easy enough.
Not unless the old application cooperates, which it likely doesn't. Perhaps your fork could detect an OpenSudoku install and prompt the user to install, off-market, an 'update' for it that just repackages its preferences for your consumption. I don't know if that works, updating a Market app with a non-market APK. Although, you said "settings/data". If 'data' includes e.g. sets of puzzles on the sdcard, yes, you can load that kind of data without any trouble -- FAT32 offers no security.
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).