Application Authenticity Protection in Native Android applicationsimprove this page | report issue
This is a continuation of the Application Authenticity Protection tutorial.
Adding required files
From the MobileFirst project's Native API folder, copy the following folders to your native's project
The application-descriptor.xml file
application-descriptor.xml file of your application by adding a security test and a public signing key.
Adding the security test
securityTest attribute to the Android environment element. For example:
Adding the public signing key
- Extract the public signing key of the certificate that is used to sign application bundle (
- If the application is built for distribution (production), extract the public key from the certificate that is used to sign the production-ready application.
- If the application is built in the development environment, you can use the default public key that is supplied by the Android SDK. You can find the development certificate in a keystore that is in a
You can extract the public signing key either manually or by using the wizard that MobileFirst Studio provides.
For more information about how to sign your Android application look here.
Extracting the public signing key by using the wizard (Eclipse)
- Right-click the Android NativeAPI folder and select Extract public signing key.
- Specify the location and the password of a keystore file and click Load Keystore. The default password for
- Set the Key alias and click Next.
- Click Finish to automatically paste the public signing key to the relevant section of the
A dialog displays the public key.
If you decide to change the value, make sure that you change it in both locations.
You can also edit the
application-descriptor.xml file directly to add the package name:
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on November 09, 2016