Closed joshuadunning closed 1 month ago
4.16.5 was exactly a fix for this:
I saw that changelog which was very odd as I swapped back and forth multiple times cleaning the android folders each time and only downgrading to 4.16.3 fixed it. I'll give it another test and update here again.
I will investigate today. I quickly released that fix in 4.16.5 before leaving for vacation in early July. Feedback from those who reported this was that the fix was successful.
I think I possibly see a problem. If those unused keys were poked into your AndroidManifest
using a previous version, then they won't automatically be removed.
<meta-data android:name="com.transistorsoft.locationmanager.hms.license" android:value="UNDEFINED"/>
<meta-data android:name="com.transistorsoft.locationmanager.poly.license" android:value="UNDEFINED"/>
I'm going to add some more logic to explicitly remove unused keys from AndroidManifest
where those keys are not provided in your app.json
.
Ok, I've released this fix to 4.17.1
and back-ported to 4.16.6
.
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.
Your Environment
react-native -v
): 0.74.5 (EXPO 51.0.31)Expected Behavior
After version bumping up from 4.16.3 to 4.16.5 or 4.17.0, I expected all license keys to still be validated properly. We DO NOT use the polygon addon, and therefore do not have a key defined; however we still receive the license validation error for the polygon plugin.
After digging into the AndroidManifest.xml I found
On version 4.16.3 and lower, the poly.license is not present and does not throw the error.
On version 4.16.5 and 4.17.0, the poly tag is added. I tried removing the meta-data tag for the poly license and the error was still present (I'm sure the license check is somewhere else in the packages).
Actual Behavior
Error pops up: License could not be validated for: com.transistorsoft.locationmanager.poly
Steps to Reproduce
For right now, I just downgraded us to 4.16.3 until we learn more.
We will stay on 4.16.3 for now. The new versions don't seem relevant to our use case.
Happy to provide more details as needed.