So it seems like "preferExternal" is totally and completely broken at least for some percentage (maybe 3%) of the Android population.
After deploying an update for my app with android:installLocation="preferExternal", some users have reported a few issues.
"Your app disappeared from my phone"
"Since your latest update, everytime I restart phone the app is removed from homepage"
So I tell them either to 1) Move the app to the phone (settings, apps, app name, move to phone) or if app is truly gone (which appears to be the case for some) 2) Unmount SD card, re-install app from Play Store (My Apps screen), Re-Mount SD Card.
Ok, so those are the workarounds.
There are a few things I could use some guidance on:
Is this issue due to a certain Android OS level or just random?
Is it a known Android bug?
Will deploying yet another update with
android:installLocation="auto", prevent these issues (and why)?
Please answer what you can. It's actually quite a horrifying issue since there could be many users I'm not aware of that have had my app mysteriously disappear from their phones. Yet Google still lists this as a valid option in their documentation.
Related
We are building an app in Unity for the Samsung S21 specifically, and we are noticing an interesting bug that resembles the following: https://issuetracker.unity3d.com/issues/android-not-enough-storage-space-to-install-required-resources-error-when-building-app-bundle-with-split-application-binary.
We have isolated it to phones that are "Fully managed" with Samsung Knox, and have noted that this occurs across all apps made with Unity, including major commercial releases on Google Play. This does not appear to be an issue with non-Unity apps.
After a factory reset, our app installs fine, but once it is updated or uninstalled and reinstalled we get the message "Error: Not enough storage space to install required resources." I have noticed that certain folders do not delete after the app is uninstalled--specifically /files/il2cpp and /files/Unity, and I cannot delete these on Knox-protected phones, while I CAN delete these folders on standard devices.
My Knox security settings say "User Deletion: Disallow."
I know that Knox is the issue here, but I am curious if anyone has any explanation what in particular with Unity is causing the problem. My suspicion is that this is because my Knox security settings do not allow me to delete, but it is interesting that this only seems to be the case in Unity apps as apps not developed in Unity (NBA Live is an example) uninstall and install fine. It is also worth noting that this all seems irrespective of the link I put above with the initial bug that claimed it was related to splitting the application binary.
We determined that using the Managed Google Play store only for downloads does not produce the issue. Any downloads from the commercial store--specifically Unity apps--will cause this issue. There is no workaround for this. If the organization with which you are working would like to be able to install a specific app on a phone with an account managed through Knox it must allow the specific app on the Managed Google Play store.
First question, appreciate some guidance. I am currently teaching myself to develop for Android and have installed my app (via Studio after builds) onto my own phone.
Every now and then my phone will restart itself (not querying that - these things happen).
During these (occasional) restarts I will get a message that Android is "Optimising App 1 of 1". I am pretty sure it is my app being "optimised".
I have searched here and the Web. Most of the questions seem to be users that have recently upgraded OS Version and that is causing the issue. There seems to be anecdotal evidence that wiping the cache cures this and that it only does it while the device is being charged.
However, if it is my app, I don't want users of my to go through this. I suspect it relates to the Target SDK I am using but it might be something different?
So, what is Android optimising? How can I make best efforts to stop my app being the cause of this?
Many thanks.
Earlier Android OS used to run on Dalvik Runtime which means apps used to compile at the time of execution. But now, Android has switched to ART with Lollipop version. It means all the apps will be compiled beforehand making them launch faster. So "Optimizing the Apps" basically means Android is compiling all the apps.
From Android 5.0, Android uses ART instead of DVM So every time your mobile OS upgraded This will happen. Also “Optimizing app” should happen only once after OS upgrade. If it’s happening every time then there is some issue in your mobile.
A factory reset should be probably solving this. (You have to go
through the pains of redownloading all your apps etc).
I have seen many solutions to check if our own app is minimized,running or background.but is there a way to check if another app package is running or minimized so that based on that we can run a code.like an app-locker.Here we need to turn off network for a certain apps according to the user selection on installed apps in device, so when that selected apps are on foreground, network should be disabled when the selected apps are closed or minimized.then enable the network.
Will it be compliant with Google play if we make such an app? because somewhere i read they don't allow apps that interfere with other apps.so confused.
TL;DR: Google doesn't want you to do this, and you shouldn't try.
The old hack that relied on ActivityManager#getRecentTasks() to find out which app is in the foreground was disabled starting in Android 5.0.
App lockers that work on Lollipop are using a new hack involving ActivityManager#getRunningAppProcesses(). How it works is described in this answer. This hack is reportedly broken on Android M.
There's a new UsageStats API from which you might be able to glean a bit of info, but it requires a permission that can only be granted by a system activity. It's documented that this system activity may not be present on all devices. Samsung and LG are among the manufacturers that have reportedly removed this activity from their Lollipop devices, so only system apps will ever be able to use UsageStats.
The bottom line is that Google has shown their commitment to preventing what you're trying to do. Even if you find a temporary solution, you can bet that it will stop working in a future Android version. Eventually, Google will close all the loopholes and your app will be permanently broken. So it's probably a waste of time to write a new app that depends on this capability.
I have a somewhat unusual Android app in the Play Store that's running on dedicated devices 24/7 (it collects sensor data, it's not meant to run on phones used for anything else). I would like the app to auto-update without user interaction, but that never seems to happen. Why could this be?
Some more background:
Auto-update is explicitly turned on for the app on the devices.
Other apps do seem to auto-update.
The app stops and restarts itself every 12 hours; mostly to whack the app out of any weird state it might get into and clear memory, but I was also hoping this would give it a chance to auto-update. There is a 10 second delay until the app restarts.
The devices are mostly old phones (HTC Desire C) running Android 4.0.4
This is fairly hard and time-consuming to test so any experiences shared with similar requirements could be helpful.
Make sure the port 5228, TCP and UDP, is not blocked by a firewall per https://support.google.com/googleplay/answer/2651367?hl=en
We've had a similar problem for years. Our apps run on school deployed devices. Whenever we push an update, it reaches may be 10% of devices within 24 hours, the rest seem to "hang". It takes about a week for another 30% of devices to get the update, while the remaining %60 never get it. There is no difference in settings across devices. All set to auto-update of course.
The way we "solved it" is our app is checking if the market has a newer version (there are libraries for doing it, but we have own server responding yes/no). If there is a newer version of the app, we invoke the intent to open Google Play with the app's page. The user has to manually click "Update" at that point.
If there was a native or cleaner way to push the updates we'd love to hear, even at this point in the game. Bothering users to update is not ideal.
This is a long shot: Maybe there was any change in the apps required permissions?
That would require manual updating (even if auto-update is on). Maybe you installed the app first in those old devices, then changed the permissions, then installed the app in new devices, then updated the app. That would make the autoupdate system work in the newer devices, and not work in the older ones.
I have recently published my second app on the Android Market. I've gotten a few e-mails about the app crashing on open, and all users were using the Motorola Backflip. It seems to work fine on all other devices. The app shows the background image, but crashes right after that.
Is there something different I have to do when coding for that device?
The strange thing is that it is very similar to my first app, which seems to work just fine for them. The major difference is that my second app is a paid app, and uses Android Licence Verification. My implementation should catch any license errors though, and I've tested this on my device.
Users have uninstalled and reinstalled the app without success. I'm stumped.
The other thing they're reporting is that the icon doesn't even show properly, but rather is a gear in a box, which makes me think that something goes awry very early in the installation process.
The solution was to have a user install aLogcat on their phone to send me the log.
It had to do with onCreateDialog. I was returning several dialogs, but one of them actually called .show(), which it's not supposed to do, of course. The thing is that this didn't cause an error on any phones except for the Backflip. The emulators also didn't error, or even warn me about it.
I have a motorola backflip and i can say that is not a good product....it's crashing for a lot of things....don't worry, your app is not wrong, the phone is wrong...