Get some flexibility in the tag type detection #17
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently an internal table helps guessing the type of tag based on its SAK & ATS.
But now phones start being able to emulate tags (CyanogenMod, Kitkat,...) while SAK & ATS are still not under control, so being different than expected.
How to get more flexibility?
Getting an environment variable to bypass entirely detection and assume that we've a tag of the right type requested by the application?
Or instead of guessing the tag from its SAK/ATS, test proactively if the tag is of a specific type?
E.g. ASSERT_MIFARE_DESFIRE(tag) would not check a preset flag but would test actively if the card is a DESFIRE by sending a GetInfo command.
Original issue reported on code.google.com by
[email protected]
on 3 Dec 2013 at 3:23