I'd like to make a very minor patch to a file of the Android Core but even though I'm pretty well-versed with writing Android applications, I'm quite lost with how to go about this.
The line of the file I'm trying to patch is here: https://github.com/android/platform_frameworks_base/blob/master/core/java/android/provider/CallLog.java#L357
I'd like modify the code so that it is never invoked. (Just imagine it being commented out.)
How should I go about this? Is it possible to create a patch for this? My last resort would be to use the Xposed Framework.
You cannot alter internal parts of the framework simply by installing an apk or something.
You will require root at a minimum, and even then I doubt you can make this kind of change.
The only way I can think of to do this would be to change the line in Android's source, build a ROM image and flash that onto your device, like you would with Cyanogen and other custom flavors of Android.
The only method for accomplishing this in clean way seems to be using the Xposed Framework:
http://forum.xda-developers.com/showthread.php?t=1574401
Related
First of all I'm a newbie in VoIP implementation. I need to implement VoIP single and group call in android application. Could you tell me, what is actually the best way to achieve this ? I'm looking for Android SIP library (probably open source) which should:
has good documentation with simple app examples
be ready to use with java
Maybe just native android SIP api will be the best ? But I heard that it doesn't support group calls.
Most of the voip libraries use C/C++ implementation for various reasons. You can use PJSip which is a C voip/sip stack. It has a good documentation but you have to build it yourself using android ndk . It has good documentation and also contains processes to build it for Android and other platforms. But there is no java/android wrapping built in so you should do that yourself. Another option is Liblinphone which is also based on C stack but provides all of the wrapping and implementations out of the box so you don't have to bother so much on native codes. It also has a sample application which you can try yourself. One downside of Liblinphone is that it lacks proper documentation and you have to dig in more.
Regarding the android SIP api, I don't think it is a good option as it has much more limitation and hardly maintained. It is based on Jainsip stack which is a 100% java stack but is too verbose. I personally would like to recomment Liblinphone as I am currently implementing it and am pretty satisfied with it. Best of luck...
Update
Here is the source code of linphone for android if you are interested in it. You can get pretty much idea of Liblinphone for android from it. You have to dig much more into the sources though.
You can have a look at Restcomm Android SDK:
It's open source, with an active community around it
It using SIP for signaling and Webrtc for media so should work nicely with NATs, etc
Comes with 2 sample applications that you can play with and alter their code to experiment
Comes with quick start guide, reference doc
You can check the Olympus sample App right away by installing the .apk from this link
Notice that the SDK doesn't support group calling out of the box, but you could combine it with Restcomm-Connect open source platform to add such functionality very easily. Restcomm-Connect also comes with docker, so you should be able to install it right away.
Please let me know if you have any questions
Best regards,
Antonis
I'm using an external library to create a customized live streaming app.
Here is the library I'm using:
https://github.com/cine-io/cineio-broadcast-android/tree/master/cineio-broadcast-android-sdk
One of the (few) issues I have with this library is that it forces the phone to use the FRONT camera if there is one. I'd rather force to use the back camera (or have a choice, whatever).
As it is, the class that manages broadcasting in this library does have built-in public methods to choose the camera upon initialization, and its methods are private, so I can't extend it.
My solution has been to download the library locally, compile it as a local project in Gradle (I'm usnig Android Studio). Then I directly amend the library files in my project. It works.
However I'm worried this isn't a very good practice. One issue I can foresee is that the library will get upgraded - and since I'll have made changes locally it'll be very hard to take advantage of new versions of the library.
QUESTION: Is there a best practice when it comes to modifying external libraries? Is it what I am doing, or is there a better way?
Please feel free to provide feedback on the question so I can improve or clarify it as needed.
I would fork the library and push your commits to your fork. Like this you can later on merge changes in the original library to your fork as well.
GitHub has a great collaboration model, that allows you to fork any OSS project easily. You can modify it at will, optionally, push the changes back in a form of pull requests.
Once you have your code ready to build, you can use a full free continuous integration/distribution toolchain, that is built from a cloud-based CI server of your choice (Codeship, Drone.io, Travis-CI to name a few), a free instance of Artifactory for your SNAPSHOTs (intermediate build results) and Bintray as a distribution platform (built-in into Android Studio for other people reuse).
Here's a video demonstration of the full stack and here's the documentation of the Artifactory/Bintray part.
You can use reflection (https://stackoverflow.com/a/11484158) but it isn't a good way.
I think in your case it will be better to compile module from source and not to update it.
i am using Codename.one for mobile apps development, once the build is submitted, they provide the "apk" file. Since there are some limitation in codename one, so i was wondering that is there a way to get the native code for android build. ??
You can get the sources using the include source feature (available for the basic 9 USD subscription) but you would be mistaken to use it for the case described.
You can extend Codename One in any way you want including with native code, there are quite a few cn1lib's most of which are open source which demonstrate rather easily how you can write native code in Codename One.
This is a superior approach since it keeps the portability of Codename One and easy development cycle while allowing you to do almost anything you need.
Notice you can look at the full source code of Codename One itself in its open source project page.
I am currently attempting to port an android app to desktop. I realize that the majority of the android based code cannot be reused, but what about "smaller parts" which dont depend on the android architecture?
I am mostly talking about support or math related classes like SparseArray, Matrix and so on.
Those may work. But you will have a rough time figuring out what works and what doesn't. Even once you do that you will need to create a whitelist somewhere like in your IDE that doesn't auto-complete classes you don't want or can't use and you will also want to fail your build. Maybe you should create a jar containing only the classes you want to use that you determine are usable.
I don't really have or want to use the Java Media Framework (JMF) on Android but I am looking for detailed information about why it's not possible to use it. (I know that it's considered as outdated anyway and I am aware that there may be better ways to achieve certain things in Android using this for example: http://developer.android.com/guide/topics/media/index.html)
Nevertheless I need more information regarding JMF on Android but all I could find is, that "JMF isn't working on Android" - but I wonder why.
So I have two questions:
Do you know any kind of "official" statement, for example from Google or Oracle, saying that JMF isn't supported on Android? I wasn't able to find something like that.
Why is JMF supposed to be not working on Android? I am interested in the technical details and would be grateful for all kind of references.
Thank you!
EDIT:
To be a bit more specific and clarify my approach: I built a tiny test-app and tried to play an audiofile the same way as I have done in a standard java desktop application (which was working as expected). I included the JMF.jar (for now without any modification) compiled, deployed and started the app - no problems so far. The (first) exception (javax.media.NoPlayerException) is thrown when calling Manager.createPlayer().
That was actually the point where I stopped and wondered if it's worth digging deeper, although the result is kind of predictable. I decided to ask about the technical background first, instead of figuring it out the hard way in hours of testing and debugging (the reason is not a lack of interest but unfortunately a matter of time at the moment).
I am looking for detailed information about why it's not possible to use it
Because it was not included in the Android SDK. Lots of things from Java SE were not included in Android.
Do you know any kind of "official" statement, for example from Google or Oracle, saying that JMF isn't supported on Android?
I am not aware of such a statement. They also have not released a statement indicating why Android does not integrate with the Hubble Space Telescope, why it does not include shoe-shining APIs, etc. There are an infinite number of things that are not in Android; it would be impossible to list them all.
More generally, Google faces pressure to keep a lid on firmware size, as the bigger the firmware, the more expensive things get (required storage, OTA update costs, etc.). Hence, they only include a subset of the Java SE SDK as one way of helping reduce firmware bloat.
Why is JMF supposed to be not working on Android?
Because it was not included in the Android SDK. I have no idea if it is possible, let alone practical, to create a fork of JMF that offers a JMF-like API but uses Android media capabilities under the covers.