lihq / seek-for-android

Automatically exported from code.google.com/p/seek-for-android
0 stars 0 forks source link

SEService::GetReaders has bad performance and can crash client Application (especially in Android Jelly Bean) #37

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I have a test that create 10 thread that each does new SEService and GetReaders 
and then so on and so forth all the way down to transmitting APDU in logical 
channel.

What i discovered is that on Android JellyBean device, PackageManager is easily 
craching during that process when one of the thread call GetReaders (becuase of 
out of memory situation0.  Upon further study, there's PackageManager is being 
killed and that trigger uncaught exception on Client level.  With some root 
cause analyze, 2 thing is discover.

1) GetReaders always call AddonTerminal.java getPackageNames always get a whole 
list of all installedPackages
2) then it does an expensive loop of comparison against 2 strings, that can be 
100ms+

If AddonTerminal.getPackagesNames is not thread/process safe, then 
Getinstalledpackages in ObjectManager can also take extended period of time 
that's the case, the long operation can easily be pre-emptted and result in 
large amount of memory being allocated at the same time.  This issue would need 
to be addressed because:

1) because the getPackageManager and string comparison is extremely expensive 
in performance.
2) more importantly, the memory foot print that is needed.

AddonTerminal does not affect the build in Readers (UICC, eSE, uSD), is there 
any real life use case other than for testing purpose?  if not, should it be 
done on the Service.onCreate time and have that information cached?

Original issue reported on code.google.com by tommypo...@gmail.com on 14 Sep 2012 at 8:44

GoogleCodeExporter commented 9 years ago
Did you verify that your tests run through when you moved the call 
updateAddonTerminals() to onCreate() where the buildin terminals are also 
created?
In this case it's easiest if we also keep the AddonTerminals static over the 
service life-time.

Original comment by Daniel.A...@gi-de.com on 18 Sep 2012 at 10:41

GoogleCodeExporter commented 9 years ago
One possible "workaround" to this crash, could be making AddonTerminal.java 
getPackageNames to be thread safe, which is by adding synchronized keyword on 
the function declaration

Original comment by tommypo...@gmail.com on 23 Apr 2013 at 8:49

GoogleCodeExporter commented 9 years ago
Still seem to be reproducible on 3.1

Original comment by tommypo...@gmail.com on 19 Dec 2013 at 9:53