I have followed the CastHelloText-android example on github. When I use either the receiver they specified in the demo or the default receiver, the cast icon shows up in my application.
However, as soon as I change the app_id to be the one provided by the Google Cast SDK Developer Console for my registered application, the icon doesn't show.
I've tried rebooting my chromecast and my android device. All to no avail.
Any suggestions?
Make sure the serial number for the device that you have registered on the dev console is correct, it is sometimes hard to read the serial number (take a picture and zoom in). Also make sure the checkbox that sends the serial number is checked when you setup you chromecast. If cast icon doesn't show up for your own app-id but shows up for the other one, then there is an issue with your app/device registration.
I had the same issue as Kimble above. I started with the serial number on my Nvidia shield, which didn't work because that's not the serial number for the Chromecast. The proper serial number can be found in the settings menu under "Chromecast built-in".
I know I am late to the party, but here is a probably more up-to-date solution. Following this documentation solved my problem: https://developers.google.com/cast/docs/registration#find_device_serial_number
According to the documentation, for cast-enabled Android TVs, the serial number can be found in the following way:
Android TV (ATV) devices have multiple serial numbers associated with them. The software (Cast) serial number can be obtained either by casting the Cast Developer Console page to the ATV device as outlined above, or by putting the ATV device into developer mode and looking in the Cast settings for the software serial number.
To put your ATV device into developer mode, navigate to Settings > System > About > Android TV OS build, and click on the build several times until the device notifies you that you are in developer mode. To find the serial number once in developer mode, navigate either to Settings > Device Preferences > Chromecast built-in or Settings > System > Cast, depending on your ATV model, and you'll see the software serial number displayed.
Also, since just by looking at the screen there is no way to disambiguate zero and capital O, or small L and capital I, etc., you can simply cast the page in the link above to read out the serial number for you:
To find the serial number of any device, you can cast the Cast Developer Console page to the device:
Click the Cast button (as if you were casting this page).
The prompt displays Cast tab and lists the available devices.
From the drop-down menu, select the device for which you want to obtain the serial number.
For display devices, the serial number displays on the TV screen and is read aloud on the TV speakers (to help disambiguate 0's and O's).
For audio devices, the serial number is read aloud on the speaker being cast to.
Related
I'm trying to understand: is there a way to check if Android device supports DolbyDigital (AC3).
I found a broadcast action ACTION_HDMI_AUDIO_PLUG that indicates wether HDMI connected or not. Also it sends an array of all the supported encodings via the value EXTRA_ENCODINGS. But, as I understand, those are the values that the TV supports, not the Android device itself.
Is there any way to get activities done by user from Android device like active time, inactive time, cyclic distance, steps count etc. without using “Google fit” api like M9 chip does in iPhone devices.
Somehow i found to get device activity by help of "Google APIs for Android" .Here you cannot get the proper count but can get the device activation mode.Please see below link
[https://developers.google.com/android/reference/com/google/android/gms/location/DetectedActivity]
I want to route APDUs I get from an NFC Reader to the SIM Card. According to the HCE documentation I thought it would be possible simply by creating an OffHostApduService with the according routing-entries (which I did).
Sadly, the SIM does not seem to get any APDUs. SELECT-Commands that work when the SIM is directly attached to my workstation by a SIM-Reader return with 6a82 (File not found).
In LogCat I found two interesting bits of information:
Every time I shoot a select command which should be routed to the SIM, I get these entries:
01-14 10:44:18.501: D/BrcmNfcJni(1009): RoutingManager::stackCallback: event=0x17
01-14 10:44:18.501: D/BrcmNfcJni(1009): RoutingManager::stackCallback: NFA_CE_DATA_EVT; h=0x302; data len=12
01-14 10:44:18.501: D/HostEmulationManager(1009): notifyHostEmulationData
I think that this is a clue that the routing is not set correctly, since I think the Android OS should not be aware when the routing to the SIM is active, and a select or another command is sent to the SIM.
Every time I remove the phone from the NFC field of the reader, I receive the following error:
01-14 10:46:48.791: E/BrcmNfcNfa(1009): UICC[0x0] is not activated
I tried to track the cause of this error down and found the file external/libnfc-nci/src/nfa/ce/nfa_ce_act.chere which seems to belong to the Broadcom NFC Driver.
I think that the mistake is that the application cannot set the correct routing for the APDUs since the driver thinks that the SIM is not activated. In the moment I send the commands, the SIM is unlocked (PIN-Entry), but I doubt that this has anything to do with it since I don't have to unlock the SIM before using it in the card reader.
I use a Nexus 5 for testing. Does anybody have experience and / or a working example where the APDUs can be routed to the SIM instead of the CPU?
A quick check (analyzing the signals on the SWP pin of a UICC inserted into the device) revealed that the Nexus 5 is not activating the SIM as an NFC secure element (neither at boot nor when putting the phone on a smartcard reader).
However, I found two interesting files on the device's system partition:
/system/etc/libnfc-brcm-20791b05.conf and
/system/etc/libnfc-brcm.conf.
These two files seem to provide the configuration for the NFC controller (the first one a chip-sepecific configuration and the second one a chip-family specific one?).
After unlocking the bootloader, I was able to modify those files through adb by booting a clockworkmod recovery image, so I did some experimenting with the configuration parameters.
The result is that I managed to let the device activate the UICC (UICC was activated and registered its CE gates through SWP?), the device sometimes even notified the UICC about field status changes. However, with none of my modified configurations, I was able to get the reader to smoothly discover card emulation (this was working before, when only HCE was available on the device) nor to communicate with the UICC.
The interesting parameters in /system/etc/libnfc-brcm.conf seem to be:
NFA_MAX_EE_SUPPORTED: This is currently set to 0. I tried a value of 3, which seems to be the default.
ACTIVE_SE: This is currently set to 0 (no active SE). I tried to uncomment that line to let the device use the first SE detected.
NFA_HCI_STATIC_PIPE_ID_??: Should not be necessary but on out GS4 this is set to 0x71 for ?? = F3 and F4.
UICC_LISTEN_TECH_MASK: This is set to 0x00 on our GS4.
REGISTER_VIRTUAL_SE: I left this as it was (== commented out).
SCREEN_OFF_POWER_STATE: I did not experiment with this, but on our GS4 this is set to 3 (screen-off CE).
The interesting parameters in /system/etc/libnfc-brcm-20791b05.conf seem to be:
NFA_DM_START_UP_CFG: I've tried the commented-out parameters for UICC and I tried to use the configuration from our GS4. The value starts with a length byte and is structured in TLV format (one tag byte, one length byte, parameter data). The relevant tag for UICC activation seems to be C2, where the upper two bits in the second parameter byte disable the SWP interfaces of the NFC controller if set.
NFA_DM_PRE_DISCOVERY_CFG: The comments suggest that this need to be uncommented for UICC support.
It's been a while since I last played with card emulation on Android but AFAIK (I could be wrong), secure element access (internal or inside SIM) has not yet been opened to all developers (without some hacking). There are many non-technical issues regarding SE control which seem not yet solved (who keeps the biggest slice of the cake the Telcos or service providers?).
The news is that Google has taken a different approach with KitKat and its HCE, which basically consists on implementing a NFC card emulation mode without hardware secure element. IMHO this basically breaks the security required for the interesting card emulation mode applications: e-payment, ticketing, authentication, etc. Nexus 5 lacks such secure element and I doubt Google will pander to carriers by easing the access to secure element inside SIM, so I guess it still will not be possible to send APDUs to the SIM with stock firmware.
If you add the following to /etc/libnfc-brcm.conf
DEFAULT_ISODEP_ROUTE=0xF3
the UICC will receive APDUs
You also need all modifications above in libnfc-brcm.conf and libnfc-brcm-20791b05.conf
Up to Jelly Bean 4.3, normal way is to use nfc_extras and its method CardEmulationRoute (<route>, <nfcEe>) to route the UICC to the RF.
But on KITKAT, this brutal modification through DEFAULT_ISODEP_ROUTE is enough to have UICC Card Emulation enabled.
I'm testing Googl's 'Channel Changing Example' on my Sony Google TV.
I'm connected to a DVB (Digital Video Broadcasting) through the HDMI port.
When i'm running the example the number of retrieved channels is 0.
Just to be clear, I can see the TV channels using the 'Live TV' in the TV itself.
You need to make sure that your selected device has a channel lineup. Based on the fact that you're using DVB, I'm guessing you're not in the US, which means you aren't really using this in a supported country. However, you can fake it by going to Settings > Video input > Configured devices > (whatever your TV source is) > Edit channel lineup and then go through the prompts. This will download the list of channels for your connected set top box (again, this is probably not going to be your real lineup, but enough for you to test out the sample.
Background; I am in the process of writing an Android messaging application that needs to know the current user's phone number. This is then used to connect to other users using the application.
My application relies on looking up the user's number from Android's Settings -> About Phone -> Phone identity -> Phone number (this can at times be blank.. but that is a separate problem).
I am assuming that the above Phone number contains the user's full number. ie, my UK Android phone shows my number as: +447832xxxxxxxx, where 44 is the UK's international dialling code and 7832 is the operator.
Is it safe to assume that all Androids phones would include the international dialling code, which starts with +?
I would be indebted if any Android users could have a quick look at their Android settings and confirm whether Phone number is displayed as +international code+operator+number, i.e. US Android sets start with +1xxxxxx.
TelephonyManager.getLine1Number() is not guaranteed to be correct or even available to applications. I'd suggest a backup plan of using SECURE_ID to match to some user entered, possibly text-message verified phone number on a server somewhere. But even SECURE_ID is sometimes not a unique identifier (all DROID2 phones have the same ID), which would mean you should rely on an account system of some sort.
In my phone (Nexus One, Android 2.2, O2 UK) I don't have Settings -> About Phone -> Phone identity. In Settings -> Status -> My phone number is "Unknown". Not sure this helps you though, sorry.
On my moto droid with 2.2 I have: Settings->About Phone->Status->My phone number. FYI it is not prefixed with +international code