PurchaseManager requests play havoc with pipeline thread.
We had a bug whereby tasks executed on AsyncTask's default pipeline thread were being cancelled before they started. I tracked the problem down to the in-app purchase SDK. This problem is likely to appear when either the SDK tester is not installed (dev) or the Amazon subscription servers are not available (prod). It appears that the server request calls inside the Amazon SDK either have no timeout set or are on an infinite call loop. It also appears that the AsyncTask that wraps those calls is being executed on the default single-threaded SERIAL_EXECUTOR - the same thread shared with all other AsyncTask calls in the process. I cannot find an api to override this behaviour. There is no PurchaseManager.cancelRequest(), for example, that could be used in conjunction with a timer to clear the thread. Please could we have some or all of the following changes in the next release of the in-app subscription SDK: - use the THREAD_POOL_EXECUTOR instead of the SERIAL_EXECUTOR with the AsyncTask that wraps the server calls - or an api to specify. - one or more cancelRequest() apis. - one or more setTimeout() apis. - one or more onRequestTimeout apis on the response class (although could also use existing request status field).
Android handles multiple Async Tasks differently pre- and post-Honeycomb. The execution of AsyncTasks does not depend on IAP SDK. Since the onXXXResponse() methods are called on the GUI thread, we recommend long-running logic in those methods be handled on a separate thread. They don't have to be, but if they take long the user will see the GUI pause. However if requests return very quickly, then there is no reason to "cancel" them, since they are asynchronous. The SDK handles timeouts internally, and you will get a canceled transaction response if the server times out.