Kingsley #1
Open
Kingsley #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary: We'd like to flush events if AEM campaign id is found Reviewed By: wx0165927473 Differential Revision: D44314208 fbshipit-source-id: 35a570ce4b5b32df16cfdca3ab5e8192dc260246
Summary: $title Reviewed By: wx0165927473 Differential Revision: D44318993 fbshipit-source-id: 75d4e63be496e58494ae095572df64b6f982b075
Summary: $title Reviewed By: wx0165927473 Differential Revision: D44350264 fbshipit-source-id: 1e5eb44f215be4e944a2b430aba81d5783281448
Summary: $title Differential Revision: D44409836 fbshipit-source-id: ff376469141dbb6106903a97846136a62dd4d1ce
Summary: We need to have config loaded before we sended CAPIG events. Previously the install event logging happens at the same time with config loading and that causes we'll miss install events. In order to fix that, 1. we add `load` function which loads the config and it'll execute completion blocks after we load the config 2. in the function `recordEvent`, we'll call the `load` function and put CAPIG event logging as callback block to `load` Differential Revision: D45034581 fbshipit-source-id: 33af95049985a26d5daf524dc23aac5435799d40
Summary: We optimize the CAPIG config loading in this diff. We don't load the CAPIG config every time we log CAPIG event, but only load the config if: 1. Last refresh timestamp is over 24 hours, or 2. CAPIG config doesn't exist (e.g. loaded config is not valid) We also add a flag to mark whether we're loading config now, if yes, then we just add the callback to the callback list and wait for the config loading completion. In order to make those thread-safe, we create a serial queue and put the operations inside the serial queue. Differential Revision: D45035238 fbshipit-source-id: d69216bab9935549750b726e9894bcb61c64b937
Summary: $title Differential Revision: D45070047 fbshipit-source-id: 670583d1869959829a852be4362c1daf67953b52
Summary: $title Reviewed By: aseempuri, wx0165927473 Differential Revision: D45072518 fbshipit-source-id: f53bd86e5b567e2264d2100b26ba9b4429e48664
Summary: $title Differential Revision: D45202361 fbshipit-source-id: d22d58af5a40b2c4887f9b713c885bde018628bf
Summary: $title Reviewed By: dreamolight Differential Revision: D45746783 fbshipit-source-id: 63e9e630e23f67038cd09c90c12238b9545eba58
Summary: This fixes facebook#2168 , app events are sent in main thread and publishing ATE didn't happen in main thread. That may cause app events flushing waiting for ATE publishing in encodedDeviceInfo and thus lead to ANR issue. We should make ATE publishing in main thread as well. Differential Revision: D46326000 fbshipit-source-id: 28bf4cab8e5035ede740056c1eae4984095fa101
Summary: Fix facebook#2209 Differential Revision: D46331151 fbshipit-source-id: 94c9efd936b0d36be17939409ea83e7c7c9fe4b7
Summary: Schema design: https://docs.google.com/document/d/1w39R4VCAodg3ciM9kkGzSpPC_Bs6xkI2-DQZMnfB2JQ/edit#heading=h.a90wcj6w8gsd Here is the new v4 schema looks like: ``` { "data": [ { "lock_window_rules": [ { "lock_window_type": "time", "time": 36, "postback_sequence_index": 1 }, { "lock_window_type": "event", "events": [ { "event_name": "fb_mobile_purchase", "values": [ { "currency": "USD", "amount": 10.1 } ] } ] "postback_sequence_index": 2 } ], "coarse_cv_configs": [ { "postback_sequence_index": 1, "coarse_cv_rules": [ { "coarse_cv_value": "high", "events": [ { "event_name": "fb_mobile_purchase", "values": [ { "currency": "USD", "amount": 10.1 } ] } ] } ], "update_time": 1602399600 } ], "is_coarse_cv_accumulative": false } ] } ``` Reviewed By: KylinChang Differential Revision: D46347246 fbshipit-source-id: 208531535673806479cf40056898c609ad3e11bb
Summary: $title Reviewed By: KylinChang Differential Revision: D46452809 fbshipit-source-id: 5158af6fe281c532ae730ca779afd8489456a93b
Summary: $title Reviewed By: Nathaaaalie, KylinChang Differential Revision: D46675691 fbshipit-source-id: d32a88d3b28fb600241c230e2462ed793e86ee70
Reviewed By: wx0165927473 Differential Revision: D46430795 fbshipit-source-id: 001ca2de5ed49ea73937d360f1ddd7cc89d659d3
Summary: $title Reviewed By: wx0165927473 Differential Revision: D46631107 fbshipit-source-id: e249fa2d7cfe3232a28b3659f346a954ade08920
Summary: $title Reviewed By: wx0165927473 Differential Revision: D46714164 fbshipit-source-id: bc42540e1569cf1d482fa111a6c4bf26a5b979bf
Summary: New diff copy from D46668428 ProtectedMode is a new feature added in FBSDK, in order to filter the non-standard parameters in AppEvents that will be sent to the FB server. **In this diff** - Create ProtectedModeManager class stub - Add protectedMode to the AppEvent configuration Reviewed By: Nathaaaalie Differential Revision: D46705940 fbshipit-source-id: e3f164c7d3c9996232b3e8d12c51128494f8cef5
Summary: **In this diff** - Implement the filter method of ProtectedModeManager. Now the standardParameter list is hardcoded in FBSDK, will change to dynamically load in the future. Reviewed By: KylinChang Differential Revision: D46708165 fbshipit-source-id: 6984dec83ae578e87e8df2871c28ab93a2a989ba
Summary: $title Differential Revision: D46789002 fbshipit-source-id: 036b53b962bc74bf83160d5afbd17d7a74b8df44
Summary: **Context** As previous diffs D46705940, we enable `ProtectedMode` to filter non-standard parameter of App Events in client side. But without those params, the MACA matching cannot be done in server, so we need to move the MACA rule matching to client side as well. **In this diff** - Add new feature `FBSDKFeatureMACARuleMatching` - Add new class `MACARuleMatchingManager` and add to the AppEvents' configuration Reviewed By: KylinChang Differential Revision: D46779149 fbshipit-source-id: d12ac3b6be2cd173fdd5023d096c1ad1478cd2f8
Reviewed By: amleshjk Differential Revision: D46789789 fbshipit-source-id: ab31d733a05b7cfb0b55dd3ddbdcf4632745fa10
Reviewed By: amleshjk Differential Revision: D46845532 fbshipit-source-id: f2fcae4da48920b7a874a0d960c86843ed84f89f
Summary: $ title Differential Revision: D46845185 fbshipit-source-id: 3b7e0dbc80cd64d58021ca3270fc8bb69073ea93
Summary: TSIA Reviewed By: KylinChang Differential Revision: D46920664 fbshipit-source-id: 6477ba83da59ca67cbc9fa874234f5cfca2f5b7f
Summary: Dynamically loading standard parameters list from server. If fail, ball back to the default list Reviewed By: KylinChang Differential Revision: D46922765 fbshipit-source-id: c66d1466beb9e6eb1fb4122d664c4c68d82f01f1
Summary: **In this diff:** - Added a new query field `FBSDK_SERVER_CONFIGURATION_PROTECTED_MODE_RULES_FIELD` to load the protected mode rules - Parse and update the `maca_rules` in `MACARulesMatchingManager` Reviewed By: KylinChang Differential Revision: D46807450 fbshipit-source-id: 3c4486aab5693bd7ed3872a0e93d0593443149c9
Summary: $title Reviewed By: Nathaaaalie Differential Revision: D46989050 fbshipit-source-id: 923d36c79dcfdfb62879c307b60726584b0ebd3b
Reviewed By: Nathaaaalie Differential Revision: D46963040 fbshipit-source-id: 0101a52e5bf6c34198f72a64ad786b8eaff290b2
Summary: as title, the param is optional Reviewed By: wx0165927473 Differential Revision: D48711246 fbshipit-source-id: 2218c69156c18144811b5682bf8d6636e5c6174a
Summary: as title Differential Revision: D48928277 fbshipit-source-id: 4de92e26af36debff4a1f104915070f9cbd7c71f
Summary: in order to release v4 on time and make sure there is no issue, we seprate SKAN report logic into two different classes and wrap up with a GK FBSDKSKAdNetworkReporter - previous SKAN report logic, no v4, only update the API to prevent CV0 reset issue FBSDKSKAdNetworkReporterv2 - v4 logic including coarse value, 2nd/3rd postback Will add feature GK in next diff Reviewed By: KylinChang Differential Revision: D48933610 fbshipit-source-id: 9420a0b8dabd1747258f3b87733e5b3f5f9fe985
Summary: In this diff: 1. Add `FBSDKSKAdNetworkReporterV2` crash sheild 2. Add `FBSDKFeatureSKAdNetworkV4` feature flag, corresponding GK is `mobile_sdk_skadnetwork_v4` 3. Hook up logic for `SKAdNetworkReporter` and `SKAdNetworkReporterV2` 4. Intentionally didn't change AEM since it's deprecated Reviewed By: dreamolight Differential Revision: D48942596 fbshipit-source-id: bf12e35e5361e8a414ed96d6dfbb756c601a64e6
Summary: In theory, we should remove checkAndRevokeTimer since we don’t need to extend skan report window However, to play it safe, we did: 1. For SKAdNetworkReporter only include v3, we bought back the original logic 2. For SKAdNetworkReporterV2 include v4, we removed extending report window Reviewed By: KylinChang Differential Revision: D49296300 fbshipit-source-id: 5df17751a585d4cf3c1f4d5ec694b4a3e86dad90
Summary: To avoid using deprecated API, updated to latest one Reviewed By: KylinChang Differential Revision: D49296481 fbshipit-source-id: 8051fe1f5cf6f3972b3127db6ec3d2132a28d052
Summary: See D49337946 Reviewed By: wx0165927473, KylinChang Differential Revision: D49466622 fbshipit-source-id: efa11a73a368a0bc373d618f09c0e533e74163c2
Summary: Bump version v16.2.0 Reviewed By: wx0165927473 Differential Revision: D49530478 fbshipit-source-id: ea7edc5fe65e130a691ed9647caf60383b5f8c1d
Summary: Fix backward compatibility for building the URL API for Xcode 14. In OC, we use __IPHONE_OS_VERSION_MAX_ALLOWED to check the iOS 17 SDK. In Swift, we use `#if swift(>=5.9)` to check the iOS 17 SDK (swift compiler is 5.9 in XCode 15) Reviewed By: sway-git, xta0 Differential Revision: D49626160 fbshipit-source-id: c702fb4208634720e78ed549ae6cd647f0f6e464
Summary: $title Reviewed By: wx0165927473 Differential Revision: D50246456 fbshipit-source-id: 73fdffc085bf9807bafefecd0cd1725b7c992344
Summary: Bump v16.2.1 for podspec Reviewed By: xta0 Differential Revision: D50284099 fbshipit-source-id: ee8faa38ac9d9097c10c087d7662e2d65ef0ee63
Summary: Thanks for proposing a pull request! To help us review the request, please complete the following: - [x] sign [contributor license agreement](https://code.facebook.com/cla) - [x] I've ensured that all existing tests pass and added tests (when/where necessary) - [x] I've updated the documentation (when/where necessary) and [Changelog](CHANGELOG.md) (when/where necessary) - [ ] I've added the proper label to this pull request (e.g. `bug` for bug fixes) ## Pull Request Details I found the required dependencies are missing in the Package.swift. These are the related targets. - FacebookAEM( `.aem`) - FBAEMKit (`.Prefixed.aem`) - FBSDKCoreKit_Basics (`.Prefixed.basics`) FacebookAEM requires FBAEM. FacebookAEM just exports FBAEM interfaces. https://github.com/facebook/facebook-ios-sdk/blob/41044df838ef3fefe600fb96b6560dc8a2b2a18a/Sources/FacebookAEM/Exports.swift#L10 `FBAEMKit` imports `FBSDKCoreKit_Basics`. In fact, `.swiftinterface` of distributed `FBAEMKit.xcframework` attempts to import `FBSDKCoreKit_Basics`. So it need to add dependencies for `FBSDKCoreKit_Basics`. But there are no dependencies. It causes error on some build environment. `FBAEMKit` is a binary target, so it can't have dependencies directly. So I added the dependencies to `FBSDKCoreKit_Basics` from `FacebookAEM`. Pull Request resolved: facebook#2254 Test Plan: This manifest works. Reviewed By: joesus Differential Revision: D49624751 Pulled By: TimOliver fbshipit-source-id: 1a163f506af643fdb2ef87215c4bafbeef4759f2
Summary: Introduce two new server-side flags: - sdk_auto_logging_default_value - sdk_auto_logging_override_value SDK parses and stores these flags in the configuration object. Reviewed By: dreamolight Differential Revision: D51100780 fbshipit-source-id: 7e2448070b3ab66f86f708ba159c5c7c77aca607
Summary: WE should update the var in memory in setters. This line was somehow overlooked. Reviewed By: dreamolight Differential Revision: D51333425 fbshipit-source-id: cdf8bd5f0d97fe5a2b900c2d1ce0e198c65636c9
…bledOnClientSide Summary: Introduce a new internal client side only flag during the transition. The original `isAutoLogAppEventsEnabled` will be delegated to `isAutoLogAppEventsEnabledOnClientSide`. In the next diff, we will be adding new getter and setter for the `isAutoLogAppEventsEnabled` flag. Reviewed By: dreamolight Differential Revision: D51330511 fbshipit-source-id: cd63649372861fcdf9d06e0ecd60acae3753490f
Summary: - The SDK decision tree can be found at https://docs.google.com/document/d/10Gftcn5wqtegaEPh0LgOkarb4T0jvE_iZKEiUpVu4nU/edit - Unit tests will be added in the next diff Reviewed By: dreamolight Differential Revision: D51140801 fbshipit-source-id: 0883ac19b5a35efb1a97f34cdc7cc7fb38487749
Summary: Since we already have a bunch of test cases covering this case, this diff simply added a few cases for checking server-side values. Differential Revision: D51152076 fbshipit-source-id: be70fcab3f2bb5c11deb0146d743dcfa262533af
Summary: - Fix the broken tests on master. - The DateComponents takes daylight saving time into account, so when you ask to subtract 35 days, it doesn't subtract exactly 35×24×60×60 seconds. Instead, it goes back 35 calendar days, which due to daylight saving time changes, can result in a slightly different number of total seconds. Differential Revision: D51377252 fbshipit-source-id: ec579ee3890988ac3dc564c095f5ae4f71134519
Summary: $title Differential Revision: D51951590 fbshipit-source-id: 5d7f0c2fbc52e83baf8862417e2ee4f42efc3357
Summary: $title Reviewed By: xta0 Differential Revision: D52021803 fbshipit-source-id: f5c6fdd39934031c348155c7e9f33bf81a475cf2
Summary: There are certain events that are "unused" and "unwanted" that are transmitted from 3P clients to Meta. We want to block these events from ever being sent from the client-side. In order to do this, we need to retrieve a list of these "blocklisted" events from the server-side and build the ```BlocklistEventsManager``` to process and block these events. More information can be seen [here](https://docs.google.com/document/d/1EYy0vZ-v6q1QDGEDj_N2is6QbX4eDPodI1lYz6W8GEU/), [here](https://docs.google.com/document/d/1OcrMzjYloBgFmNRgiJ3C_beMtuKxbEr8KII0YWya8Pw/), and [here](https://docs.google.com/document/d/1kYBDdyPcCr99-B_mtubcwhVlStBW8N_E-9HDBfknka4/). This diff lays the foundation for this feature by creating the ```BlocklistEventsManager``` class and adding the ```FBSDKFeatureBlocklistEvents``` feature. The next diff will actually implement and enable the ```BlocklistEventsManager```. Reviewed By: sway-git, Nathaaaalie Differential Revision: D51099373 fbshipit-source-id: 16c57d80ba34ea2d5fcb90b4547c04685c0016fb
Summary: There are certain events that are "unused" and "unwanted" that are transmitted from 3P clients to Meta. We want to block these events from ever being sent from the client-side. In order to do this, we need to retrieve a list of these "blocklisted" events from the server-side and build the ```BlocklistEventsManager``` to process and block these events. More information can be seen [here](https://docs.google.com/document/d/1EYy0vZ-v6q1QDGEDj_N2is6QbX4eDPodI1lYz6W8GEU/), [here](https://docs.google.com/document/d/1OcrMzjYloBgFmNRgiJ3C_beMtuKxbEr8KII0YWya8Pw/), and [here](https://docs.google.com/document/d/1kYBDdyPcCr99-B_mtubcwhVlStBW8N_E-9HDBfknka4/). This diff implements and enables the ```BlocklistEventsManager```. Reviewed By: sway-git Differential Revision: D51137667 fbshipit-source-id: 725d71ec2af1c8ad481a0ce3a7f7f95c0896e125
Summary: There are certain events that are "sensitive" that violate our terms that are transmitted from 3P clients to Meta. We want to redact these event names from ever being sent from the client-side. In order to do this, we need to retrieve a list of these "redacted" events from the server-side and build the ```RedactedEventsManager``` to process and redact these events. More information can be seen [here](https://docs.google.com/document/d/1EYy0vZ-v6q1QDGEDj_N2is6QbX4eDPodI1lYz6W8GEU/), [here](https://docs.google.com/document/d/1OcrMzjYloBgFmNRgiJ3C_beMtuKxbEr8KII0YWya8Pw/), and [here](https://docs.google.com/document/d/1OhJ-LSX0fl8WJJlbs17ka3wleUQmUDchmdbmfLUXD0w/). This diff lays the foundation for this feature by creating the ```RedactedEventsManager``` class and adding the ```FBSDKFeatureFilterRedactedEvents``` feature. The next diff will actually implement and enable the ```RedactedEventsManager```. Reviewed By: sway-git Differential Revision: D51177934 fbshipit-source-id: 161ee1fa7a2c5e3e28e695ba60314a05e9abafdd
Summary: There are certain events that are "sensitive" that violate our terms that are transmitted from 3P clients to Meta. We want to redact these event names from ever being sent from the client-side. In order to do this, we need to retrieve a list of these "redacted" events from the server-side and build the ```RedactedEventsManager``` to process and redact these events. More information can be seen [here](https://docs.google.com/document/d/1EYy0vZ-v6q1QDGEDj_N2is6QbX4eDPodI1lYz6W8GEU/), [here](https://docs.google.com/document/d/1OcrMzjYloBgFmNRgiJ3C_beMtuKxbEr8KII0YWya8Pw/), and [here](https://docs.google.com/document/d/1OhJ-LSX0fl8WJJlbs17ka3wleUQmUDchmdbmfLUXD0w/). This diff implements and enables the ```RedactedEventsManager```. Reviewed By: Nathaaaalie Differential Revision: D51214260 fbshipit-source-id: 7c4111be7aa26acf046b1227d0204f49ccc0fb9f
Summary: There are certain 3P apps that are in prohibited categories. For these apps, the server-side currently blocks any incoming signals, but we want to also enforce this blocking on the client-side. In order to do this, we need to use a flag sent from the server-side on the client-side to enable the client to block events from apps that are in prohibited categories (i.e. when this flag is true). This is accomplished by extending the [MobileSdkAppEventsKillSwitchGk](https://www.internalfb.com/code/www/flib/platform/graph/resources/application/mobile_sdk/MobileSdkAppEventsKillSwitchGk.php), which is passed as the ```app_events_killswitch``` flag to the client. More information can be seen [here](https://docs.google.com/document/d/1EYy0vZ-v6q1QDGEDj_N2is6QbX4eDPodI1lYz6W8GEU/), [here](https://docs.google.com/document/d/1MCPIESOxtgTuUJC78DdLeOA8Jv4qiDaWV1NxHzGO34k/), and [here](https://docs.google.com/document/d/1svBR6jklbb6M-lhgh3qj7XyaEchJDn1YXint2ZYU_Fk/). We already use the ```app_events_killswitch``` flag to block the sending of post-install events. This diff extends the result of the ```app_events_killswitch``` flag to also block install events so that all events are blocked for apps that are in prohibited categories. Reviewed By: Nathaaaalie Differential Revision: D51290686 fbshipit-source-id: 573df6453fa705a5290eb9cbef988715ace26034
Summary: There exists a potential issue that duplicate install can be sent because `applicationDidBecomeActive` may be triggered multiple times within a very short time (e.g. App Launch and ATT prompt can trigger this function) and thus cause `publichInstall` is triggered multiple times. In order to fix this issue, this diff reuses the existing key `lastAttributionPingString` and `lastInstallResponseKey`. The flow will be 1. PublishInstall is triggered 2. Check if `lastAttributionPingString` exists and will send install event and set the key if the key doesn't exist. We do nothing if the key exists. 3. If the install event is sent successfully, we will set the key `lastInstallResponseKey`. If not, we'll remove the key `lastAttributionPingString`. 4. When app terminates, we'll check if `lastInstallResponseKey` exists to check if the install event is sent successfully. If the key exists, we'll do nothing. If the key doesn't exist, it means the install event is not sent successfully in the app launch and we'll remove the key `lastAttributionPingString`. Reviewed By: jjiang10 Differential Revision: D53170017 fbshipit-source-id: 340e21188d884088215a65d06fffc402065a5102
Summary: As title Reviewed By: KylinChang Differential Revision: D53284965 fbshipit-source-id: 1bc3e3eae60f2f9d052a59548c795f897e8c9f15
Summary: There was an XCode build warning because the feature list in the ```_FeatureManager``` was not exhaustive. This diff fixes it. Reviewed By: xta0 Differential Revision: D53289237 fbshipit-source-id: ccf6da5646b8580a95640dc180072bee2fec6abd
Summary: Added Privacy Manifests Reviewed By: jjiang10 Differential Revision: D53290629 fbshipit-source-id: c018ebad092402de1015f93ec2051bc70dfce4ee
Summary: Bump SDK Version to 17.0.0 Reviewed By: jjiang10 Differential Revision: D53864621 fbshipit-source-id: 218006151196c7d2a4432e0ddd28a4e982b6aca3
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Application-bundle-Java.zip
Thanks for proposing a pull request!
To help us review the request, please complete the following:
bugfor bug fixes)Pull Request Details
Describe what you accomplished in this pull request (for example, what happens before the change, and after the change)
Test Plan
Test Plan: Add your test plan here