The method is needed since makeReadOnly() only works on T1T/T2T. Also removed
makeLowlevelReadonly(), since NFC forum does not allow setting the CC and the lock
bits separately.
Change-Id: I8e6d7c065b1f017ef07d878c41df05e1a8193f5a
attemptDeadServiceRecovery() is a hack to recover from NfcService dying. It
should be a rare event, and is only needed in NfcAdapter which is a long-lived
object.
TagTechnology objects are transient, it is acceptable for them to go stale
when NFC service dies. Lets not complicate the code with recovery for a rare
event.
Change-Id: I101350e920b075c680eb4f250683f0a2bb878553
BasicTagTechnology.transceive(byte[] raw) should work for most child classes,
except those that want to disable (raw) transceive.
Current plan is not to add transceiveMifare() etc - use explicit methods
instead.
Add package scoped BasicTagTechnology.transceive(byte[] rata, boolean raw)
as a helper to remove code duplication.
Change-Id: Iaea161022751c99058d291e2ed0f8c475d1c7282
It's not easy to determine if this
is possible, so instead apps should
attempt a format and handle errors
in the format request.
Change-Id: I078a208b849e71ef3fb6b5970a9111ece4a2d201
- It's useful to have accessors at block level, so apps don't really have to know
about the sector structure (and how many blocks there are in a sector).
- There's no way to tell whether a read/write/ didn't work because of auth
failure. The documentation should be changed to make this point clear.
- Added increment/decrement commands, for atomic increment/decrement of value blocks.
Change-Id: I590feacbcd1443f1be7a86ab046a5b1f33e2e04c
- The NfcService now allows for connecting to a specific technology;
- The "active" parts of technology classes may not be used at the same time.
Change-Id: Ibb569f51cc6da4f3e24df9d0850c6f49a022b0c2
- Added getNdefCached() to return the message read at discovery time.
- Fixed format() to check ndef before doing the write:
libnfc actually requires a checkNdef to be done before writing.
Change-Id: I9b3108299c05539bdef92dd74f62f911fb5a16bf
This gives NFC service a handle to the application context.
Deprecate NfcAdapter.getDefaultAdapter(), it does not provide a context.
Using this method will print a warning, and will later throw an exception
if a method that requires a context is called. No 2.3 API's will fail, but
new API's that do require a context might fail.
Also add helper NfcAdapter.getDefaultAdapter(Context).
Change-Id: I9a6378de4ef4b61ad922f8d53e64e2a1a1d5d60c
Also added an extra to carry the ndef message, so we can have it in multiple
Ndef instances without doing an active read.
Change-Id: I2ecabc24732990c5c9979ee3a001a7fb13da21d9
- GetTechnology() used a binary search, but the array was linked to another
array (extras) which was not sorted. So made it linear.
- The tag technologies were instantiated with a null NfcAdapter.
Change-Id: Iae15169a89155c3a5c9f81824f809d6010ebac01
The implementation was guarenteed to cause deadlock when a timeout was set.
Change-Id: I59444ea784eb9057c6c4c9e9123f558b3ef5eef6
Signed-off-by: Nick Pelly <npelly@google.com>
We are leaving enough API so that you can see when any Tag is discovered,
get its ID, and get its NDEF messages.
But for advanced use - creating tag connections and writing messages - we have
2 problems. Firstly a lot of the code is untested
(RawTagConnection.transceive()), or in some cases known not to work
(NdefTagConnection.write()). Secondly, there is still debate about how to
best expose information about Tags.
The set of data/methods exposed for a Tag changes completely depending on the
tag technology. There may be multiple sets of technology implemented in a
single tag. Tag A may have technology X and Y, Tag B may have technology Y
and Z. Furthermore, some NFC controllers will be not be able to use all
technologies, and so Android Device 1 may see technology X and Y on Tag A but
Android device 2 may only see technology X. So we have a pretty challenging
set of constraints to work under, and we are not convinced the current Tag and
NdefTag class is the best approach going forwards.
The Tag application should be able to remain unbundled, since it just needs to
get incoming NDEF Messages.
Change-Id: Ic09f094f33794e10f8d730fffe011c9a5957e0ac
Signed-off-by: Nick Pelly <npelly@google.com>
Retrieve the service again from ServiceManager on RemoteException.
Change-Id: Ie227b52019e7deafeab712af1addd6d957f7a8ee
Signed-off-by: Nick Pelly <npelly@google.com>
