I have been looking at this blog https://nelenkov.blogspot.com/2012/08/accessing-embedded-secure-element-in.html, this is really good however I am having trouble understanding how to add the com.android.nfc_extras to my project. Also, the way the etc/nfc_access.xml file works.
If there is anyone that will help me break through this process then it will be nice, since I am new to this.
It really depends.
The most basic answer is: disregard the article (it's 6 years old, Android changed a lot!) and try to use GlobalPlatform Open Mobile API. It is API for accessing secure elements present on many phones.
Expanded answer: it varies between manufacturers. Some will allow you to access their embedded secure element (eSE) via OMAPI, sometimes you might need to use propietary service as a proxy. One example of vendor-specific service is Samsung KMS Agent (still, eSE is visible in OMAPI).
After that introduction, if you want to access eSE and you are new to this, you probably want to use OMAPI. If you are writing app targeting Android P - great news, OMAPI is now part of Android.
But in reality you would probably target older Android version, so bad news is - you don't know if OMAPI is present on the phone. See: List of OMAPI supported devices
But assuming you have OMAPI present, then take a look at Android documentation for OMAPI: https://developer.android.com/reference/android/se/omapi/package-summary and GlobalPlatform.org documentation e.g. OMAPI docs
Related
I know this is way too general, but I have a reason. I am looking forward to make a simple app that can transfer strings from my mobile device to my TV. I wish to transfer this data over Wi-Fi, provided that the TV and my phone are on the same network. Now, the Android Documentation for the P2P Wireless APIs is DEAD. It even uses some deprecated implementations, and to worsen that up, nobody cared to provide an up to date documentation for carrying it out in modern day programming.
All I want, is a reference to a reliable source that might be helpful in understanding this. I added the compose tag, again, so that the info is conveyed that the app is built using a declarative paradigm, unlike the traditional android system. The sources may still be using the old android system (I, however, would prefer a Compose app). If nothing, at least point me to the correct (and updated) documentation, if it at all exists.
I'm developing an Android application that communicates with my device(ARM based device with bluetooth module) via bluetooth using TLS(TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256).
What I considered:
javax.net.ssl from Android. Problem is that ephemeral(ECDHE) encryption keys are starting from API 20 but I need API 11. I didn't find a way to add suite. It seems that this library is strongly related to android version. API versions and overview
Bouncycastle(spongycastle) I didn't find a way to use it without creating a socket. I need something like in/out streams so I could use it not with the network connection. Also I didn't find TLS/SSL at all.
Implementing everything by myself. I could take all algorithms from selected suite and implement protocol by myself but I don't know what I don't know and I'm afraid to screw up security. I don't know if it's a good practice to do such a thing(may be it's high level enough so it's not very dangerous to implement it by myself)
My question is: which libraries could you recommend for TLS? Is it a good way to implement the protocol(not algorithms) by myself?
The Desired Functionality:
User A is running your app on an Android or iOS device. User A can automatically find and communicate with other nearby (< 20 meters?) users B and C (Cross-Platform), whether they're running Android or iOS, and without any of the users having an internet connection (Offline).
I believe this is a commonly desired functionality, and having a definitive answer to this question would be a great boon to the mobile development community.
Further requirements/things you'd like to have, in order of importance:
Single Codebase (or at least sharing 90+% of code) for Android and iOS, e.g. through Xamarin or something similar.
Automatically choose the best (perhaps going down a list of preference) signal to use, e.g. choosing WiFi direct or bluetooth (similar to AllJoyn, Multipeer)
Use only Free (or free for certain classes of user) libraries
The Question:
How to achieve the desired functionality?
Sub-question 1
Is it even possible?
Answer: YES. Apps like Firechat and Spaceteam do it, therefore it must be possible.
Rejected Possibilities:
Multipeer: iOS only, doesn't achieve Cross-Platform.
Alljoyn: iOS bindings are Objective-C only, doesn't achieve Single Codebase.
Mono.Zeroconf: Supposedly would require separate platform implementations, so don't achieve Single Codebase?
Open Garden SDK: Would be a great solution, except it doesn't actually exist yet.
I've been researching this topic for several days now, and I haven't been able to find a definitive answer. Part of it is probably that people use so many different terms like mesh networking, ad-hoc networking, zeroconf, DNS-SD, etc., which makes it difficult to search.
If you're interested in some of the research I did on stackoverflow and elsewhere, here are some notes and links (I'm limited in the number of links I put directly in this post).
Not sure if this is what you are looking for but I would highly recommend Xamarin with the library ZeroConf which is native and has Xamarin support.
https://github.com/onovotny/Zeroconf
It works great and that gets you close to your unified codebase with a native and uniform way of discovering other ZeroConf devices.
Edit: It looks like the ZeroConf library only supports subscribing to ZeroConf services and not publishing also and I think you will need publishing as well. But it seems other users have requested it so it seems like a feature they will be adding.
I'm planning to implement a simple VOIP feature, using the new android.net.sip in Android 2.3, as an extra feature of an existing Android application. Earlier, i.e. before 2.3, I tried to do a naive solution but I could not connect the other mobile phone because of the carrier network operator's firewalls!
So, I wonder, how does this new SIP package in Gingerbread bypass those firewalls, allowing mobile phones to connect directly to each other? Or will there be problems anyway? (I scanned Googles Android documentation but could not find any information on this topic.)
Thanks in advance!
/Steve
You're making an unwarranted assumption that there's a (hidden) mechanism for bypassing/traversing firewalls. Maybe there is, but quite possibly there isn't. The overall SIP documentation looks thin; this feature may well not be ready for general use, or you may well need to implement such things outside of it (STUN, TURN, UPnP, etc).
What are the key differences between Android, iOS and Blackberry OS in terms of level of accessibility by application developers (i.e. access to the video input, sound input, phone functionalities, to which extent, etc.)?
PS: Assume latest version of each OS.
EDIT: Can someone turn this into a wiki so we can compile answers from people that don"t necessarily have experience in all 3 plaforms.
I'm not familiar with BlackBerry, but on Android and iOS you can access just about anything. Until recently iOS had some restrictions about camera access (see this), but I belive those have been solved. Because Android is open-source, you can theoretically go as deep as you want as far as accessing the hardware, but you may or may not be able to get any deeper through the standard Android API than you can through the iOS API.
On Android, you can do a lot more to override default functionality. For example, you can create your own launcher screen or phone application. The iOS approval process wouldn't allow these kinds of applications.
API hardware access really isn't an issue on either platform, the bigger concern is overriding default software (almost never possible in iOS) and what types of applications iOS allows.
Each platform has its own nice and bad parts. I have been working on both Android and BB. I wish I could take only nice parts from both to create a platform of a dev dream! :)
For instance, I could take these features from BB:
The greates feature I like in BB is the simplicity of the application architecture - you can always count on your main UIApplication instance - OS never kills it.
Also I do like the simplicity the Dialog class provides - it is very easy to implement business logic related to user choice - while Dialog screen is shown the code execution just stops and waits for user input.
From Android I'd take the following:
Network communication. On BB this is a real nightmare (BES, BIS, WIFI, Direct TCP without APN, Direct TCP with APN, WAP, WAP2, Unite - who's next? :)).
For file manipulations you just use a native/usual Java API.
Nice looking UI components are available right out of the box.
I should add I'm not happy with GPS related stuff on both platforms, however maybe it is due to GPS hardware limitations rather than API creators.
Thanks!
BlackBerry is a pain, once I made a project for it (the JDE version was 4.7 back then) and it didn't had an ArrayList. WTF?