I would want to constantly check for new SMS from a background service (which suns even if application is stopped).
I wonder if Codename One supports background services as Android platform supports https://github.com/codepath/android_guides/wiki/Starting-Background-Services.
Codename One supports services using native interfaces on Android. Other platforms don't have anything quite like Android's services so this isn't something that can be generalized at that level.
iOS/Windows Phone do not allow intercepting SMS's and Android itself has made significant changes to incoming SMS logic which restrict this functionality significantly so either way this isn't something you should do. Generally the recommended way to handle incoming wakeup is to use push notification.
Related
I am new to Android and working on this chat app where I want to change an Activity element based on a predetermined data on predetermined exact times. It doesn't have to work when app or phone is closed but I want to send notifications as well with the change. There is AlarmManager, JobScheduler, Handler, Timer, WorkManager but I am extremely confused about how they compare to each other. Which is the best option in this case?
In fact, WorkManager under the hood uses all of these scheduling APIs depending on the API level. This means that you won't have to deal with finding the best API for devices, because WorkManager will pick up the appropriate API for you.
You can also read the official documentation for more info and comparison: https://developer.android.com/topic/libraries/architecture/workmanager
The WorkManager API is a suitable and recommended replacement for all
previous Android background scheduling APIs, including
FirebaseJobDispatcher, GcmNetworkManager, and Job Scheduler.
TL;DR: My app is hogging the user's microphone. Can I turn it off automatically whenever another app needs to use the mic?
I have an Android app that has some really cool microphone functionality, similar to Amazon Alexa, that stays on all the time in a background service. The problem is, my app hogs the users' microphone, making it unusable:
However, this is terrible application behavior on my behalf, and I want to do my best to avoid it. Is it possible to be notified when another application requests to use the microphone, so that I can automatically stop my service?
PS: I am using the Pocketsphinx library for continuous background voice recognition.
This is tricky, as I'm not a ware of any API for this. This surely will require system-level APIs to work like an "Ok Google" type of thing.
A viable option would be (from https://stackoverflow.com/a/43623308/603270) to run a Job at regular intervals, checking for foreground apps using android.permission.PACKAGE_USAGE_STATS.
This might suffice. But you could also add things regarding phone calls (how to detect phone call broadcast receiver in android) using android.intent.action.PHONE_STATE or media playback (via Receiver or maybe even MediaPlayer directly).
If you're really wanting to get this thing working, an alternative would be to get an array list of all installed apps on the system and which ones require permission to use the mic or not, then use an accessibility service to monitor the users screen if an app the user just opened requires the mic (which you'll know from the array you just grabbed). From there, disable the mic in your app if their app needs the mic. The background service can then check in intervals of, say, two minutes, to see if the app that required the mic is still open. This is really inefficient. But if you don't care, then this might be a good option.
There is no standard way to inform another app that you want access to the microphone (so that they release the resources and let you access it). You could however send a broadcast to all other apps ("requesting the microphone"), but the other apps would have to implement this feature (and very few or zero developers will do this).
I would recommend you to simply inform the user that the microphone is currently not available, because you can't do anything else.
In Java we can get the highlighted text from native window by using JNA or JNI. For example we could use
Monitor text that is highlighted
Is there any way to do the same thing by using Android SDK??
You are welcome to use the accessibility APIs to write an accessibility service and watch for text selection events. This will require the user to agree to allow your app to spy on all user input, which will tend to make your app less popular.
Otherwise, this is not possible, for obvious privacy and security reasons.
Using purely the SDK without exploiting a security vulnerability is not possible.
There is a simple explanation of why this is not possible.
The first reason is the way Android apps are executed in the OS in a sandboxed way using linux's user groups and permission system.
Every running process and Application on Android has it's own user and group and permissions to access those resources only. So in a way they cannot communicate with other apps(or capture what a user is highlithing at the moment.
The only way for an app to communicate with other is using the binder IPC, which has to pass through the activity manager first. As far as my knowledge goes, there is not a defined way to do this. Notice this is a layer of protections inherited from linux below Android's usual permission system.
Adding to this, starting from Android 5(lollipop) add to this layer the now enforced selinux policies, which do not allow the application domain to access other domains that handle graphics, the mediaserver, and some others, I will not enter more in this topic due to it's complexity and relevance to the question, just know that these are some very secure mechanisms that prevent actions that might imply a security breach.
Is it possible? Yes, however it involes exploiting a vulnerability, but this is another topic and for that I should recommend to search papers on the web that talk about vulnerabilities in android.
Maybe I'm just having a hard time wrapping my head around it. I kind of understand how it works from the research I've done, especially this question: How does Codename One work?
But what if I want to intercept incoming texts in Android? How does that affect the iOS app? If I want to use Vimeo's API to upload videos (I have an Android app that does it), will I have to get the source code and add that separately?
Incoming texts can't be intercepted in iOS as far as I know.
For Android you can use intents to intercept incoming texts but that's a bit of a pain you would need to write Android native code for that which you can do with native interfaces in Codename One.
I'm not very familiar with the Vimeo API but if its a REST API then you can pretty much map to it with Codename One's networking API using NetworkManager, ConnectionRequest etc.
I've worked with Android in the past, but haven't done anything super-advanced or what I'm about to describe so need some guidelines as to what the best approach/method is to do this before I proceed.
I'm not entirely sure how to google this, so it's best to explain.
I want to build an Android library project preferably with the source undisclosed. I read this can be done as follows: Create another jar that the Android library project references. However, not sure if all of the source code can be private. If anyone can point me somewhere, that would be great.
Asides from that, the library needs to expose an API for any Android app to use, and some sort of event mechanism to broadcast an event when certain events happen (e.g when the app is in foreground etc).
A scenario would be:
1) User loads the app which has the library embedded
2) The embedded library detects that the app has loaded and 'sends an event' to the app
3) The app captures the event and does some stuff specific to the app + an API call to the library
I guess what I'm interested mostly is figuring out what the best ways are to capture the callbacks by the app, once the library has sent some event to the app and to reduce the burden on the developer having to spend too much time implementing what needs to be done when certain events are captured.
Hope this makes sense.