I'm looking into starting an Activity (different app) with some parameters (sensitive session) and was wondering what's the safest way here. For instance, startActivityForResult() may be used on Android and I was wondering if any other app can see this request or if it requires root rights to intercept such a request? So basically, is it safe to use it or not? By default, we assume users don't have root rights.
I was wondering if any other app can see this request
The app that responds to your startActivityForResult() call can see the request. That could be:
The real unmodified app that you wish to send the data to
A hacked version of that app
A completely independent app that happens to match your Intent, particularly if you are using an implicit Intent
You can try to check signatures to confirm whether the other app is indeed the real unmodified app, so you avoid the latter two scenarios.
On older versions of Android, the Intent would be visible to other apps as part of the data backing the overview screen (recent-tasks list). That was cleared up somewhere in the 4.x series IIRC.
Those are the only two attacks that I know of for non-rooted devices.
Related
I'm trying to make a phone call from my app in a way it does not need to switch activities, But every guide I find has the following code snippet,
Intent callIntent = new Intent(Intent.ACTION_CALL);
callIntent.setData(Uri.parse("tel:XXXXXXXXX"));
startActivity(callIntent);
which switches the activity I start the call from to another activity (in this case to an activity in a different app). Is there a way to stop this from happening? I managed to do it with a third party library called "sinch" but I'm wondering if there is a native way to do it or maybe a better library?
Ps- the app I'm building it for myself, basically, I'm building a voice assistant that can make calls via voice commands, hence I can't let it switch activities. I have no intention of publishing it on the app store and I have no difficulty giving dangerous permissions :) My plan is to run it on a separate piece of hardware in the future.
This link can help you, but as Xavier Rubio Jansana wrote previously, Google hardly accepts applications that do not use intents to make phone calls :
https://google-developer-training.github.io/android-developer-phone-sms-course/Lesson%201/1_c_phone_calls.html
Google wants any programmer to use an intent to make the user view the default phone application handle the phone call.
If your app does not need to be available on Google Play Store then it would be ok for you to make the phone call directly.
To elaborate on what I was talking about earlier, it is talked about in this stack overflow question (perhaps upvote their answers if they are helpful). How to make a phone call using intent in Android?.
From memory, ACTION_DIAL will bring up the dialler and pre-populate the number.. it requires no special permission because it requires the user to actually place the call.
On the other hand, ACTION_CALL will actually initiate the call and requires special permissions.
If returning focus (bringing your app back to the foreground) is a concern, you could try using a scheduled intent to (re) launch your activity (maybe using alarm manager or similar) some time after invoking the dialler. You can retain state with a little care around launch modes in the intent and/or a special "do nothing" activity published in your app manifest which does nothing but re-activate your app.
what I have:
a mobile app, that checks the current version of an application after each auth and shows a special dialog box with some info - a new version of software is available or you can't use the application before it willn't be updated. But this functional is not available for all users.
a server that handles any request from the mobile app (e.g. serching by criteria) and responses to a client
what I need:
after adding a new functional to the app, it shouldn't be available for old versions (e.g. the current app version is 1.1.1 and new modifications are used only since the app has version 1.1.2). Modifications can be variety.
what I can:
make a force updating all clients that have the old version of the app and coerce all users to update the app after new modifications will have been made by regular updates (e.g. once a month).
create a table Filter, add types of modifications, modifications, and special params and modify functions by the values from the table Filter.
All of these ways seems to me like a dirty hack.
I want to know is there any way to do this better. Has anyone faced with such problems and have a good idea to resolve it better? Thanks.
Normally force to update is not very nice aproach, but if you really need it, you can put User-Agent header in all your requests to server and create a filter there (on the server), which will return specific error to all the requests made with app version less than the version you want. Then in the app you can handle this specific error and show so called screen of death.
Also you can version API. Say you added new fields in the response of /users endpoint. So v1.1.1 can do calls to /v1/users and v1.1.2 can work with /v2/users.
In general idea is that client app is very light and it is up to server to decide what and how to return.
I am writing an application that requires end user to constantly send updates to our server. I generally use the OKhttom or httpURLConnec clients to make me api calls.
The api call is tied to a button click.
In case my end user has no internet access, is it possible that if he clicks the button to make the request. The request is cached and made later on automagically whenever internet is available?
I can think you can read the Android documentation here and choose the best option for you like:
GcmNetworkManager - docs
JobScheduler (only for API 21+) example
Evernote has released a library which already switch to the best implementation available for the device, i would suggest you to use this without doing everything from scratch: https://github.com/evernote/android-job
I have an Android app and have registered a custom URL scheme. Is it possible to get what app launched my app (e.g. Facebook, Chrome etc...)? At the moment, I can only find how to get the URL that was clicked but not the actual app that launched mine. Can I do this or am I chasing something not possible?
Thanks
No, you cannot.
Unless, of course, you have defined a proprietary protocol where the calling activity includes the name of itself in the intent, and you are in control also of the calling applications. Obviously this would not work for cases such as finding out if Chrome or Facebook called you as you don't control these apps.
You might have some limited success using ActivityManager.getRecentTasks() and try to find out which app is #2 in the task list, but that API is deprecated in Lollipop, and can not be trusted on older platforms either, apps can choose to be excluded from recent tasks, your app could be spawning a new task vs be part of the calling apps task, etc.
I have read different posts about forcing an update of an app, and the only idea that ppl has had (as far as I can tell) is to create a web service which the app calls to see what version is the current one. The WS must them manually be updated to reflect the versionCode.
This approach has several problems:
Problem 1:
When you upload an app to the Play Store, then it takes several hours before it is available for devices to download, and you never know when. Also, it seems to me like it becomes available at different times for different devices, so you really have no clue what so ever when its "available for all".
This means that you cannot immediately update the WS (that tells the app what is the "current" version) since directing them to Play Store won't be very constructive, as the updated app isn't available there anyways. And since you don't know when it will be available, you don't really know when to update the WS.
Problem 2:
Sometimes you do some changes to the back-end (comm protocol changes or something else) that requires you to upload the new version of the app and then update the backend so that they can talk to each other as expected. In this case, you really want some way to tell the app that "please update since you are out of date" and direct them to the Play Store.
So, the question is, how can I achieve this functionality?
As zapl has commented, the backend should ALWAYS allow backward compatibility. Whenever your app makes a call to the backend server the app should report its version number and the backend should respond accordingly.
As for forcing an app update, you should look at GCM to push a notification which will then take the user to the update although in reality this wouldn't actually 'force' the user to update.
Either way, as long as both the backend and app report their version numbers to each other (perhaps with a notification of 'update available') then you can design things so 1). they continue to work and 2). users will update ASAP when they need to.
I understand that publishing to Google Play can have delays but as long as the backend retains backward compatibility, it shouldn't be a problem.
You can use appgrades.io to force app updates using custom view/popup that you can design (no code required) on appgrades Dashboard