[Q] NFC Tag Launcher "Open in Browser" prompt - Galaxy S III Q&A, (US Carriers)

Whenever I scan an NFC tag I created with NFC Tag Launcher it brings up a prompt that says "Open in browser" with options for OK and Cancel. However, it does not do that for tags I create in Lightflow for turning sleep on or off. Is there any way to disable this prompt?

---

Can't offer any help but I'm having the same problem with NFC Task Launcher.

---

I too get this. Not sure why. I'm on a rooted Verizon S3.

---

Download an app for NFC from the market first, then overwrite the default command that was stored on it. Most likely the command was to redirect you the site of the brand or seller of the tag.

---

nunyabiziz said:
Download an app for NFC from the market first, then overwrite the default command that was stored on it. Most likely the command was to redirect you the site of the brand or seller of the tag.
Click to expand...
Click to collapse
These are blank tags that I wrote to myself. I click OK every time and it never opens anything in the browser.

---

Have you verified that it was blank or have you erased the tag yet? I had the same issue with blanks that were not completely blanks.

---

nunyabiziz said:
Have you verified that it was blank or have you erased the tag yet? I had the same issue with blanks that were not completely blanks.
Click to expand...
Click to collapse
How can I tell if it's blank? According to NFC Tagwriter by NXP it's blank, and according to NFC TagInfo, the first two pages are read-only factory locked..

---

What do you have using NFC taginfo under "NDEF"?

---

nunyabiziz said:
What do you have using NFC taginfo under "NDEF"?
Click to expand...
Click to collapse
The blank tags have no message. One that I've written with NFC Tag Launcher has a message of the following:
Code:
WELL-KNOWN: urn:nfc:wkt:U(URI)
Identifier: 0x03("http://")
"tags.to/ntl"
MIME: ntl
enU:2:M:0,Q:-1;O:7;E:h:1__3:M:2;S:2;E:h:0
One written by lightflow has the following:
Code:
MIME: application/vnd.lightflow
SleepToggle
I would imagine the first part is what's causing it, but I don't know what there is to do about it.
EDIT: looks like that URL goes to the play store page for NFC Tag Launcher. Not sure why it's not actually opening in the browser though.

---

I personally use "NFC task launcher" and "erase tag" option.
---------- Post added at 09:28 PM ---------- Previous post was at 09:25 PM ----------
Sounds like you got it figured out.

---

nunyabiziz said:
I personally use "NFC task launcher" and "erase tag" option.
Click to expand...
Click to collapse
The issue is that I'm pretty sure it's NFC Tag Launcher that's writing the URL to it when it writes the task to the tag. I don't know what I'd do to write the tasks out to the tag otherwise.

---

I use NFC Task Launcher's erase function as well. As soon as the tag is written to again, this issue occurs.

---

jh120 said:
I use NFC Task Launcher's erase function as well. As soon as the tag is written to again, this issue occurs.
Click to expand...
Click to collapse
And did you write a task to the tag after? The NFC tag will always be detect, even blanks. It will just try to launch a unknown command.

---

nunyabiziz said:
And did you write a task to the tag after? The NFC tag will always be detect, even blanks. It will just try to launch a unknown command.
Click to expand...
Click to collapse
The issue is that the act of writing the task with NFC Task Launcher writes the URI to the tag. So erasing then rewriting the task accomplishes nothing.

---

I dont know all tags are the same size so maybe my tags are different. Im using web evolved tags and by default until erased and written to the tags will launch my browser and redirect to their site.

---

nunyabiziz said:
I dont know all tags are the same size so maybe my tags are different. Im using web evolved tags and by default until erased and written to the tags will launch my browser and redirect to their site.
Click to expand...
Click to collapse
Yeah, this isn't caused by anything with the tags themselves, it's just that NFC Tag Launcher adds the URI to the tag when you write out a task no matter what.

---

I can confirm that this happens regardless of tag type. I erased an old NFC-capable train ticket and wrote a wi-fi toggle to it. It works, but the browser dialog box still pops up.

---

Yeah, it's NFCTL writing that URL to the tag.
That URL is used as the intent filter and serves a few purposes. 1.) it saves space over a longer custom mime type or application specific record (which stores the package name). 2.) it directs anyone who doesn't have to the app to the play store to get it so that the tag actually does something - an application specific record does the same thing but has to store the *entire* package name (28 bytes in this case).
The way this has worked on *every* other device (and the way it should work in Android) is that the entire NDEF message hits the intent filter for that URL and the message is then delivered to the app. The app then grabs all records from the message (there are two) and parses the second record and executes those actions.
Given what the OP has sent me for some reason the Verizon S3 isn't doing this. (The international and ATT version work as expected).
Given that it's showing the chooser it's missing the specific intent filter and showing a dialog for what to do with this URL:
Code:
D/NfcService( 909): TAG: Tech [android.nfc.tech.MifareUltralight,
android.nfc.tech.NfcA, android.nfc.tech.Ndef]
D/NfcService( 909): Attempting to dispatch tag with override
D/NfcService( 909): No activities for NDEF handling of Intent {
act=android.nfc.action.NDEF_DISCOVERED dat=http://tags.to/ntl (has
extras) }
However it's still delivering the payload to NFCTL as the actions get executed (which it shouldn't do if you're getting the browser chooser dialog). It shouldn't work this way, literally. If you get the chooser it should deliver the entire payload to the chosen app (it's not).
So, what can we do here? I can add an option to use an application specific record in place of the URL. This should ensure it doesn't happen but at the cost of space - you'll lose 15+ bytes of space on the tag as a result though as it will write a separate NDEF record to the tag containing the full package name.
Is there anyone with a Verizon device this *isn't* happening for?
I could in theory get this into a release tomorrow as I'd want to have this squashed pre release.

---

I've been playing around quite abit with this and I have "sort of" gotten around this by use the Tasker URL Launcher.
With TUL installed along with tasker, I can use another NFC writer utility to create the url of tasker://taskname
Now if I touch the new tag without NFCTL installed I will be prompted with the "New Collected Tag" screen....unfortunately its still not an autorun but I can tap the "new tag" and the sequence fires correctly.
Obviously as previously stated the problem is the interception by the phone of the URL string used by NFCTL. Personally I have rooted and ripped out most all the Verizon bloat so I'm unsure what is left to cause this interception.
Let me know and I'll test whatever.

---

konman2k4 said:
I've been playing around quite abit with this and I have "sort of" gotten around this by use the Tasker URL Launcher.
With TUL installed along with tasker, I can use another NFC writer utility to create the url of tasker://taskname
Now if I touch the new tag without NFCTL installed I will be prompted with the "New Collected Tag" screen....unfortunately its still not an autorun but I can tap the "new tag" and the sequence fires correctly.
Obviously as previously stated the problem is the interception by the phone of the URL string used by NFCTL. Personally I have rooted and ripped out most all the Verizon bloat so I'm unsure what is left to cause this interception.
Let me know and I'll test whatever.
Click to expand...
Click to collapse
I may add a quick option tomorrow morning and throw a test APK up here. If the Verizon release is anything like the International and US pre-orders I suspect we'll see a lot of downloads and this is a *really* annoying thing to happen. So far Samsung takes the crown from HTC's head as the OEM making the weirdest changes.