Summary:
Versions of flipper from before 7th August 2018 don't return any response, so we don't store any connection_config.json file.
To keep the functionality the same as with up-to-date app versions, when this happens, store an empty config file ("{}").
Reviewed By: danielbuechele
Differential Revision: D9682885
fbshipit-source-id: fd580f6bba6b6b20135aa2c076be10e1eea0f8bc
Summary: Loading the deviceId is not critical, so if it ever fails, we can live with that by swallowing the exception and using the default (possibly 'unknown' deviceId).
Reviewed By: danielbuechele
Differential Revision: D9682886
fbshipit-source-id: e5d60dd262fce683dd444167edd1475e0c029759
Summary: There's no need for these to be macros.
Reviewed By: priteshrnandgaonkar
Differential Revision: D9555471
fbshipit-source-id: a78d6cdb4ceb1830f749eda50e0e07ebc55723bf
Summary:
SonarWebSocketImpl has got pretty bloated. So I'm extracting all the file interaction out of it into
ConnectionContextStore. The purpose of this class is to provide all the context needed to establish a connection.
This makes SonarWebSocketImpl more functional and therefore testable.
Reviewed By: priteshrnandgaonkar
Differential Revision: D9540089
fbshipit-source-id: 0cd1d69f2b11eaf9f569245a2da14f85cc140427
Summary:
If you use a null eventbase, folly implicitly decides which one to run the futures in, for example
the timekeeper thread.
The only component that passes in event bases is sonar.cpp.
Reviewed By: priteshrnandgaonkar
Differential Revision: D9539443
fbshipit-source-id: 7fd7289257c84b039a7ac00b14f78bb271262480
Summary:
Android devices don't always know their own serial.
But we do a certificate exchange using adb from the desktop, so we can provide it in the response.
After this the client will provide it every time it connects, so we can do things like filter plugins by device id.
For apps that have already done cert exchange, they'll continue to use 'unknown' as their id until they do it again with an up to date version of sonar.
We can think about forcefully stopping that, but I haven't done it.
Reviewed By: danielbuechele
Differential Revision: D9481460
fbshipit-source-id: f8932699711ebbec4260fabe32f87e6cdff920f2
Summary:
See https://github.com/facebook/flipper/issues/230 for a longer
explanation.
It turns out that many of the tasks in `native.gradle` (at least
`prepareGlog` which modifies files inside the source directory, but also
others) cause the cmake cache to invalidate.
Because we run those tasks unconditionally, we need to recompile all our
C++ code even when unmodified.
I fix this by adding a manual cache key to this which simply skips all
the tasks unless an up-to-date `external_cache_revision.txt` is found.
This is a bit hacky, but the alternatives are a) convincing cmake that
these modifications are not recompile-worthy which I have no idea how to
do and which might be impossible to do `mtime` on the files touches, or
b) having fine-grained `onlyIf` rules for every task which can easily
break. This seems the most straight-forward option.
Fixes#230.
Pull Request resolved: https://github.com/facebook/flipper/pull/242
Reviewed By: jknoxville
Differential Revision: D9381340
Pulled By: passy
fbshipit-source-id: a7db55aacac4a29076c29298d6c5b97d8bc91f66
Summary: calling SonarClient::instance()->stop() without a connection will try to deref a null client_
Reviewed By: jknoxville
Differential Revision: D9325527
fbshipit-source-id: b0a81d6eb9d1375b74cbf10466f947e8a2de3b98
Summary: It may not be immediately obvious how this works, so adding comments.
Reviewed By: passy
Differential Revision: D9333321
fbshipit-source-id: 79740b3d2a9589b3ba48c47b0068afdaf26f35a3
Summary:
Add a method to add error messages into failed steps. This will be surfaced in the diagnostic screen, to help the user
troubleshoot.
Reviewed By: passy
Differential Revision: D9333322
fbshipit-source-id: 5f1e55c3d71b19292dbc428aaecfbd41e7a75125
Summary:
It's expected that whenever not connected to a desktop, or when the sonar desktop app isn't running, we'll get
errors connecting. Isolate these so we can treat all other exceptions properly.
Reviewed By: passy
Differential Revision: D9333323
fbshipit-source-id: c9853ca84d1a04827ebf7bae0fe87859ca6110d1
Summary:
Adds a more structured representation of state updates than a multiline string.
Also changes the string form to omit [started] records.
Reviewed By: danielbuechele
Differential Revision: D9315503
fbshipit-source-id: 55b8f9572091fd42fe852c8d26a8f2a53f76c82a
Summary:
NOTE: Second push of the same commit. The original was reverted because of an incompatibility with
the rsocket version used in the OSS build, which is now fixed.
[Step 2 of a protocol change between desktop app and agent]
The flipper agent periodically tries to connect.
When it doesn't have the required certs, instead of trying to connect, it requests them from the desktop.
After requesting, it just continues the loop, trying to request.
The problem with that is
a) the desktop can take longer than one cycle to generate and provide the certs, meaning the agent will make overlapping requests, causing confusion and it to take longer than necessary.
b) the desktop can take less time than a retry cycle, but the agent will still wait before trying to connect.
Fixing a) by making the agent wait for a response from the desktop before continuing attempting to reconnect.
This means on the next connection attempt, it's guaranteed that the desktop is finished processing the CSR.
b) remains unfixed for now, but can be dealt with separately.
This changes the agent to use requestResponse, instead of fireAndForget and wait for a response from Flipper before continuing.
Also added a fallback to detect old versions of Flipper/Sonar and use the oldFireAndForget method in those cases.
Reviewed By: danielbuechele
Differential Revision: D9315946
fbshipit-source-id: 8058f7d43690ba609f16a61c0a9b40991e9e83cc
Summary:
This breaks in open source due to a missing rsocket symbol and
blocks our legocastle task.
Closes https://github.com/facebook/flipper/issues/224
Original commit changeset: e782b303b5e4
Reviewed By: jknoxville, danielbuechele
Differential Revision: D9289450
fbshipit-source-id: b780c300394f5793e95ef2fb6b0e6ba0150caf9a
Summary: I noticed from the diagnostics screen that onDisconnected was never being called when sonar disconnects.
Reviewed By: danielbuechele
Differential Revision: D9265562
fbshipit-source-id: afd070126c6ef02a98c8dbc6589b6f9b8b83a730
Summary:
[Step 2 of a protocol change between desktop app and agent]
The flipper agent periodically tries to connect.
When it doesn't have the required certs, instead of trying to connect, it requests them from the desktop.
After requesting, it just continues the loop, trying to request.
The problem with that is
a) the desktop can take longer than one cycle to generate and provide the certs, meaning the agent will make overlapping requests, causing confusion and it to take longer than necessary.
b) the desktop can take less time than a retry cycle, but the agent will still wait before trying to connect.
Fixing a) by making the agent wait for a response from the desktop before continuing attempting to reconnect.
This means on the next connection attempt, it's guaranteed that the desktop is finished processing the CSR.
b) remains unfixed for now, but can be dealt with separately.
This changes the agent to use requestResponse, instead of fireAndForget and wait for a response from Flipper before continuing.
Also added a fallback to detect old versions of Flipper/Sonar and use the oldFireAndForget method in those cases.
Reviewed By: passy
Differential Revision: D9179393
fbshipit-source-id: e782b303b5e441f7d6c7faa3e5acdcbfb51e5e9c
Summary: These will be displayed in the sonar diagnostics screen, for troubleshooting connection issues.
Reviewed By: danielbuechele
Differential Revision: D9150552
fbshipit-source-id: c6d65fba86e7564fbb004aaa7b0303a1d5952e5d
Summary:
The plan is to add such state annotations around all core sonar tasks, so the diagnostic screen can show a useful up to date picture of what's going on.
This is the first batch of such annotaions, to act as a tracer while putting the rest of the diagnostics code in place.
Reviewed By: passy
Differential Revision: D9150555
fbshipit-source-id: 5c25205ecc690f0101b444681be48b823b0cb052
Summary:
The plan is to get SonarState to take update events and aggregate them into an object, that can be displayed in the UI so you can see what sonar is currently trying to do, and what if anything is failing.
This is pretty rubbish right now, as it just uses a single string to represent state, this is just the initial version I'll iterate on.
I also need to pass the SonarState into the SonarWebSocketImpl, since that's where a lot of the heavy lifting is done, but as long as something is logging state updates here, it proves the concept.
SonarStateUpdateListener is the interface that will be implemented by android and iOS implementations. These implementations will notify an activity or screen that the state has changed and they should reflect that.
Reviewed By: danielbuechele
Differential Revision: D9150551
fbshipit-source-id: 8dd585ca503d32e684ff843d66a59a50a420b4c0
Summary: Releases a new iOS version 0.6.16. After landing this I will release 0.6.16 tag on github
Reviewed By: danielbuechele
Differential Revision: D9194965
fbshipit-source-id: 13d5e346d6d34a7bf7b6dfb568ca622d97660132
Summary:
Prior to this diff the OSS sonar project depended on folly's master branch instead of tags, which is not good as things can break, which broke recently. So this diff adds the folly dependency thru tags to avoid any future failures.
This diff releases a new folly dependency which relies on a tag
Reviewed By: danielbuechele
Differential Revision: D9194966
fbshipit-source-id: 0a0956f0bd457e375fcbb86b3fec412aeb759a47
Summary: These will be displayed in the sonar diagnostics screen, for troubleshooting connection issues.
Reviewed By: passy
Differential Revision: D9117508
fbshipit-source-id: 6481f127b908fa539fe1fed1e268a28fa357d6f8
Summary:
The plan is to add such state annotations around all core sonar tasks, so the diagnostic screen can show a useful up to date picture of what's going on.
This is the first batch of such annotaions, to act as a tracer while putting the rest of the diagnostics code in place.
Reviewed By: passy
Differential Revision: D8954014
fbshipit-source-id: 864156b0d3f51eeb05c2c8916c1765e834f1dc8e
Summary:
The plan is to get SonarState to take update events and aggregate them into an object, that can be displayed in the UI so you can see what sonar is currently trying to do, and what if anything is failing.
This is pretty rubbish right now, as it just uses a single string to represent state, this is just the initial version I'll iterate on.
I also need to pass the SonarState into the SonarWebSocketImpl, since that's where a lot of the heavy lifting is done, but as long as something is logging state updates here, it proves the concept.
SonarStateUpdateListener is the interface that will be implemented by android and iOS implementations. These implementations will notify an activity or screen that the state has changed and they should reflect that.
Reviewed By: passy
Differential Revision: D8932114
fbshipit-source-id: fb03babfe92be53771eb4d8f10de7ecdc7f1a6d8
Summary:
Overall plan to modify Future<T>::then to be r-value qualified and use Future<T>::thenTry or Future<T>::thenValue.
The goal is to disambiguate folly::Future and to improve type and lifetime safety of Future and its methods.
4/n: Codemod:
* rvalue-future<T>.then(callable with operator()(not-a-try)) to rvalue-future<T>.thenValue(callable with operator()(not-a-try)).
* rvalue-future<T>.then(callable with operator()()) to rvalue-future<T>.thenValue(callable with operator()(auto&&)).
* rvalue-future<T>.then(callable with operator()(auto)) to rvalue-future<T>.thenValue(callable with operator()(auto)).
Applied to xplat.
Reviewed By: marshallcline
Differential Revision: D9133114
fbshipit-source-id: 30cc4f0480ca04b3abda54af3aafd9fc4dfdf0e0
Summary:
This PR adds support for using SonarKit clients in Swift apps. Fixes#13, fixes#87
1. Swift can't import Obj-C modules which have C++ headers. For this reason, we use SonarKit as an Obj-C++ wrapper around Sonar, which is written in C++. Due to search path misconfiguration, trying to import SonarKit into a Swift project would import `xplat/Sonar/SonarPlugin.h` instead of `iOS/SonarKit/SonarPlugin.h`, which caused `file not found` errors for C++ stdlib imports like #28 because new projects don't have their search paths set up correctly.
2. The network and layout plugins have C++ definitions (struct methods, classes) in some of their headers. This causes the compiler to get confused for Swift projects, because it only supports importing Objective-C files in umbrella headers, meaning that the `SonarKit` won't build.
1. I updated the `HEADER_SEARCH_PATHS` of SonarKit.podspec's build configuration to include `${PODS_ROOT}/Headers/Private/SonarKit/**` first, which alleviates the search path issue. The Obj-C `Sample` project seems to have worked around this by including a hardcoded `${PODS_ROOT}/SonarKit/**` search path in the pbxproj, which is why Sample works but new projects (like those referenced in #28) don't. I removed this since it's no longer necessary.
2. I added a `SampleSwift` app to demonstrate using Sonar with a Swift project.
3. Because the Podfiles for `Sample` and `SampleSwift` referenced podspecs using `:podspec` instead of a concrete version, Cocoapods wouldn't copy local header files (instead, it downloads them from the source). To enable local development of these sample apps using `:path`, I added a symlink to SonarKit.podspec in the root of the directory.
4. I changed SonarKit.podspec to use a tag-based `source`, since v0.0.1 pulls from the master branch of this repo.
The layout and network plugins still don't work with Swift - in order to fix this, we'll need to work on extracting the C++ out of their headers and writing Obj-C++ wrappers for them. I decided to push this off to a later PR since this one is quite large already.
This means that we need to be able to `import SonarKit` without importing all the network/layout plugin headers. In order to make this work, I made "SonarKit/Core" the spec's `default_subspecs`.
priteshrnandgaonkar, let me know if you have any thoughts on this implementation. You can verify that the SampleSwift app works by checking out this branch, `pod install`ing in the SampleSwift directory, and building it :)
Pull Request resolved: https://github.com/facebook/Sonar/pull/106
Reviewed By: jknoxville
Differential Revision: D8890010
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 449305bcc5cbeb5787c23f51b1ecb80a5cbdad32
Summary: SonarConnection should have an `error` function; this stubs out the mock to have this, allowing creation for tests.
Reviewed By: jknoxville
Differential Revision: D8878130
fbshipit-source-id: 9e0f45dac4ba31ee650dfd46dcee51207cc7a9b4
Summary:
This diff adds the support to automate iOS releases. This diff adds two scripts, one for updating all the `podspecs`, and `podfiles` with updated version number. The script also updates the version used in sample and getting started doc file.
The second script publishes a github tag.
Following will be the process for iOS release:-
1. From `fbobjc/Libraries/SonarKit/Scripts` run `sh public-ios-podspec-update.sh`, it will update all the podspecs, podfiles and docs with updated version number. Commit it and land this
2. Once the above changes are landed and synced to github, run `sh push-new-github-tag.sh` from `fbobjc/Libraries/SonarKit/Scripts` to push the tag on github
As a follow up on this diff, ideally, we should trigger second script automatically when the 1st task changes are synced to github.
Reviewed By: jknoxville
Differential Revision: D8879958
fbshipit-source-id: 8f0dc9200e8f64578af33e1446629f09c16c43f2
Summary:
This moves the native setup to a separate gradle file and unpacks everything outside the build folder. That way we don't throw everything away on every incremental build.
This is an intermediate step to get to a more declarative setup like Fresco has it and get rid of the individual hacks we have for every download.
Pull Request resolved: https://github.com/facebook/Sonar/pull/154
Reviewed By: jknoxville
Differential Revision: D8833812
Pulled By: passy
fbshipit-source-id: 2424c9d6e22e6092c04af344e06939b4a6aba041
Summary:
This diff uses `tag` instead of master branch and also updates the version number to the desktop sdk.
Pull Request resolved: https://github.com/facebook/Sonar/pull/152
Reviewed By: danielbuechele
Differential Revision: D8820016
Pulled By: priteshrnandgaonkar
fbshipit-source-id: ff2e554be55254b77c4e130b35b7299abbafa77d
Summary:
Compile against a static version of OpenSSL for better compatibility
with apps that already use OpenSSL in some fashion.
Pull Request resolved: https://github.com/facebook/Sonar/pull/149
Reviewed By: priteshrnandgaonkar
Differential Revision: D8804169
Pulled By: passy
fbshipit-source-id: 4de66a77806a3b3f01b2cf5f253916f2cf6f48e8
Summary:
One design goal of sonar is to never cause the host app to crash or hang.
For this reason, we do all heavy work in a background thread.
If we detect that it's not running in it's own thread, just return so we don't hold up the caller.
Reviewed By: danielbuechele
Differential Revision: D8767288
fbshipit-source-id: e146cc2cfe5c3e62d12f527ff79f24c74873d4ff
Summary:
Having another attempt at removing this. It's unsafe because it in some cases executes the .then() task in the timekeeper thread, rather than the executor the original future is using.
When that default executor is an InlineExecutor, for example, you can get stack overflow.
I tried to remove this use before, but having the same thread used for both the sonar client itself and rsocket, meant that they entered a deadlock trying to connect.
Now that I've separated those jobs into separate threads, they can execute independently.
Reviewed By: danielbuechele
Differential Revision: D8748356
fbshipit-source-id: a1029ece2c7006ad7642cbf8aa59e692c76b19b2
Summary:
We currently give sonar one event base from java / obj-c code to use for scheduling tasks.
This causes a problem, because we schedule reconnect tasks on the event base, and then these tasks interact with rsocket which schedules it's own tasks.
The problem is that we're passing rsocket the same event base. So the reconnect code executes and blocks waiting for rsocket to connect.
But rsocket can never connect because it never executes because that thread is blocked, so we get deadlock.
This is the first step which just changes the interface to pass two event bases.
The consumers will be changed to pass in different threads next.
Reviewed By: danielbuechele
Differential Revision: D8748350
fbshipit-source-id: 481d6f23644f28fd0f1c786252605287019c999c
