If an integrator overrides the session_expire string resource with a new string that not contains %1$d, it will cause an exception in runtime. To prevent this kind of problem we could separate the string into two parts and use the library name as a prefix before the actual string key to make unintentional string override harder.

To ensure each resource key has a library prefix you could define prefix in your build.gradle which warns if there is a resource not has a prefix.

Even though resource override seems a pain for library developers, it tremendously eases UI customization for library developers without additional effort after properly used styles. For example, the text color used in the library might not be compatible with the host app in terms of accessibility or text color, at this point, the library’s documentation should be clear about which style/color used for a specific UI element. After an integrator overrides the specific resource on the app’s resource folder, UI customization will be applied.

What about If the library not documented how to change a specific UI element? Even it seems daunting we could dig into the library's resource with help of Android Studio.

When you click the External Libraries section, your project’s external libraries will be listed then you need to find the related library that you would like to make some changes, but the tricky step is how to find the UI element from the resource files, I follow these steps;
* Pick a string from a screen
* Search that string text in the res/values/values.xml to find the key of the string
* Find a layout file under the res/layout folder using the string key

After you find the layout file you’re free to apply your changes easily following the resource override approach in your app’s res folder. But don’t forget in the next version of the library your changes might be invalid.

Some libraries heavily depend on hardware features such as camera, microphone, etc. due to that reason library developers tend to declare that features as required features in the manifest file.

But when a feature declared in the manifest file, Google play filters to prevent the application from being installed to devices that do not include the features or do not support the features specified in the manifest. So the library developer’s user-feature declaration impacts an application’s downloads even there is no guarantee the library will be used by each user of the application

Instead of uses-feature declaration, the required features should be checked at the runtime using PackageManager’s hasSystemFeature function to check whether the device supports the features or not