Develop Reference

How to check for DolbyDigtal (AC3) support on device?

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.

AltBeacon setBluetoothAddress and setBluetoothName

I'm attempting to transmit as a beacon an Android phone using the altbeacon library as described here. I am trying to set some parameters using the following methods:
setServiceUuid(0xfeaa)
setBluetoothAddress("31:14:15:92:65:35")
setBluetoothName("MyBeacon")
When the beacon is interpreted on another Android device in the RangeNotifier listener method, didRangeBeaconsInRegion, the beacon doesn't have these parameters set. (eg. getServiceUuid is -1 and the BT address and name are each null).
I'm using the following beacon layout in the parser for the transmitting application and in the scanning application:
m:2-3=beac,i:4-19,i:20-21,i:22-23,p:24-24,d:25-25
I don't know what this means though; I wonder if I need to change it.
Anyone have an idea how to make the bluetooth address, name etc. be accessible in the beacon that is scanned on the receiving device?

Some fields in the Beacon class are only used when detecting beacons and do not affect transmissions. You have found three of these exact fields. Here is an explanation of each and why they work this way:
BluetoothAddress: this is a fixed six byte unique address built into the Bluetooth chip on your phone. When sending packets (beacon advertisements or otherwise), the chip always uses the same address. You cannot change it. This is by just the way Bluetooth works.
BluetoothName: this is the friendly name of your phone visible to other Bluetooth scanners. Changing this name affects not just beacon transmissions but all Bluetooth operations on the phone. For this reason, the library's BeaconTransmitter does not change this name. You can do so youself, however, by calling the setName method on Android's BluetoothAdapter class. See here.
ServiceUUID: This field applies only to certain beacon formats such as Eddystone, which are based on 16-bit GATT Service UUIDs. For other beacon formats (AltBeacon, iBeacon), this value is -1 as you have seen. The ServiceUUID is actually defined in the BeaconParser layout expression. In the Beacon class you can read it, but writing to it has no effect. You generally do not need to worry about this field, and certainly not for the AltBeacon layout shown in the question, because it is not used for that format.

Android Device Name Without Bluetooth [duplicate]

This question already has an answer here:
Android : Get "device name" on android tv
(1 answer)
Closed 4 years ago.
I wanna get android device name (i.e. the "name" that user can change through settings and that you can find under "Settings > About device > Device name").
Other developers recommend to get this name through bluetooth.
But on my device (Samsung Galaxy S4) this name is only updated when I enable bluetooth, so if I change the name when bluetooth is disabled : the new name won't be displayed until I enable bluetooth.
I'm wondering if there is a way to get the updated device name without enabling bluetooth?
I can think of a workaround like :
enabling bluetooth
get name
disable bluetooth
but I was wondering if a more elegant solution exists.

The device name you are talking about is also known as the bluetooth friendly name and therefore reading it through the bluetooth API is perfectly valid.
Be aware that if your app is running on a non-bluetooth device : this name don't exists.
If you read carefully the doc of the bluetooth API you will see for the setName(...) method:
... If Bluetooth state is not STATE_ON, this API will return false. After turning on Bluetooth, wait for ACTION_STATE_CHANGED with STATE_ON to get the updated value.
In other words: this behavior is not particular to your device, but it works as specified.
Your workaround is AFAIK the only way the get the updated name when name was changed while bluetooth was disabled (and unfortunately it has serious drawbacks : enabling/disabling BT is costly).
Please also note that you must wait for ACTION_STATE_CHANGED with STATE_ON to get the updated value.

KitKat: How to route APDUs to the SIM

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.

Setting Priority for wifi configuration in android

I have to set a priority for wifi configuration sothat I have to always connect to specified wifi network so that device ignores other available wifi in the region.
configuration.priority = 100000;
It is connecting to the last known connected wifi network and ignoring specified wifi network.

If you are trying to set priority for a particular Wifi Configuration, you must use
config.priority = value;
WifiManager.updateNetwork(config);
and you should use the below api after updating
WifiManager.saveConfiguration();
I was able to set priority for my configured network.
Note:
By default the android system will provide highest priority for the last known connected wifi network. If you want to set a higher priority for any other configuration, set the value with respect to the highest value set by the android system rather going for some numerical digit.
Default priority value is in relative with the highest value and its also based on its usage preference. User set value will be changed if the network is manually selected.

If I remember correctly, changes to pre-configured networks should be saved to make an effect.
addOrUpdateNetworkNative(WifiConfiguration config);

I know this is probably a bit late, but I've been looking at the same thing, and apparently 99 999 is the highest value you can set, anything higher than that gets ignored From here