⬆️ Upgrade the native code the latest versions #1079
Comments
|
Here's the list of potential android API changes: The ones that are potentially relevant to us are:
|
|
The Fortunately, we use our own plugin, so we can change it however we want.
but with some limits
that we easily meet since we only generate the alarm once a day. |
|
Context-registered broadcasts are queued while apps are cached Do we have context-registered broadcasts?Context-registered broadcasts are those which are not in the manifest.
These are the receivers that we register for. We can ignore the bluetooth classic ones, since we only use that in the foreground for testing. For the others, let's see which messages, they register for, and whether they are defined in the manifest
Searching again for the inner class, I can confirm that there are only these three matches Note that there are also other receivers defined in the manifest that don't seem to call
So to make sure we capture all the broadcast locations, we also need to find the and These cover:
So the only context-registered broadcasts are the two in what is the cached state?
contrasted with
So unless the foreground service is killed, we will not have a cached process, so this won't apply to us. What happens if we don't receive these broadcasts when the foreground service is running?
And we do restart the foreground service anyway eventually, and then this will be fixed.
If that happens when the foreground service is not running, we won't generate proper errors. When the foreground service is re-generated, we need to make sure that we re-check the bluetooth permissions and prompt the user to re-enable. The geofence is fine; we should just verify that, if the foreground service is killed and the bluetooth status changes in the interim, we re-check the status when the foreground service is recreated, and prompt the user to fix the permissions. |
|
Foreground service types are required ✔️ If your app targets Android 14, it must specify appropriate foreground service types. ❌ If apps that target Android 14 use a foreground service, they must declare a specific permission, based on the foreground service type, that Android 14 introduces. ❌ ACTIVITY_RECOGNITION permission seems to imply ❌ The best practice for applications starting foreground services is to use the ServiceCompat version of startForeground() (available in androidx-core 1.12 and higher) where you pass in a bitwise integer of foreground service types. You can choose to pass one or more type values.
But the example is Poking around a bit... Ah! We first call So we only need to change |
|
While poking around at the documentation related to the foreground service changes in Android 14, (API 34) I also found
But do we still need that if we have a foreground service for location anyway?
Need to test! |
|
Runtime-registered broadcasts receivers must specify export behavior Building on the prior investigation into runtime registered broadcasts
We are listening to bluetooth, but for the enabled/disabled flags. So it is not clear if that comes from permissions or bluetooth app. Should test. |
|
Restrictions to implicit and pending intents Searching for all intents and seeing if they are implicit or explicit:- `plugins//cordova-plugin-file/src/android/LocalFilesystem.java`: `broadcastNewFile` is implicit; but broadcasts the intent externally - `plugins//cordova-plugin-em-datacollection/src/android/sensors/BatteryUtils.java`: `getBatteryInfo`; registering for intent - `plugins/cordova-plugin-em-datacollection/src/android/location/TripDiaryStateMachineService.java`: `handleStart` is commented out - `plugins/cordova-plugin-em-datacollection/src/android/location/TripDiaryStateMachineService.java`: `handleTripStart` is explicit - `plugins/cordova-plugin-em-datacollection/src/android/location/ForegroundServiceComm.java`: explicit - `plugins/cordova-plugin-em-datacollection/src/android/location/OPGeofenceExitActivityActions.java`: explicit - `plugins//cordova-plugin-em-datacollection/src/android/location/LocationChangeIntentService.java`: explicit - `plugins//cordova-plugin-em-datacollection/src/android/location/TripDiaryStateMachineForegroundService.java`: explicit - `plugins//cordova-plugin-em-datacollection/src/android/location/TripDiaryStateMachineForegroundService.java`: explicit - `plugins//cordova-plugin-em-datacollection/src/android/location/TripDiaryStateMachineForegroundService.java`: explicit - `plugins//cordova-plugin-em-datacollection/src/android/location/TripDiaryStateMachineForegroundService.java`: explicit - `plugins//cordova-plugin-em-datacollection/src/android/location/actions/GeofenceLocationIntentService.java`: **implicit** - `plugins//cordova-plugin-em-datacollection/src/android/location/actions/GeofenceActions.java`: **unsure** - `plugins//cordova-plugin-em-datacollection/src/android/location/actions/GeofenceActions.java`: explicit - `plugins//cordova-plugin-em-datacollection/src/android/location/actions/LocationTrackingActions.java`: explicit - `plugins//cordova-plugin-em-datacollection/src/android/location/actions/ActivityRecognitionActions.java`: explicit - `plugins//cordova-plugin-em-datacollection/src/android/location/TripDiaryStateMachineReceiver.java`: explicit - `plugins//cordova-plugin-em-datacollection/src/android/verification/SensorControlForegroundDelegate.java`: **implicit, not internal** - `plugins//cordova-plugin-inappbrowser/src/android/InAppBrowser.java`: **implicit, not internal** - `plugins//cordova-plugin-em-unifiedlogger/src/android/NotificationHelper.java`: explicit - `plugins//com.unarin.cordova.beacon/src/android/LocationManager.java`: registering for intent - `plugins//phonegap-plugin-barcodescanner/src/android/com/phonegap/plugins/barcodescanner/BarcodeScanner.java`: explicit - `plugins//cordova-plugin-local-notification-12/src/android/LocalNotification.java`: explicit - `plugins//cordova-plugin-local-notification-12/src/android/LocalNotification.java`: implicit, launching external - `plugins//cordova-plugin-local-notification-12/src/android/LocalNotification.java`: unsure, but in `requestIgnoreBatteryOptimizations`, which we don't invoke - `plugins//cordova-plugin-local-notification-12/src/android/LocalNotification.java`: `cancelScheduledAlarms` seems to be implicit - `plugins//cordova-plugin-x-socialsharing/src/android/nl/xservices/plugins/SocialSharing.java`: **implicit, not internal** - `plugins//cordova-plugin-em-serversync/src/android/ServerSyncAdapter.java`: **implicit**So the locations we need to fix are:
The locations we need to test, and potentially fix, are:
**Follow up 1:** Address MUTABLE local notificationsWhile testing Schedule Exact Alarms found that the LocalNotification code is an issue, notably This was added in e-mission/cordova-plugin-local-notification-12@0b6aefe#diff-893ce41eb8e5292aff4ea85879e33ed745caa82f2c97300f9bd7a90e3c67a277. It was also mutable when the file was copied over to the bhandaribhumin repo https://github.com/e-mission/cordova-plugin-local-notification-12/blame/e79584161eb555e18a0178e4fdcda43ddbd902d6/src/android/notification/Builder.java#L202-L208C10 with the In the original katzer repo (https://github.com/katzer/cordova-plugin-local-notifications/blob/master/src/android/notification/Builder.java), it was IMMUTABLE. with the immutable flag added in katzer/cordova-plugin-local-notifications@b7896cb to avoid crashes on android 12. Let's try to change it back to the katzer version and see if it fixes the problem. It does! **Follow up 2:** Server sync implicit intent doesn't seem to fail, but let's remove it anywayThis intent to indicate that we have new data is clearly implicit However, it appears to be sent properly without crashing However, we don't currently use the We can just remove this intent. Note, however, that we do use the This gives us: Other updates at the end of the issue |
|
Of the remaining issues flagged in #1079 (comment) The ones we are going to postpone are:
The ones that we will not fix are:
|
|
Summary of the 11 points from earlier and their resolution
|
|
Next steps:
Will test and fix tomorrow! |
|
While trying to rebuild, ran into an issue with loading the dependencies Could not resolve androidx.core:core:1.6.+.This is because the locations for the metadata have changedThe dependency is in I looked up the dependency, and the library is here https://mvnrepository.com/artifact/androidx.core/core/1.6.0 The push plugin has |
Hm... given that this appears to be a common issue with certs that people have encountered before https://stackoverflow.com/questions/69180079/how-to-resolve-gradle-tls-connection-after-upgrading-from-5-4-to-6-8-3
Since the cert is in the JRE
Let's try upgrading both of these and see if it fixes the problem. |
Upgraded to java 17.0.12 and gradle 8.10Did not fix it Checking the certs installed in the JRE... |
|
Aha! If I go to the missing URL in the browser, I still get the 404 error, but the certificate includes a root that is not part of the standard bundle Aha! the cert chain is: @louisg1337 you were right that it is due to netskope! I still don't see how this is supposed to work given that the path does not exist, but I just need to figure out how to import the enterprise root into the cacerts |
|
So I tried to look up the roots in multiple ways:
We ended up with multiple copies of the same root key in the cacert ( Note also that the error trace has while the examples on stackoverflow have Note the lack of TLS 1.3. Maybe the issue is that the netskope routing puts in TLS 1.3 somewhere along the way, while CI/CD goes out to the internet directly. Note also that even after I installed gradle The gradle version is associated with the cordova version because the gradle files are automatically created by cordova. |
|
Upgrading to [email protected] Bingo! That worked! |
|
Per the instructions, we need to have SDK Platform
This is interesting because removing the older platforms may fix our issues with the SDK install CI/CD task, which is failing because of lack of space. Let's try doing that and see if the build still works... Note that the minSDK is now 24 (Android 7). This has not changed since the last release (https://cordova.apache.org/announcements/2023/05/22/cordova-android-12.0.0.html), but it does mean that we don't need system images for API 22 and 23. |
|
Similarly upgrading the iOS version to 7.1.1
Failed with
This is because although we overwrite the Did not help. I wonder if this is related to "Moved CODE_SIGN_ENTITLEMENTS to the target settings of the application target within the Xcode project." |
|
Upgrading to the most recent version of the cordova CLI fixed it. Let's bump these up and also bump up nvm (0.40.0), node (20.9.0) and npm (10.8.2) to their LTS versions. |
|
Note also that the gradle version is automatically configured and downloaded by cordova Let's try removing that and see if it works. |
shankari
added a commit
to shankari/e-mission-phone
that referenced
this issue
Aug 27, 2024
This is consistent with e-mission/e-mission-docs#1079 (comment) and may fix the errors in the CI/CD for the android SDK installation script Testing done: with the other changes in this PR, `npx cordova build` succeeded
shankari
added a commit
to shankari/e-mission-phone
that referenced
this issue
Aug 27, 2024
This includes: - cordova-android - cordova-ios - core plugins (inapp-browser) - cordova CLI - nvm, node, npm - cocoapods - gradle This is consistent with e-mission/e-mission-docs#1079 (comment) to look through the changes in the cordova codebase
shankari
added a commit
to shankari/e-mission-phone
that referenced
this issue
Aug 27, 2024
While investigating the issues with SSL errors, I discovered that cordova doesn't use the system gradle, but configures `build.gradle` so that the correct version of gradle is downloaded and installed on the first run. This means that we don't need to install gradle manually, which in turn, means that we don't need to install sdkman so that we install the pinned version of gradle. Yay for simplifying code and removing dependencies! e-mission/e-mission-docs#1079 (comment)
shankari
added a commit
to shankari/e-mission-phone
that referenced
this issue
Aug 27, 2024
It was in `before_build` earlier, but that led to the changes from the script being overridden before the actual compile started e-mission/e-mission-docs#1079 (comment) e-mission#1168 (comment) e-mission#1168 (comment) e-mission#1168 (comment) e-mission#1168 (comment) Testing done: Before this change: ``` Done setting IPHONEOS_DEPLOYMENT_TARGET Overwriting existing resource file at platforms/ios/emission/Resources/GoogleService-Info.plist ^[[37mcordova-custom-config: Applied custom config from config.xml to /Users/kshankar/Desktop/data/e-mission/native_code_upgrade/platforms/ios/emission/emission-Info.plist^[[39m ``` After this change: ``` Overwriting existing resource file at platforms/ios/emission/Resources/GoogleService-Info.plist ^[[37mcordova-custom-config: Applied custom config from config.xml to /Users/kshankar/Desktop/data/e-mission/native_code_upgrade/platforms/ios/emission/emission-Info.plist^[[39m ... Done setting IPHONEOS_DEPLOYMENT_TARGET ... Touch /Users/kshankar/Desktop/data/e-mission/native_code_upgrade/platforms/ios/build/Debug-iphonesimulator/emission.app (in target 'emission' from project 'emission') cd /Users/kshankar/Desktop/data/e-mission/native_code_upgrade/platforms/ios /usr/bin/touch -c /Users/kshankar/Desktop/data/e-mission/native_code_upgrade/platforms/ios/build/Debug-iphonesimulator/emission.app ** BUILD SUCCEEDED ** ```
|
Geofence Action intent, improve security This is a bit tricky because of the way in which we have structured the code. We launch the GeofenceLocationIntentService service through an explicit intent. When we get the location, we want to get it back here, and then modify the location field and have the geofence action continue. So we register a BroadcastReceiver as an anonymous inner class. Right now, we send an implicit intent and filter by it in the broadcast receiver. So the flow is: we receive location, we broadcast location, we receive location, we modify GeofenceActions fields.
First, we verify that the change is not required and the code works anywayAfter making this change to force us to read the location again we get Now, let's try to send the intent to `GeofenceActions` (`new Intent(this, GeofenceActions.class);`) Did not workLet's try to determine the anonymous class name by printing it out ( Now, let's try to send to this class name (`new Intent(this, GeofenceActions$1.class);`), this generates a compile errorLet's make this a named inner class (`new Intent(this, GeofenceActions$1.class);`) instead of an anonymous one.This is better anyway to be robust to other inner classes being added to the Did not work. I suspect this may be due to the filter for the name. We listen to the filter but we don't send it anywhere The intentFilter cannot be null, but we can make it blank.
This also did not fix it There is also this argument that if you just need to notify one particular class, we should not use a receiver. But I am not going to tackle that more complex restructuring now. Instead, I will just make the changes to address the security best practices
(1) works but (2) doesn't - just switching `LocalBroadcastManager.getInstance().getReceiver` to `ContextCompat.registerReceiver` means that we don't get the broadcast messagesNo package works Package works Using `ContextCompat does not work But note that
Versions after bumping upI also changed the default version in the plugin. Everything has been updatedAnd it still failed Since I can't figure out why the ContextCompat doens't work:
|
|
Note also that if the The one in the Bluetooth code is actually not a local broadcast receiver Testing to see if it works nowWorks when the foreground service is present Killing the foreground service Turning bluetooth on and off, no logs Rooting the emulator using the instructions at: Find and kill only the foreground service Turned Bluetooth on/off, no logs (kind of expected, because with the foreground service killed, the one service is not even running). Launched the app
Try again - Bluetooth is off Kill the foreground service popup error that the app keeps closing, app is goneLaunch app, no bluetooth updates Change bluetooth toggle Comparing to android 12, behavior is the same
So we are not going to change this behavior now. The manifest-registered receivers are not subject to this change
So we don't need to change them. For the record, only these two receivers don't have the exported tag, and they are from a plugin that we haven't forked. So I think we are done here. |
|
Now that we have upgraded the base platforms and plugins, we can actually start the code changes outlined in
|
|
Next steps:
|
shankari
added a commit
to shankari/e-mission-data-collection
that referenced
this issue
Aug 28, 2024
…id 14 This addresses a couple of the issues in e-mission/e-mission-docs#1079 (comment) ❌ If apps that target Android 14 use a foreground service, they must declare a specific permission, based on the foreground service type, that Android 14 introduces. **FIXed by** ✔️ Added `FOREGROUND_SERVICE_HEALTH` and `FOREGROUND_SERVICE_LOCATION` permissions ❌ ACTIVITY_RECOGNITION permission seems to imply health as part of the foreground service as well **FIXed by** ✔️ Changed the type to `android:foregroundServiceType="location|health"` Bumped up the plugin version as well
shankari
added a commit
to shankari/e-mission-data-collection
that referenced
this issue
Aug 28, 2024
This is one of the security recommendations https://developer.android.com/develop/background-work/background-tasks/broadcasts#java I also tried to change the receiver to be NOT_EXPORTED, but could not get that to work in the limited time available. I also tried to send the message via an Intent that specified the context and the class, but that does not work with broadcast intents e-mission/e-mission-docs#1079 (comment) Testing done: - Before the change ``` 08-27 22:36:18.466 4901 5581 I GeofenceLocationIntentService: broadcasting intent Intent { act=GEOFENCE_LOCATION_RESULT (has extras) } ``` - After the change ``` 08-27 22:42:29.312 6785 7442 I GeofenceLocationIntentService: broadcasting intent Intent { act=GEOFENCE_LOCATION_RESULT pkg=edu.berkeley.eecs.emission (has extras) } ```
shankari
added a commit
to shankari/e-mission-server
that referenced
this issue
Aug 28, 2024
We don't actually use the server_to_phone response on the phone since we always retrieve data from the server. This comments out the data that is returned from the server so that we don't waste time reading data that we don't use. We still get the calls as a coarse ping to know that the app is installed and is working correctly, even if the user is not contributing data. But we don't burn up bandwidth reading unused data from the server. This cleanup is part of removing the NEW_DATA implicit intent e-mission/e-mission-docs#1079 (comment)
shankari
added a commit
to shankari/e-mission-server
that referenced
this issue
Aug 28, 2024
We don't actually use the server_to_phone response on the phone since we always retrieve data from the server. This comments out the data that is returned from the server so that we don't waste time reading data that we don't use. We still get the calls as a coarse ping to know that the app is installed and is working correctly, even if the user is not contributing data. But we don't burn up bandwidth reading unused data from the server. This cleanup is part of removing the NEW_DATA implicit intent e-mission/e-mission-docs#1079 (comment) Testing done: - Before: `08-27 17:26:02.802 11959 12158 I CommunicationHelper: Result Summary JSON = {"server_to_phone": [{"metadata": {"write_ts": 1687907246.5748034, "type": "document", "key": "diary/trips-2016-07-27"}, "data": [{"type": "FeatureCollection", "properties": {"source": "DwellSegmentat length 295649` - After: `08-27 18:39:10.918 15925 16081 I CommunicationHelper: Result Summary JSON = {"server_to_phone": []}`
shankari
closed this as completed
in
e-mission/cordova-plugin-local-notification-12@79f8d6d
shankari
added a commit
to e-mission/cordova-plugin-local-notification-12
that referenced
this issue
Aug 28, 2024
This is related to the implicit intent changes in e-mission/e-mission-docs#1079 (comment) While testing local notifications, I got the error ``` java.lang.RuntimeException: Unable to start activity ComponentInfo{edu.berkeley.eecs.emission/de.appplant.cordova.plugin.localnotification.ClickReceiver}: java.lang.IllegalArgumentException: edu.berkeley.eecs.emission: Targeting U+ (version 34 and above) disallows creating or retrieving a PendingIntent with FLAG_MUTABLE, an implicit Intent within and without FLAG_NO_CREATE and FLAG_ALLOW_UNSAFE_IMPLICIT_INTENT for security reasons. To retrieve an already existing PendingIntent, use FLAG_NO_CREATE, however, to create a new PendingIntent with an implicit Intent use FLAG_IMMUTABLE. ``` In the original katzer repo the notification had IMMUTABLE flags, when the code was copied over to bhandaribhumin it was changed to MUTABLE. Changing it back to IMMUTABLE fixes the issue. Testing done, after the fix, the transition is sent properly: ``` 08-27 17:00:57.067 11959 12185 D local-notification: Scheduling inexact alarms with intent: PendingIntent{b58ad0c: android.os.BinderProxy@cc38655} 08-27 17:01:09.358 743 783 V WindowManagerShell: Transition requested: android.os.BinderProxy@721057c TransitionRequestInfo { type = OPEN, triggerTask = TaskInfo{userId=0 taskId=29 displayId=0 isRunning=true baseIntent=Intent { flg=0x5000c000 cmp=edu.berkeley.eecs.emission/de.appplant.cordova.plugin.localnotification.ClickReceiver } baseActivity=ComponentInfo{edu.berkeley.eecs.emission/de.appplant.cordova.plugin.localnotification.ClickReceiver} topActivity=ComponentInfo{edu.berkeley.eecs.emission/de.appplant.cordova.plugin.localnotification.ClickReceiver} origActivity=null realActivity=ComponentInfo{edu.berkeley.eecs.emission/de.appplant.cordova.plugin.localnotification.ClickReceiver} numActivities=1 lastActiveTime=4787963 supportsMultiWindow=true resizeMode=1 isResizeable=true minWidth=-1 minHeight=-1 defaultMinSize=220 token=WCT{android.window.IWindowContainerToken$Stub$Proxy@2a34e05} topActivityType=1 pictureInPictureParams=null shouldDockBigOverlays=false launchIntoPipHostTaskId=-1 lastParentTaskIdBeforePip=-1 displayCutoutSafeInsets=null topActivityInfo=ActivityInfo{e2bee5a de.appplant.cordova.plugin.localnotification.ClickReceiver} launchCookies=[] positionInParent=Point(0, 0) parentTaskId=-1 isFocused=false isVisible=false isVisibleRequested=false isSleeping=false topActivityInSizeCompat=false topActivityEligibleForLetterboxEducation= false topActivityLetterboxed= false isFromDoubleTap= false topActivityLetterboxVerticalPosition= -1 topActivityLetterboxHorizontalPosition= -1 topActivityLetterboxWidth=-1 topActivityLetterboxHeight=-1 locusId=null displayAreaFeatureId=1 cameraCompatControlState=hidden}, remoteTransition = RemoteTransition { remoteTransition = com.android.systemui.shared.system.RemoteAnimationRunnerCompat$1@ef0188b, appThread = null, debugName = SysUILaunch }, displayChange = null } 08-27 17:01:09.359 538 3443 I ActivityTaskManager: START u0 {flg=0x5000c000 cmp=edu.berkeley.eecs.emission/de.appplant.cordova.plugin.localnotification.ClickReceiver (has extras)} with LAUNCH_MULTIPLE from uid 10192 (realCallingUid=10163) (BAL_ALLOW_PENDING_INTENT) result code=0 08-27 17:01:09.395 538 558 V WindowManager: Sent Transition #102 createdAt=08-27 17:01:09.351 via request=TransitionRequestInfo { type = OPEN, triggerTask = TaskInfo{userId=0 taskId=29 displayId=0 isRunning=true baseIntent=Intent { flg=0x5000c000 cmp=edu.berkeley.eecs.emission/de.appplant.cordova.plugin.localnotification.ClickReceiver } baseActivity=ComponentInfo{edu.berkeley.eecs.emission/de.appplant.cordova.plugin.localnotification.ClickReceiver} topActivity=ComponentInfo{edu.berkeley.eecs.emission/de.appplant.cordova.plugin.localnotification.ClickReceiver} origActivity=null realActivity=ComponentInfo{edu.berkeley.eecs.emission/de.appplant.cordova.plugin.localnotification.ClickReceiver} numActivities=1 lastActiveTime=4787963 supportsMultiWindow=true resizeMode=1 isResizeable=true minWidth=-1 minHeight=-1 defaultMinSize=220 token=WCT{RemoteToken{46e322d Task{cbd08ac #29 type=standard A=10192:edu.berkeley.eecs.emission}}} topActivityType=1 pictureInPictureParams=null shouldDockBigOverlays=false launchIntoPipHostTaskId=-1 lastParentTaskIdBeforePip=-1 displayCutoutSafeInsets=null topActivityInfo=ActivityInfo{2034362 de.appplant.cordova.plugin.localnotification.ClickReceiver} launchCookies=[] positionInParent=Point(0, 0) parentTaskId=-1 isFocused=false isVisible=false isVisibleRequested=false isSleeping=false topActivityInSizeCompat=false topActivityEligibleForLetterboxEducation= false topActivityLetterboxed= false isFromDoubleTap= false topActivityLetterboxVerticalPosition= -1 topActivityLetterboxHorizontalPosition= -1 topActivityLetterboxWidth=-1 topActivityLetterboxHeight=-1 locusId=null displayAreaFeatureId=1 cameraCompatControlState=hidden}, remoteTransition = RemoteTransition { remoteTransition = android.window.IRemoteTransition$Stub$Proxy@9b7bcf3, appThread = null, debugName = SysUILaunch }, displayChange = null } 08-27 17:01:09.447 538 1542 D CoreBackPreview: Window{e079e5 u0 edu.berkeley.eecs.emission/de.appplant.cordova.plugin.localnotification.ClickReceiver}: Setting back callback OnBackInvokedCallbackInfo{mCallback=android.window.IOnBackInvokedCallback$Stub$Proxy@62bd76b, mPriority=0, mIsAnimationCallback=false} ``` And the javascript gets the callbacks for add/click ``` 08-27 17:01:09.535 11959 11959 D CordovaWebViewImpl: >>> loadUrl(javascript:cordova.plugins.notification.local.fireEvent("add",{"id":1724803257028,"title":"Dummy Title","text":"Dummy text","actions":"dummy-actions","trigger":{"at":1724803262028,"type":"calendar"},"alarmVolume":-1,"attachments":[],"autoLaunch":false,"autoClear":true,"clock":true,"defaults":0,"groupSummary":false,"launch":true,"led":true,"lockscreen":true,"number":0,"priority":0,"progressBar":{"enabled":false,"value":0,"maxValue":100,"indeterminate":false},"resetDelay":5,"silent":false,"smallIcon":"res:\/\/icon","sound":true,"timeoutAfter":null,"vibrate":false,"wakeup":true,"fullScreenIntent":false,"triggerInApp":false,"meta":{"plugin":"cordova-plugin-local-notification-12","version":"0.9-beta.5"}},{"event":"add","foreground":false,"queued":true,"notification":-1773595964})) 08-27 17:01:09.537 11959 11959 D CordovaWebViewImpl: >>> loadUrl(javascript:cordova.plugins.notification.local.fireEvent("click",{"id":1724803257028,"title":"Dummy Title","text":"Dummy text","actions":"dummy-actions","trigger":{"at":1724803262028,"type":"calendar"},"alarmVolume":-1,"attachments":[],"autoLaunch":false,"autoClear":true,"clock":true,"defaults":0,"groupSummary":false,"launch":true,"led":true,"lockscreen":true,"number":0,"priority":0,"progressBar":{"enabled":false,"value":0,"maxValue":100,"indeterminate":false},"resetDelay":5,"silent":false,"smallIcon":"res:\/\/icon","sound":true,"timeoutAfter":null,"vibrate":false,"wakeup":true,"fullScreenIntent":false,"triggerInApp":false,"meta":{"plugin":"cordova-plugin-local-notification-12","version":"0.9-beta.5"}},{"event":"click","foreground":false,"queued":true,"notification":-1773595964})) ``` And add/clear ``` 08-27 17:05:37.565 11959 11959 D CordovaWebViewImpl: >>> loadUrl(javascript:cordova.plugins.notification.local.fireEvent("add",{"id":1724803537551,"title":"Dummy Title","text":"Dummy text","actions":"dummy-actions","trigger":{"at":1724803542551,"type":"calendar"},"alarmVolume":-1,"attachments":[],"autoLaunch":false,"autoClear":true,"clock":true,"defaults":0,"groupSummary":false,"launch":true,"led":true,"lockscreen":true,"number":0,"priority":0,"progressBar":{"enabled":false,"value":0,"maxValue":100,"indeterminate":false},"resetDelay":5,"silent":false,"smallIcon":"res:\/\/icon","sound":true,"timeoutAfter":null,"vibrate":false,"wakeup":true,"fullScreenIntent":false,"triggerInApp":false,"meta":{"plugin":"cordova-plugin-local-notification-12","version":"0.9-beta.5"}},{"event":"add","foreground":true,"queued":false,"notification":-1773315441})) 08-27 17:06:09.523 11959 11959 D CordovaWebViewImpl: >>> loadUrl(javascript:cordova.plugins.notification.local.fireEvent("clear",{"id":1724803537551,"title":"Dummy Title","text":"Dummy text","actions":"dummy-actions","trigger":{"at":1724803542551,"type":"calendar"},"alarmVolume":-1,"attachments":[],"autoLaunch":false,"autoClear":true,"clock":true,"defaults":0,"groupSummary":false,"launch":true,"led":true,"lockscreen":true,"number":0,"priority":0,"progressBar":{"enabled":false,"value":0,"maxValue":100,"indeterminate":false},"resetDelay":5,"silent":false,"smallIcon":"res:\/\/icon","sound":true,"timeoutAfter":null,"vibrate":false,"wakeup":true,"fullScreenIntent":false,"triggerInApp":false,"meta":{"plugin":"cordova-plugin-local-notification-12","version":"0.9-beta.5"}},{"event":"clear","foreground":false,"queued":false,"notification":-1773315441})) ``` No crashes
|
This is not actually closed. |
|
While testing against the committed code, I didn't want to edit it to force reading the location again as in So I just turned the GPS off in the emulator Tests passedNote that this looks like it also provides an explanation for why we see multiple exit activity actions and multiple geofences sometimes. Once we start `GeofenceLocationIntentService` to read the new location, we get some updates. The first update creates the geofence and stops the `GeofenceLocationIntentService`. But now that it has received the broadcast, `CreateGeofenceAction` sees a valid "last location", creates another geofence, and multiple `OPGeofenceExitActivityAction`s.Logs: |
3 tasks
idillon-sfl
pushed a commit
to FabmobQC/mamobilite
that referenced
this issue
Sep 4, 2024
This is consistent with e-mission/e-mission-docs#1079 (comment) and may fix the errors in the CI/CD for the android SDK installation script Testing done: with the other changes in this PR, `npx cordova build` succeeded
idillon-sfl
pushed a commit
to FabmobQC/mamobilite
that referenced
this issue
Sep 4, 2024
This includes: - cordova-android - cordova-ios - core plugins (inapp-browser) - cordova CLI - nvm, node, npm - cocoapods - gradle This is consistent with e-mission/e-mission-docs#1079 (comment) to look through the changes in the cordova codebase
idillon-sfl
pushed a commit
to FabmobQC/mamobilite
that referenced
this issue
Sep 4, 2024
While investigating the issues with SSL errors, I discovered that cordova doesn't use the system gradle, but configures `build.gradle` so that the correct version of gradle is downloaded and installed on the first run. This means that we don't need to install gradle manually, which in turn, means that we don't need to install sdkman so that we install the pinned version of gradle. Yay for simplifying code and removing dependencies! e-mission/e-mission-docs#1079 (comment)
idillon-sfl
pushed a commit
to FabmobQC/mamobilite
that referenced
this issue
Sep 4, 2024
It was in `before_build` earlier, but that led to the changes from the script being overridden before the actual compile started e-mission/e-mission-docs#1079 (comment) e-mission#1168 (comment) e-mission#1168 (comment) e-mission#1168 (comment) e-mission#1168 (comment) Testing done: Before this change: ``` Done setting IPHONEOS_DEPLOYMENT_TARGET Overwriting existing resource file at platforms/ios/emission/Resources/GoogleService-Info.plist ^[[37mcordova-custom-config: Applied custom config from config.xml to /Users/kshankar/Desktop/data/e-mission/native_code_upgrade/platforms/ios/emission/emission-Info.plist^[[39m ``` After this change: ``` Overwriting existing resource file at platforms/ios/emission/Resources/GoogleService-Info.plist ^[[37mcordova-custom-config: Applied custom config from config.xml to /Users/kshankar/Desktop/data/e-mission/native_code_upgrade/platforms/ios/emission/emission-Info.plist^[[39m ... Done setting IPHONEOS_DEPLOYMENT_TARGET ... Touch /Users/kshankar/Desktop/data/e-mission/native_code_upgrade/platforms/ios/build/Debug-iphonesimulator/emission.app (in target 'emission' from project 'emission') cd /Users/kshankar/Desktop/data/e-mission/native_code_upgrade/platforms/ios /usr/bin/touch -c /Users/kshankar/Desktop/data/e-mission/native_code_upgrade/platforms/ios/build/Debug-iphonesimulator/emission.app ** BUILD SUCCEEDED ** ```
|
This version (1.8.3) is now live on the android and iOS stores. Note that since we use a foreground service, I had to upload a video to the google play store describing what OpenPATH does, and wait for it to be manually reviewed. But it just got accepted right now. @jf87 @idillon-sfl @asiripanich @ericafenyo @TTalex @AlirezaRa94 @MaliheTabasi for visibility |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It is that time of the year again, and we need to upgrade the native code to the most recent version of the android API by the end of August. We do have some time to do this, but I would ideally like ~ 1 month of testing before it goes to production, so we also don't have that much time. I was hoping that @louisg1337 would be able to tackle it this time, but I am not sure if he has enough bandwidth given the changes needed for the carbon footprint improvements. So I might just have to step up and do it one more time.
The text was updated successfully, but these errors were encountered: