Samsung Chord as a Backgorund Process - android

I am going to enter the Samsung 2013 app contest, and one of the requirements is that you use their Chord API http://developer.samsung.com/chord.
I plan on allowing users to send messages to all phones that have my app installed. From what I gathered from the information in the previous link, this means that I will need to have a constantly running background process for users to receive the messages when they are not looking at the app at the time.
I want to know if this is true, and if so, is this viable? I am considering using the method detailed here: Android: keeping a background service alive (preventing process death) if I go ahead with this.

I'm trying to use Samsung Chord too. I thing you don't need to do this. Samsung's API Chord already provides this control.
According Chord's API:
"If a Chord node doesn’t receive a UDP signal within a specified amount of time, it considers the “missing”
node to no longer be part of the network."
And, the only thing you have to do is:
"A node cannot receive a UDP broadcast if it is in LCD-off status. Therefore, if developers want the node to discover other nodes while the application is running, the node’s status should be set to LCD-on. To do this, use Android’s PowerManager.WakeLock."
Best regards,
Adriano

Related

Best way to link a FCM token to a device?

I'm making a server that sends messages using FCM to clients depending on what happens (temperature and/or humidity change, a door is opened, etc.).
But if the token can change, how can I keep track of the device to send messages to the correct one (w/o using a login system)?
I was thinking to link the token to the sim iccid in a database, is this correct?
Use device's advertising id. It won't change unless the user manually changes it. Please check the thread How to get Advertising ID in android
Update 05/18/2017:
Starting Android O, ANDROID_ID will now be different per app per user in the device.
Original Answer:
If you're looking for a long lasting (possibly permanent) ID that you can use, I guess you can make use of ANDROID_ID:
String ANDROID_ID
A 64-bit number (as a hex string) that is randomly generated when the user first sets up the device and should remain constant for the lifetime of the user's device. The value may change if a factory reset is performed on the device.
Note: When a device has multiple users (available on certain devices running Android 4.2 or higher), each user appears as a completely separate device, so the ANDROID_ID value is unique to each user.
Constant Value: "android_id"
However, there are still some factors that you should consider depending on your use-case. I recommend going through the Best Practices for Unique Identifiers documentation.
FCM wise, it is usually associated with a user, hence it is commonly paired with the user details.

Detect application is being uninstalled in lollipop devices

I would like to know which users have uninstalled my application so that I can ask them for a feedback to improve the app. Hence, I would like to detect when the user has initiated the uninstallation process on my app.
One of the older solutions on StackOverflow had the following steps:
List< ActivityManager.RunningTaskInfo > taskInfo = am.getRunningTasks(MAX_PRIORITY);
String activityName = taskInfo.get(0).topActivity.getClassName();
if (activityName.equals("com.android.packageinstaller.UninstallerActivity")) {
// do whatever is needed
Since Lollipop, getRunningTasks has been deprecated. So how can com.android.packageinstaller.UninstallerActivity activity be detected without getRunningTask?
Alternatively is there any other method to detect uninstallation process has been started on my app? Using getAppTask probably?
Apparently you wont be able to do this, you will have to rely on something called silent notification.
What we did was we sent notification every 3 days or whatever frequency you want.
On the client side as soon as a notification is received we hit a network call which mark NotificationReceived for the client. Now since notification are not full proof we assumed a threshold of 2/3 missed notification as uninstall event. And for the client we have this counter above decided threshold we contacted them for feedback.
Also no one will be willing to fill your form at the time of uninstallation as user has already decided to uninstall your application.
Read these 2 questions and answers:
native solution
GCM solution
As I know you have to mix the two. Read the limitations of first solution. You have to confirm uninstallation event of the first solution with the second solution for a complete implementation.
Hopefully, this solution will work for you. It helps you understand the reasons for your app uninstalls, reduce the uninstall rate using a powerful predictive engine and also get app Re-installs through a unique actionable channel (Android version 4.0 and above).
Just set a variable named appLastPresent for every user in the server-side and update that variable every day by calling an API using WorkManager's PeriodicWorkRequest. Also set installedDate variable when the user installs the app.
Now set up a chron job on the server side to check if the difference between installedDate and appLastPresent is greater than 7 days. Then send the user an email or message enquiring for issues or feedback, if it is greater.
NB: User can be offline for 7 days. Therefore only send email enquiring like why you are not using the app, if uninstalled please let us know why

Want to know startForeground() as user for multiuser

I am working on android multi-user. So I have to convert my existing project in to multi user supporting project.
My app will be running in owner. If I switch to user, any related UI actions should be shown on owner or user,
I am using Context.startActivityAsUser(intent, UserHandle.Current);
so the activity will be launched on corresponding user or owner.
the same way to launching broadcast events.
In my app, I am using notification as part of service as below
startForeground (int id, Notification notification);
as the service is running is owner, the notification is showing on owner only even though I switched to user.
When end user switched to other profile, the notification should be shown on current profile.
as per my knowledge, there is no startForeground(...) as user (i mean as startForegroundAsUser()) so I have converted notification stuff to
NotificationManager.notifyAsUser(null, appID, notification, UserHandle.CURRENT);
....
When I switch from owner to user, my app is getting crashed and logs also not clear for find the issue. Logcat just says as
I/ActivityManager(421): Process com.example.test (pid 5833) has died
W/ActivityManager(421): Scheduling restart of crashed service com.example.test/com.example.test.testservice in 1000ms
.....
.....
.....
but the service is not started as top profile is CURRENT.
Let me know the other approach to achieve this.
The short answer is you cannot do this. Each app package is installed on the device with a separate data area and process for each human user. They are purposely kept isolated in memory and filesystem space via Linux UID/GID and permissions. In Android 5.0 this is further enforced using SE Linux for Android. So when you are switching (human) users, your apps are being started as separate instances for that person.

Google Tag Manager for Android

I implement Google Tag Manager on my project .When i work on emulator all events come faster in Google anlyatics account shown which page open,but problem is that when i use in real device its taking more time to show the events,its taking around 2-5 mins.
I am using like that can any tell me why its not working in real device.
& also can any one help me out how to implement E commerce tracking in android app.
DataLayer dataLayer = TagManager.getInstance(context).getDataLayer();
dataLayer.push(DataLayer.mapOf("event", "openScreen",
"screenName", "Home Screen"));
GoogleAnalytics.getInstance(context).setLocalDispatchPeriod(5);
I'm not entirely sure, since I don't develop your Android, but for iOS using Google Tag Manager (and Google Analytics for that matter) the mobile platform is not pushing events in realtime, but they batch the data and send them every other minute or so. For me the emulator in iOS does the same, i.e. it sends data every other minute and the same on device. Maybe the emulator in Android is different in this regard, but I believe that mobiles do not send data in realtime at all, but batches a chunk of data and send it at the same time.
I don't think there is any way to go around this. Correct me if I'm wrong though, but that's what I read somewhere in the documentation. Can't seem to find the reference though.

Why do we need a UserHandle in many API declarations

In Android Open Source Project, a lot of core API declarations have an integer parameter userId in the end. I traced back and figured out the integer comes from a class called "UserHandle.java". There is a simple comments saying this class represents a user on the device. It still confuses me. Why do we need such a class? What's the difference between different values of the class, such as "USER_OWNER", "USER_CURRENT", "USER_CURRENT_OR_SELF"?
Thanks in advance!!!
Ever since Jelly Bean, Android platform has supported multiple users. This means that multiple users may be able to use one device, yet not be able to access other user's files or communicate with another user's app.
The first user on the device is user 0. The rest start their numbering from 10,11,... (In JB the numbering was 1,2...).
USER_OWNER is user 0.
He has some extra privileges over the other users (mostly access certain settings that others can't or uninstall an app for all users).
Multiple users on one device requires that only one user can be active in a specific point in time, this user is referred to as USER_CURRENT (since Kitkat().
In general one user's application can't send a broadcast message or an Intent to other user's apps.
Only apps with system permissions can do that (for example when the battery is running low, an intent will be sent to all).
Whenever you send an Intent from your app, the system service verifies whether this is a valid Intent i.e. if its supposed to reach all users then it's not.
This means that even if you were to use a certain api with the wrong userId (for example you force userId=0 even though this is user 10), then your call will receive a SecurityException.
To avoid such exceptions, there is also the option to send an Intent with USER_CURRENT_OR_SELF.
This means you're trying to send to the current user, but if he's not allowed to receive the Intent, let the same user who sent the Intent receive it.

Categories

Resources