I put out an android app last week, and wanted to release an update to it that will include additional phrases to a specific aspect of the app. It isn't a big release that serves as a bug fix (no known bugs actually - fingers crossed ;p) but it will certainly add to the entertainment value of the app and add a lot of flexibility.
Is this poor practice, as new releases should include a lot of content or is this accepted for the most part?
Thanks!
AFAIK, We can release minor updates to the applicatio as well, it is always acceptable and desirable.
I have also released the minor updates to my one of the application, they were for the solving the bug and issues raised in the application.
So you can also do the same !!
But for that You need to Change the versionCode and versionName attributes inside the AndroidManifest.xml file for releasing a udpate version of the same application.
For example:
android:versionCode="2"
android:versionName="1.0.2"
IMHO that's fine - in fact desirable.
Additional content is always welcome.
I use a Spanish Verbs app, and early on it had some important verbs missing, but I was glad when they came in soon after.
Related
I have an app that accepts certain data from other apps. Those other apps typically check to see if my app is installed. For some reason some of those other app developers do some convoluted checks and sometimes those fail. This often leads to me getting bad reviews because those apps tell the users to install my app and they do but then it keeps telling them that because it can't find my app.
So I decompiled one of those apps and I think I found the issue. They get a list of installed apps like this:
getPackageManager().getInstalledApplications(128)
128 appears to be PackageManager.GET_META_DATA but I have no idea what that means and why my app doesn't appear on the list when that is called?
I've read on this post Android PackageManager can only detect system apps on physical devices that it could be related to package visibility on Android 11 https://medium.com/androiddevelopers/package-visibility-in-android-11-cc857f221cd9 however I tried adding that <queries> element and it didn't help at all. Is that something they need to add or something I need to add?
Edit: Figured out how the <queries> thing works. The app searching for my app must have it. So this doesn't really help me. Is there any way to get my app to show up for those apps when they query packages?
I have no idea what that means
It means that the returned data will include contents of <meta-data> elements in your manifest.
why my app doesn't appear on the list when that is called?
It is unlikely that the problem has to do with GET_META_DATA directly.
However, IIRC, those PackageManager methods are capacity-limited and may not return all results if there are too many or they are too large. In that respect, GET_META_DATA will increase the size of the response and may cause that response to be incomplete in terms of the elements in the list. If your app is missed as a result, then that would give you the behavior that you are seeing.
IOW, the real problem is that they are calling getInstalledApplications() in the first place. GET_META_DATA just makes the situation worse.
For some reason some of those other app developers do some convoluted checks and sometimes those fail
Consider supplying an SDK that handles the check, using more focused techniques than "getting the list of all installed applications along with their <meta-data> contents". Depending on the nature of your app, that SDK might also include code for checking the signature of your app to confirm it matches an expected value, so the other apps don't try communicating with some imposter or cracked version of your app.
In "Targeting" section of a Firebase A/B test, you should be able to target by version:
The version of the app (can vary by platform)
Is this supposed to use versionCode or versionName on Android? Simple question, yet I can't find the answer anywhere, and the documentation is useless in this regard.
My initial assumption was that of course it uses the numeric version code (e.g. 789). But I've tried both that and version name (e.g. 5.5.1), and neither seems to work — "0 users exposed"! (Or the delay before the report updates is very long.)
I've also been assuming that Firebase SDK automatically reads the version info, and it's not up to you as developer to programatically set it, but please correct me if I'm wrong!
I'm using Remote Config based A/B tests, should it make any difference.
Right, turns out it uses versionName. (Experiment data was coming in with a long delay so it was hard to tell.)
You can use exact matches, "contains", and regexes:
Since ACRA.init can only be called once and ACRA.getConfig() and ACRA.getConfig().setFormUri(uri) are both deprecated.Is there any correct way to change formUri programatically, once ACRA has been already initialized?
In our development app we are testing against several environments and we have different formUris to store ACRA errors, so each time we change to a new environment we must reconfigure ACRA to send all the errors to that formUri.
Right now we are using ACRA.getConfig().setFormUri(uri).
But we are afraid that this won't be possible in the nearby future, so is there any alternative?
There are no plans to allow ACRA to be initialised multiple times. It would introduced unnecessary complexity into a component that you need to be as rock solid as possible.
But you still have the capability of setting the formUri programmatically. You can just set it only once.
You clearly have some event at runtime that knows/determines which environment you are in. So you could set a SharedPreference at that point outlining the target formUri. Restart the app and have the formUri come from the SharedPreference.
NB this is an extremely unusual use case. Why do you have a separate formUri for the different environments for the one app? Why not have a single error repo and filter reports based upon some attribute in the report, such as environment?
IMHO having separate error reporting servers for even dev and release versions of an app is a nett negative as it means there is one more thing that you have changed between dev and release that you didn't need to. Less moving parts, less complexity == greater robustness.
But we are afraid that this won't be possible in the nearby future
You are right, 4.9.0 removes setFormUri
So is there any alternative?
Currently not. You can watch the discussion here.
The 5.2.0 version of ACRA will allow re-initialization, so the correct way will be to alter the configuration re-initialize.
Specifically, ACRA.init() will succeed but emit a stern warning for all inits after the first time, but it will throw away the old configuration and take settings from the new one.
Background
It seems some old Android OSs (and maybe even the newest ones) have a limitation on the amount of code each app can hold.
As I've found, the limitation is on a buffer called "LinearAlloc" .
On 2.2 or 2.3 it's about 5-8 MB , and I think it's 16 or more on others.
The problem
If you have a too large code (and apps can reach this state), you won't be able to install the app at all on older devices, getting the next error (also reported here) :
Installation error: INSTALL_FAILED_DEXOPT
Please check logcat output for more details.
Launch canceled!
What I've found
One solution is to just remove as much code and libraries as possible, but on some huge projects such a thing is very hard to do.
I've found the next links talking about how Facebook solved this, by somehow increasing the limit:
http://www.slashgear.com/how-facebook-fixed-its-gingerbread-dalvik-problem-04272478/
http://arstechnica.com/business/2013/03/how-facebook-dug-deep-within-android-to-fix-its-mobile-app/
https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920
Also, Google has posted how to solve it by loading code dynamically :
http://android-developers.blogspot.co.il/2011/07/custom-class-loading-in-dalvik.html
The question
How did Facebook do it?
Is it possible to overcome this in other ways too?
Is there any free library that increases/removes the limitation of this buffer?
What is the limitation on newer Android versions, if there is any?
How do other huge apps (and games) handle this issue? Do they put their code into C/C++?
Would loading the dex files dynamically solve this?
The limit is the total number of method references:
https://code.google.com/p/android/issues/detail?id=7147#c6
https://code.google.com/p/android/issues/detail?id=20814#c6
A middle ground between doing nothing and the multi-dex approach described in the FB/Google articles is to use a tool like ProGuard to remove references to unused code at the Java level. See:
http://proguard.sourceforge.net/
http://developer.android.com/tools/help/proguard.html
There is a new solution, made by Google:
https://plus.google.com/+IanLake/posts/JW9x4pcB1rj?utm_source=Android%20Weekly&utm_campaign=59f1f4bf4d-Android_Weekly_125&utm_medium=email&utm_term=0_4eb677ad19-59f1f4bf4d-337848877
http://developer.android.com/reference/android/support/multidex/MultiDexApplication.html
It seems all you have to do is any of the next things:
- extend from "MultiDexApplication" instead of from "Application"
- call MultiDex.install(context) in your application's attachBaseContext
But now I wonder:
Is that really it?
Does it have any issues ? Does it affect performance?
How does it work?
What should be done with ContentProvider, as it's getting called before Application gets initialized?
The post says "gives you MultiDex support on all API 4+ devices (well, until v21, where you get this natively)" . Does it mean that from v21 it will be the default behavior, or just that the class will be built in and you won't need to use the support library's class ?
Will this solution work on Eclipse too?
Periodically I'd like to make very minor changes to an app on the market, that don't justify notifying users that they need to upgrade. For instance a little cosmetic tweak. Basically I don't want anyone (including my client, for whom I built the app) to notice that I made the change, but I'd like all new downloads to get the changes. Can I do this, or will making any changes cause everyone to be alerted there is a new version?
I understand where you're coming from but this is a very bad idea. If it were possible you could have a bunch of people with the same version numbers but a different program making it very difficult to track if something goes wrong.
You can however increment only the integer version and leave the text version the same (this only shows in the market anyway).
This will still cause people to get auto updates for your app. I think you should either bundle all your changes up and wait or just accept that everyone will be getting lots of updates for your app.
Unfortunately Prashant's answer is not correct. You only need to increment the code, not the human readable version string.
I frequently leave the user visible version number alone when releasing minor tweaks and bug fixes, saving the market visible version numbering for actual features and major bug fixes.
Well last time i tried to the same thing, i got a message that application version numbers needs to be incremented before uploading a new version of the application. Also, version number and version code need not be in sync. But both needs to be incremented before uploading the new apk in market place. Hope this helps.