HERE SDK tries to start its MapService internally when consumers call MapEngine.init(). Due to Android 8 background execution restrictions, this fails if MapEngine is to be initialized from a background Service. Is there any way to initialize MapEngine that doesn't involve the SDK starting a Service internally?
The exception log:
> java.lang.IllegalStateException: Not allowed to start service Intent { act=com.here.android.mpa.service.MapService.v3 cmp=de.newecho.app/com.here.android.mpa.service.MapService (has extras) }: app is in background uid UidRecord{6924417 u0a225 CEM idle change:cached procs:1 seq(0,0,0)}
at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1521)
at android.app.ContextImpl.startService(ContextImpl.java:1477)
at android.content.ContextWrapper.startService(ContextWrapper.java:650)
at com.nokia.maps.MapServiceClient.a(SourceFile:77)
at com.nokia.maps.MapsEngine.a(SourceFile:622)
at com.nokia.maps.MapsEngine.a(SourceFile:364)
at com.here.android.mpa.common.MapEngine.init(SourceFile:260)
EDIT:
I have no idea why this got marked as a duplicate. My question is not about how to generally handle background work on Android 8 as in the "duplicated" question. The call to startService() happens in the HERE SDK internally, so consumers have no means to change that. The question is directed towards HERE devs to clarify whether there is a way to initialize MapEngine in a manner so that the HERE SDK doesn't start a Service internally.
Within HERE Mobile SDK it is not possible to init the map from a background thread.
It is possible to continue function like Navigation in background after map init(in foreground) is done by ensuring a) The required map data is already loaded on the device, b) a foreground service is triggered
From Documentation : https://developer.here.com/documentation/android-premium/dev_guide/topics/map-guidance.html
If you are using Turn-by-Turn Navigation Mode
for driving, you can also set HERE SDK to perform guidance (including
voice instructions and event callbacks) while the app is in the
background. However, unlike the foreground navigation scenario, HERE
SDK does not stream map data during background navigation on Android.
To properly support background navigation for these devices, HERE SDK
requires your app to preload map data (such as for the current city or
state) using the MapLoader class.
Important: Starting with Android O (8.0), if your app is running in
the background, then the location system service only computes a new
location for your app a few times each hour. To avoid this behavior,
start a foreground service by following the instructions in the
Android documentation. Important: Starting with Android P (9.0), app
that requires use of foreground service must request
android.permission.FOREGROUND_SERVICE permission from the user. For
more information, please refer to Android Pie behaviour change
documentation.
Related
Any one know how get the location update every seconds. when my device on foreground or background mode.
I am working on Tracking app get the location in every seconds when he is waking on road or traveling whatever.
Actually my app working on version 10 not working on android 11 and 12.
Also searched on google don't found exact answer.
I used this permission:
Access background permission,
Access Coarse permission.
Access Fine Location.
OR Foreground services for notification
If any one know please let tell me
Thank you
in android 11 or higher the user has to go to app permissions and specifically give them permissions to always take the position in the background. This permission cannot be requested from the app. Only from the phone configuration.
To help protect user privacy, Android 11 (API level 30) introduces limitations to when a foreground service can access the device's location, camera, or microphone. When your app starts a foreground service while the app is running in the background, the foreground service has the following limitations:
Unless the user has granted the ACCESS_BACKGROUND_LOCATION permission to your app, the foreground service cannot access location.
The foreground service cannot access the microphone or camera.
Reference link : https://developer.android.com/guide/components/foreground-services#access-restrictions
you have to use the Foreground service for that and add a task in the Foreground service to get a location using geolocation or any other library.
steps to implement:
implement foreground service using link library::[1]: https://github.com/Raja0sama/rn-foreground-service.
add headless task using geolocation.
you will get the location after the app is removed from recent.
my goal is show an activity in every where(even lock screen) on a specific time.
i could in previous android versions until Oreo do this work , but after Oreo Google change the methods, "if you want to display a view on lockScreen use "Activity.this.setShowWhenLocked(true);" :Google says. then i have to create an activity and only use a service wasn't enough.
My Solution : i use AlarmManger to run a service in background on a specific time, that service start my activity(my goal).
Problem : in previous versions android until Oreo , i don't have problem. app works fine . even that time i close my app from recent app , or phone locked. but in Oreo and newer when app works when it is in foreground.
point : in my intent i use this flag :FLAG_ACTIVITY_NEW_TASK
question : how to run a specific activity from a background service even when app is close or phone locked, in Oreo and newer version?
You can't achieve this desired result using background service instead you must consider Foreground service for this task. Here you can find further details about Foreground Services in Android. docs reference
Hope this will help you.
Pardon, but the question here is how to run an activity or a task even when the app is closed. Foreground service will exist as long as the user is interacting with the app or there is a persistent notification showing the task progress, this isn't a case here.
I'd strongly recommend you to go for the workmanager to perform background task. There is a brilliant codelab on the same here :
https://codelabs.developers.google.com/codelabs/android-workmanager/#0
and read the docs here :
https://developer.android.com/topic/libraries/architecture/workmanager
in addition that works i done previous, i understood MIUI in Xiaomi prevent from displaying pop-up window that comes from back ground , then i got its permission and solved problem, now i can see my view anywhere i want. here is a brief for whom that want :
Permissins :
1.Overlay window
2.pop-up window from background(in Xiaomi and probably Other Chinese Phone UI)
Levels :
set a alarm from Activity with Calendar & PendingIntent in AlarmManger to run my Service in a specific time
when i computed my values in Service then Intent to ActivityViewer, in this step i add FLAG_ACTIVITY_NEW_TASK to my intent(according to google docs in android Pie you have to add this flag to your intent for this usage).
In my ActivityViewer according to google docs , I use Activity.setWhenLock() method to show my view even in lock screen and use TYPE_APPLICATION_OVERLAY for Oreo and newer , and use TYPE_TOAST for version 6 until Oreo , and use TYPE_SYSTEM_ERROR for before 6 , in setLayoutParams for setType.
I use this code for getting pop-up window from background permissin in Xiaomi :
Intent intent = new Intent("miui.intent.action.APP_PERM_EDITOR");
intent.setClassName("com.miui.securitycenter",
"com.miui.permcenter.permissions.PermissionsEditorActivity");
intent.putExtra("extra_pkgname", getPackageName());
startActivity(intent);
I am verifying my location service compatibility with Android Q but I am a little unsure how my app is going to react since in my testing I have seen not difference when granting Background permission vs Only while app is running.
Coming off this statement from the Q migration documentation
An app is considered to be in the background unless one of its
activities is visible or the app is running a foreground service.
Since the location service is a foreground service does the difference in permission even matter in this case?
Well it's a bit of a tricky question.
When running location foreground service on Q you need "while app running" permission + to declare in the manifest this foreground service is of type location. Your app has no need of the background permission.
If your app do asks for background permission, the user can get suspicious and reject any location permission :( So it is not recommended to ask the user for permissions you don't need.
highly recommend to watch this video from the google IO: Updating Your Apps for Location Permission Changes in Android Q (Google I/O'19)
You can read more about t here: documantation
And you can see googles example project on GitHub for location updates on Q with foreground service here :LocationUpdatesForegroundService
You just need run foreground service instead of background. Otherwise your app will crash during background services start when there is no activity on the foreground
Based on my testing, it appears that the NotificationListenerService(NLS) in my android app is not getting bound to the system on Android 8 (Oreo). I am targeting my app for SDK version 26 to make it compatible with the new OS.
Prior to Android N, the NLS service was bound to SystemUI forever (Ref: Google I/O 2016). Starting from Android N, two new methods were introduced in NLS service: requestRebind(ComponentName) and requestUnbind().
In Android Oreo, there are new Background Execution Limits that apply to services. However, it does not apply for certain services, such as a "Notification listener that another app binds to". This is my use case, as I am using an NLS service that is supposed to be bound to the SystemUI.
However, as I observed, this service is never getting bound to SystemUI. Additionally, even if I explicitly call requestRebind(ComponentName), the service is never getting bound and hence it is non-functional because this means I am unable to listen to notifications.
How do I fix this problem in Android Oreo?
Oh boy, this is silly! The issue was resolved by a reboot. I suppose Android was misbehaving on my phone and simply refused to work the right way. Rebooting the phone and trying again made the service work the way it is supposed to!
I'll leave this question up as a reminder to all that sometimes the simplest and most cliched fix (i.e. "Did you try turning it off and on again?") is the right answer!
Good grief!
My app main usage is overlay, the overlay is running from a service.
Android Security add the nice "Screen Overlay Detected"
I want to avoid "Screen Overlay Detected" when user tries to change permissions. so... I've add an AccessiblityService that detects:
if ( event.getPackageName().equals("com.google.android.packageinstaller") ){
stopService(myServiceIntent);
}
However, even now I see this message popping. (when my service is stopped...).
I saw Twilight does it without problem.
What am I missing?
p.s. - I've also tried building a signed apk but saw exact same behavior.
It seems I've been able to resolve this.
a) stopService isn't assured your service will be stopped.
as described here :
It will not be destroyed until all of these bindings are removed. See > the Service documentation for more details on a service's lifecycle.
b) I was able to kill my service by sending intent that called stopSelf().
However process killing/starting can be slow.
c) Best resolution: so it seems Android checks for view visibility. no need to kill services or do anything more complicated.
Current way I'm doing it:
- AccessibilityService (already used by my app) monitor "com.google.android.packageinstaller" though it can be refined to class: "com.android.packageinstaller.permission.ui.ManagePermissionsActivity"
Once detected in this class, we send Intent to "duck", and when we're out, we send another intent that we're back on.
The service handles those calls by:
[ourView].setVisibility(View.INVISIBLE); // when permission settings shown
[ourView].setVisibility(View.VISIBLE); // when normal flow
As long as Android 6.x is buggy on some devices where this "overlay alert" is displayed without any reason (on 2 to 5% of the devices according to my analytics data), the best solution is to avoid the whole permission process by defining the targetSdk to 22. Take care that you can't downgrade the target sdk for a new version or this will induce a INSTALL_FAILED_PERMISSION_DOWNGRADE error when the user updates requiring an unisntall/install of the app.