Amazon: An example on how NOT to run an app store

After a recent release to the app stores, my company discovered a crash in the public area of our Android app.  The crash was caused by a race condition in making HTTP requests.  It was crashing enough that we decided to deploy a fix to the Google Play and Amazon App stores.  Google Play has some issues (Google Play gives a cryptic error when you deploy two versions in "rapid" succession), but we launched in the store.  Amazon ended up rejecting us.

When you elevate to a store, you have to provide a demo account so that Apple, Google and Amazon to test out the functionality.  During the main release, Apple, Google and Amazon (in that order) were able to login.  Then, during the fix release, Google was able to log in just fine.  Somehow, in the hours between Google successfully logging in, and Amazon trying to log in, the demo account got locked out.  This shouldn't be that big of a deal.  We called up our support group to unlock the account.  We contacted Amazon to try again.  That is when we found out the bad news.  They can't just "try again".  We have to resubmit our app.  That frustrated us for two reasons.  First, in large companies, there tends to be some bureaucracy when it comes to changes to a production environment.  This is usually done to allow different groups a chance to reschedule or join a change.  Another reason resubmitting frustrated us is the Amazon upload process is really painful.  For those of you not familiar with Amazon's DRM process, here it is:

1) Upload your APK
2) Amazon adds their DRM jar into your APK, then modifies every Activity to hook into their DRM
3) You download the modified APK
4) You sign the APK with your digital signature
5) You upload the modified APK

In a small shop, this is not a big deal.  In a large enterprise, all production changes tend to be executed by a different team.  That team tends to have no clue what "signing" is.  You end up with multiple people on a conference call since different people need to do different parts of the change.

A few days later (due to a weekend and holiday) we resubmit.  After the overnight (Amazon test engineers seem to work in a timezone on the opposite end of the world), we get rejected again!  This time:

Bug Description:  "The App"  was found to be incompatible because of issues with the app’s interaction with Kindle Fire's hibernation feature. "The App" force closes, crashes, or loses user state after the device hibernates and then resumes.
Steps to Reproduce:
1. Install and launch the app.
2. Login using the credentials given.
3. Hibernate the device.
4. Unlock the device, app restarts and reverts back to the login page.

What Amazon calls a bug is actually a security feature that my company's (paranoid) security team said we must have.  We detect if you background then foreground the app.  If you are on a secure page (a page that requires you to be logged in), then we log you out and send you to the home page to log in again.  While our clients find this extremely annoying, we do provide the ability to disable the security feature.  You have to opt into it, though.

This is not a new feature.  Amazon has accepted our app before with this feature.  It seems to me that Amazon's test team is inconsistent with their testing procedures.  At this point, I'm wondering why we are even in the Amazon store.