Develop Reference

Android Q background restrictions

I need to show an activity on push received, but I am getting Background activity start from package-name blocked. system Toast.
This is an authentication activity where user needs to perform some task. I do not manage phone or NFC interaction thus I don't need to actually start 'special' service but showing notification is not enough - I need that activity.
SYSTEM_ALERT_WINDOW permission doesn't help.
So, should I re-implement all my flows to work only with notifications? Is there any possibility to start activity when application was closed (No activity in back stack)?

Android Q places restrictions on when apps can start activities. This behavior change helps minimize interruptions for the user and keeps the user more in control of what's shown on their screen.You can see the full document here
As of Android Q Beta 4, this change has the following properties:
Affects your app if you launch activities without user interaction
Mitigate by using notification-triggered activities
Disable restrictions by turning on the Allow background activity starts developer option

Android Oreo: Is there any way to auto - start the application on mobile reboot?

I am developing an application for a business entity. That application should run in the background in every employees' mobile phone. Employees are mostly salesman. The application basically detects location changes and suggest the salesman where they might visit. A kind of reminder application. It also lets other salesmen see where are their teammates.
Right now I am using a foreground activity and it works fine till the system forcefully doesn't kill the service or the phone doesn't reboot due to manual activity or battery discharge.
Ones the application is closed, as of now, the managers in the firm needs to call salespeople to turn on the application once, as on application start it automatically turn on its foreground service. But this is really an extra burden on the management team which can be automated.
I am ok to have any settings based or code based solution. One solution is to root the phones of salespeople and install some extra utility app or write the code based on root APIs, but this will be too much for this simple task.

THe permission RECEIVE_BOOT_COMPLETED was not added properly in the manifest. After adding the permission it worked calmly. In on receive method of the broadcast receiver, I am starting the foreground service.

At the moment, the best way is to use WorkManager https://developer.android.com/topic/libraries/architecture/workmanager/ Yes, it still alpha, but works very good.
From other side, you could work on automating the task "managers in the firm needs to call salespeople to turn on the application once". I mean, an app/backend could automatically call the salesman (with some pre-recorded message) or send SMS to them.

No response from Service and BroastReciver running on App install [duplicate]

I have a device management application, which essentially runs as a service in the background from boot. I'd like to start this application immediately after installation. How do I achieve this?

You cannot do this -- there is no way to automatically start your service merely because it was installed.
The application must first be invoked by the user through some sort of activity. Or, you are going to need to hook into some relevant broadcast Intent via the manifest, so you can get control when one of those events occur and kick off your service that way. Or, you are going to need to ask the user to reboot so your BOOT_COMPLETED Intent filter can get control.

There was a hole - the Android Analytics SDK used to send an intent right after installation - but that got closed (producing lots of confusion, of course).
But the final answer, I believe, is here:
http://developer.android.com/about/versions/android-3.1.html#launchcontrols
This seems to suggest that, as of 3.1, Google made the decision that apps are in a stopped state until the user explicitly activates them, e.g. by launching app or placing widget.
This means that the strategy of listening of a common broadcast (i.e. to get your app launched surreptitiously) won't work either.

broadcast receiver prei-nstalled apps

I know that in applications developed by third parties to get on google play, BroadcastReceiver not begin to run until the user enters the application.
I would like to know what happens in applications that are pre installed on the phone, because I am developing an application of this type. They start to listen from the beginning or require the user to enter the application?

System apps receive broadcasts, even if they are in force stopped state or have not been started even once
Edit :
PackageManagerService has a ActivityIntentResolver which resolves all the broadcasts. So if you check the override for isFilterStopped, it is excluding system apps from stopped packages.
Below is the comment you can search in AOSP:
// System apps are never considered stopped for purposes of
// filtering, because there may be no way for the user to
// actually re-launch them.

Android phone as a dedicated device

We want to use Android mobile for dedicated application. Can somebody suggest how can we make it happen.
Here are the requirement:
The phone when started, should launch our application., so the user cannot launch any other application. The application will be a 1D barcode reader.
The application should be live as long as the phone is up and running, user cannot close the application at all.
Thanks for your help.
Regards,
Manish

Android after boot is complete sends a bradcast intent:
android.intent.action.BOOT_COMPLETED
if you listen for this intent, you can launch a service that in turn launch your activity.
In the Activity you have to take care of the user's interactions that explicitly close the activity, like home button, back button and camera button press.
Setting your activity to be full-screen also should prevent the user to use the notification bar to interact with notification like those from market-app that can close your activity.
Finally, your activity can be killed by the system by various and uncatchable reasons: in those cases, the service that first launched your Activity comes in handy, as it can periodically monitor the general state of the application and relaunch components as needed.

Check out the new Android Enterprise solutions for your use case.
https://developers.google.com/android/work/overview
Its well documented. You can either use
Android Management API to provision the devices and apply policies to the device which will be applied to the device using Android's Device Policy Controller (DPC) or,
Use Google Play EMM API and develop your custom DPC
It depends upon your use-case really, but the first solution set should serve your purpose

I'm afraid there's no single answer to this, but you need to work on multiple fronts.
One of these fronts is preventing user from running other applications: for this there are applications sold on Android Market that can put other apps of your choosing behind passcode.
You need to combine this with automatic launch, but I don't yet know how to do that.