After we have learned everything we need to know we now can focus on the concepts loading our JCE. Therefore we have to distinguish between standard Java platforms and special Java implementations like the one for Android.
On standard Java systems we ship a simple jar-file which can be used as library to dynamically load our JCE. There is also a static installation method that enables our JCE being present in the whole Java Runtime Environment.
Contrary to the standard Java system there is no static installation available for Android. Here developers would always have to link our library to their program in order to use our JCE. Due to this reason we developed our own loader concept for Android which enables our JCE being preinstalled once per device and avoids multi-linking for serveral apps. Lets have a deeper look at those concepts.

...

Loading our JCE on Windows / Linux – standard Oracle Java

On standard Java / Oracle platforms there are two ways of installing our SmartCardAuthProvider. We whether have the choice to install the SmartCardAuthProviders statically to our system or loading it dynamically.

...

Static installation

In order to install the static provider there are two steps necessary. First we have to install just copy the jar-library to the "Java\lib\ext" folder where Java points to the location of your installed JRE. Afterwards we have to edit the "java.security" file stored in "Java\lib\security" and add the following line where X is a number starting at 1:
security.provider.X=com.certgate.jce.staticinstall.StaticSmartCardAuthProvider

Higher numbers mean lower priority. The priority can be seen as a order for asking the providers if they support a demanded algorithm when it is equal where the algorithm comes from. We suggest using 1 as priority and increment all other providers previously listed in that file. After a restart of the JRE each Java program will be able to use our provider. The provider - if necessary - can be retrieved by using the following lines of code:
AuthProvider p = Security.getProvider("CERTGATE SmartCard Provider");

When this line is executed the first time within a program the StaticSmartCardAuthProvider is initialized and will use the first reader which has a smartcard present. When no reader is found or no reader has a smartcard inserted the reader returned by getFirstAdditionallyReader is used (see 3.1 for more information).

Dynamic loading with SmartCardAuthProviderManager

When our jar-library is linked to your code it is recommended to use the SmartCardAuthProviderManager to initialize all providers i.e. for each smartcard reader found within your system an own provider is created. This can be done with:
SmartCardAuthProviderManager.getInstance().registerAllAvailableProviders();

The registered SmartCardAuthProviders can e.g. be retrieved by:
SmartCardAuthProviderManager.getInstance().getRegisteredSmartCardProviders();

Dynamic loading with our SDK / library

...

1. Register the P11ModuleManager at the ReaderManager
   
   ModuleManager moduleManager = P11ModuleManager.getInstance();
ReaderManager.getInstance().setModuleManager(moduleManager);
   
   
2. Cycle through all available ReaderModuleDescriptions, create a SmartCardAuthProvider and add it to the system

...

1. systemVector<ReaderModuleDescription> descriptions = ReaderManager.getInstance().getDetachedReaders();

for (ReaderModuleDescription d : descriptions)
{
Reader r = ReaderManager.getInstance().attachReader(true, d);
SmartCardExtension ext = new SmartCardExtensionImpl(r);
SmartCardCryptoFactory fac = new SmartCardCryptoFactoryImpl(r);
SmartCardAuthProvider provider = new SmartCardAuthProvider(null, r, ext, fac);
Security.addProvider(provider);
}

...

Loading our JCE on Android

Since there is no static way for installing SmartCardAuthProviders to the whole i.e. that all applications can use the providers Android system usually a developer would need to link our library to his application binary. When we e.g. release a new bugfixed version of our library it can be a quite annoying task to build up the own application again just for re-linking the third party library. Due to this reasons and the Java sandbox limitations we developed an own loader concept allowing to install our cgJCE once per device and then use it from all applications. Indeed it is necessary to link another jar library but this one is likely not intended for changing a lot and just a very small fraction regarding the filesize compared with our complete cgJCE library. This light weighted library is called the "loader".
The loader is responsible for loading the pre-installed cgJCE into the context of the appropriate application and automatically if wished runs the necessary initialization procedures. Afterwards the SmartCardAuthProvider can be easily used as Java standard AuthProvider.
Furthermore the loader brings some wrapper classes. Since loading our cgJCE with the loader disables the use of our JCE SDK classes due to class loader issues instances of SmartCardAuthProvider can not be casted to the JCE SDK classes or interfaces we have written wrapper classes using reflection calls to nearly simulate our JCE SDK.

The SmartCardAuthProviderWrapper itself is no provider class but offers nearly the same functions as the SmartCardAuthProvider. For retreiving the provider – for e.g. direct getInstance calls as shown in 1.3 – getProvider has to be called.
SmartCardAuthProviders would usually offer to register observers. This is not available for the SmartCardAuthProviderWrapper but there is a replacement instead. The wrapper offers to register a SmartCardAuthProviderEventCallbackHandler which also forwards SmartCardEvents and can be registered or unregistered via registerSmartCardEventHandler and unregisterSmartCardEventHandler. As SmartCardExtension it returns a SmartCardExtensionWrapper via getSmartCardExtension.
The SmartCardExtensionWrapper has almost the same functionality as the SmartCardExtension but has some minor deviations. Instead of a parameterized getRemainingAttempts function there are getRemainingAttemptsUser and getRemainingAttemptsAdmin instead. The same concept applies to the verifyPIN and changePIN functions.
When using the loader the JCE is initialized with the following steps:

1. Implement the LoaderCallback
   The LoaderCallback-interface contains a function which is called when the loader has finished its job in order to signal that the providers are ready to use.
   
   
2. Call ProviderLoader.load function
   This function starts our cgJCE providers being loaded asynchronously.
   
   
3. Wait until LoaderCallback is called before using the cgJCE providers.
   When the LoaderCallback receives the final onLoaded call our cgJCE providers were loaded and are now ready to use.
   
   

For easier integration we also implemented an AsyncTask called the InitJCETask. It offers to initialize the whole cgJCE with just one line of code by calling
new InitJCETask(applicationContext, null, true).execute();.

The above line of code does not supply a OnTaskFinishedCallback (null) whereas it would return the opertions result. For more information see the loader whitepaper. We recommend to always use the LoaderCallback or the OnTaskFinishedCallback since they signal that the loading process has finished.
When the loading-job is finished the providers are registered to the system and can be used as usual.