I recently release an app for Kindle Fire. The app was approved by the amazon store, but was rejected for kindle. Following feedback was given :
We have recently evaluated your app’s compatibility with Amazon’s Kindle Fire tablet. This added test process is here to verify that every app available for download on Kindle Fire will provide our customers with a high-quality experience on their devices. Your existing submission of XXXXXXXX has been found to be incompatible with Kindle Fire due to the following:
Upon completion of our compatibility test processes, your app was found to be unresponsive when subjected to testing. To be compatible with Kindle Fire, the app’s core features must be responsive to user commands, and its primary functionality accessible and compliant with device specifications.
Please review these issues and update your submission to address the incompatibility. You may find it helpful to review the Kindle Fire FAQ in the Amazon Appstore Developer Portal.
Has anyone got any pointers on what could be wrong ?
Never developed for amazon, but the text seems to point out that your app freezes the user input in a certain situation.
Maybe there is some data retrieval that is not done in a separate process and freezes the ui?
I just received the same response from them and, I to, have apps they approved for their store, tested on, based on the Flurry analytics I'm using, less powerful devices than the Kindle Fire. It's pretty vague too, wish they offered a developer tablet or some more details. Only thing you can do is maybe guess what is unresponsive and hope it passes next time.
Sounds like you're getting ANRs. Read tips on how to avoid this here: http://developer.android.com/guide/practices/design/responsiveness.html
but most of the time it's caused by doing something long running (usually network calls) on the UI thread. Make sure you spawn another thread being doing a network call.
If you have access to a Motorola Xoom running Honeycomb 3.2 you might want to test your app on that. My app was rejected by Amazon because they experienced blank screens. I've tested it thoroughly on Kindle Fire and have never seen that behavior. It was only when I emphasized that point with the Amazon reviewer that I learned they were not testing on their own device but on Motorola's Xoom running an obsolete OS that I don't want to support. I now have a Xoom and my app runs fine on it under ICS but is quite buggy with Honeycomb.
Related
Recently I have discovered that about 2 months ago there was released Android 11 update for Samsung devices.
Samsung has in this version of OS decided to really strictly suspend the apps/services running in the background (more info)
So e.g. when app I am working on goes to background and phone is locked, all BT communication is almost immediately suspended. When I unlock the screen, in that exact moment all threads are not suspended anymore and execution continues.
OS therefore completely ignores the foreground service mechanism.
Official documentation
Also when I try to add my app to the list of "Never sleeping apps" (some alternative to battery optimization whitelist on Android 11) - app is still getting suspended + this whitelisting mechanism appears to be unstable and even when I add my app to the whitelist, app disappears from the list after few hours.
My questions:
Have you seen similar issues on Android 11 too ? What helped to resolve the issue?
Is this only Samsung specific issue or even Pixel devices do the same optimization (ignoring foreground service and whitelist)?
Thanks for any input.
sadly this is a huge and common problem and my repsonse will probably not fix it for you, but give you some more insights and possible work-arounds. Have a look at dontkillmyapp.com.
Especially dontkillmyapp.com/samsung:
On Android 11 Samsung will prevent apps work in background by default unless you exclude apps from battery optimizations. This is a severe divergence from standard Android process management policies.
Yes, this is a long way to go! Devs cannot ask for it automatically as they risk being kicked out from Play Store due to policy violations.
Also I can highly recommend very insightful the fun talk fron Droidcon Berlin 2021.
I'm having trouble with an app I published that sends user notifications.
The notifications are called from a background service that checks for a boolean that gets saved to SharedPreferences when the user selects to enable notifications or not.
However, I've had some users on the Galaxy S5s say that they can't turn them off (I test with nexus devs and have beta testers on m8, etc). How do I address this issue?
What is the strategy for solving problems that arise only for specific devices?
IMO, Android kinda sucks in that regard. There is absolutely no way to guarantee that if one piece of code that works on one device works on another one. Since Android is open source, manufacturers usually modify the firmware to make it kinda customized. However, they sometimes change things that will affect performance of a single function.
It is even worse! Your code might work on S4 with Android JellyBean, but not work with the same device Android Kitkat. Anyways, no - there is no way to debug without the actual device. However, you can log different events in your code and use an analytic service (like Google Analytics) and send the data to your database to study and figure out the problem. This is the method that I typically use in such cases.
If the problem is that the app crashes on some device. It is even easier. Users need to press on the "send crash data" button - so you can study the log on your developer account.
I recently released my app to the Google Play community. The team and myself tested the app on Gingerbread, jellybean, and kitkat. All were either Samsungs or Nexus. Now we have someone getting a crash on a Motorolla Droid Bionic, Android version 4.1.2.
My app required wifi (not Cell data) connection which is not possible with androids emulator. I am in the process of installing android on VirtualBox but I don't know if this will allow me to identify the problem.
Should I be this concerned? This is my first app and I want to make sure it works for everyone? This app is for controlling a home appliance so I feel like we need to make sure that it works, but I'm not sure how to really get accurate test results and error messages.
What do other developers do to emulate accurately specific phones and OS versions?
thanks for any advise and help.
Ask for the "Stack Traces" reported in "Crashes & ANRs" section of your application in Google play Developer Console to have more details about the problem.
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've an app in the market with a few crash reports of "java.lang.RuntimeException: native typeface cannot be made". This is covered elsewhere on SO and I know where in my code it is. That's not my problem - the problem is finding out which Android version and handset type is causing it. I've never seen this on any handsets the app is tested on, nor does any version of Android on the emulators raise it. The only crash errors I see are these and always on "Platforms OTHER". I'm assuming if a different crash was reported I'd get a better clue regarding the platform - I'd expect to see "8", "11" etc.
It's a paid app. It happens right on first run so the users are cancelling the purchase.
Does anyone know what this platform is please?
In my experience, the developer console reports very few of the crashes occurring in your app.
If your app already requests internet permission you can use an error reporting library.
I use ACRA in my app. It's very easy to integrate and you'll be amazed at the number of crashes that don't get reported in the market developer console.
The Platforms section displays the device the crash occurs on, not API level. However, as you've seen, it's very limited. The only values I've seen besides OTHER are
T-Mobile myTouch 3G
Nexus One
Droid
Anything else is lumped in with OTHER. Obviously, the list of devices it separates out is vastly incomplete and not very helpful. Until Google improves it, the Platforms sections is essentially useless and I recommend using a third party library to get better information.