Summary:
This change makes it possible to remove preferences. I also added a `Delete` context menu option to `DataInspector` because I needed it to implement this feature. passy confirmed that it makes sense to add this because delete is a common action.
Fixes https://github.com/facebook/flipper/issues/451
Pull Request resolved: https://github.com/facebook/flipper/pull/1018
Reviewed By: jknoxville
Differential Revision: D21086308
Pulled By: passy
fbshipit-source-id: 551ff0908d5e6c93f58d6012b42e1ee3531de997
Summary:
Forgot to add it here previously, so it will diverge
from others if there's a global NDK env var set.
Reviewed By: nikoant
Differential Revision: D21061431
fbshipit-source-id: 0a90211a63497bac467b2b9598c7c058145857cc
Summary:
This is in line with the most recent stable Android Studio Release.
Pull Request resolved: https://github.com/facebook/flipper/pull/958
Test Plan:
Used it myself.
Open Source CI required a higher NDK, so let's first check what CI says to that internally now.
Reviewed By: jknoxville
Differential Revision: D20794634
Pulled By: passy
fbshipit-source-id: c32f934634b036ad3c1cad9fc49541e585d64329
Summary:
Fix https://github.com/facebook/flipper/issues/931
This is not how I would *like* to fix this, but it should do the job.
When the switch over to AndroidX was made, the overall abstraction
started to leak and we really need to remodel this in its entirety.
There's also the question of whether we want to support both support
fragments and AndroidX fragments or not. Right now it's kinda-sorta
supported but only under some circumstances, which is not great.
I also added some more defensive try/catches as there's some unsafe casting
involved and future changes may break this causing the entire layout to disappear.
Change Log: Fix support for AndroidX fragments in Layout Inspector.
Pull Request resolved: https://github.com/facebook/flipper/pull/957
Test Plan:
Changed the sample app to include some AndroidX fragments and they
now show up (again) in the view hierarchy:
Tested internally that FB4A fragments show up again, too:
{F233098198}
Reviewed By: mweststrate
Differential Revision: D20792503
Pulled By: passy
fbshipit-source-id: 7030b897ab547d1e8803b7f0d7aaa34263cfaed2
Summary:
Tracks images in disk cache. It seems performant even with 500+ images in disk cache. Sidebar displays the local path for an image when that image is selected. Shows total size of images in disk cache. 'Clear Cache' clears the disk cache.
For now we unpack the async cache request in the plugin, should implement a `getSync()` method on `bufferedDiskCache` in the future. For some reason Flipper doesn't work with a blocking call (https://fburl.com/smj0s4li).
Reviewed By: defHLT
Differential Revision: D20001062
fbshipit-source-id: 1e7a7900e9f42d05e3bf30472e57cd643caa5aca
Summary: We can OOM in flipper, and we'd like to catch those and prevent them from crashing the app. They are Errors, not Exceptions.
Reviewed By: mweststrate
Differential Revision: D20648824
fbshipit-source-id: 60002a3c950518e56189776f05df8f2c92a851f0
Summary: Flipper should never crash the mobile app. This is a plugin entry point, so it's understandable that it can, but we should avoid it whenever possible.
Reviewed By: passy
Differential Revision: D20648373
fbshipit-source-id: f32b428cccdd0c78eb15e9e95a64ecf3f4e10429
Summary:
This is the change made by Pascal at D19813495. to clean up the file
Shouldn't really change how it works but makes it
safer and brings it in line with our coding standards.
Reviewed By: passy
Differential Revision: D20474258
fbshipit-source-id: 67d77316a5b7efd7258072b4f35a2d9c50de408e
Summary:
Add logic on client side
# How it works (from the code)
1. Server side sends request url and method to response data and headers to client side
1.1. This will happen every time server update **any** mock response (add, edit, and remove)
2. Client stores those in map
3. For every network request,
3.1. Check if there is a matching url and method
3.2. If so, create a new response with the data and headers and drop the request
3.3. If not, proceed and send the request and wait for a response
`addNetworkInterceptor` is changed to `addInterceptor` to allow short-circuit and proceed without fetching anything. More info can be found at https://square.github.io/okhttp/interceptors/
Note:
- This is an original PR.
- The content below is from original PR
Add network response mocking for Network plugin. See discussion [here](https://github.com/facebook/flipper/issues/475)
## Changelog
- Add Network response mocking, currently support Android clients only
- Change the Android example app to use `addInterceptor()` instead of `addNetworkInterceptor()`
Pull Request resolved: https://github.com/facebook/flipper/pull/488
Test Plan:
{F231673798}
- Connect an Android device
- Tap on Network plugin
- Click on the Mock button
- Click on Add Route button, and specify the URL
- Edit the mock data in the text area
- Optionally, click the Headers tab to edit the headers data
- Click close button to close the dialog
- Send some network data in your application. You should be able to see the mock data appears in the Network table in those rows highlighted in yellow
Reviewed By: passy
Differential Revision: D16580291
Pulled By: cekkaewnumchai
fbshipit-source-id: fc391f5e7efebc6f51a72b00d16263e009e1fdb0
Summary:
per title
Note:
- This is a part of this PR: https://github.com/facebook/flipper/pull/488
Reviewed By: jknoxville
Differential Revision: D20474257
fbshipit-source-id: d2ac79d03ac67453bd67ecc46ace973be1590c04
Summary:
- Add a new listener to be called when the plugin is initialized
Note:
- This is a part of this PR: https://github.com/facebook/flipper/pull/488
Reviewed By: jknoxville
Differential Revision: D20474259
fbshipit-source-id: ef1673ffa7fbc087761a753fbae813346bd481c3
Summary:
There was a bug reported recently where the fetching all the nodes failed and the error is pasted [here](https://our.intern.facebook.com/intern/paste/P127476330/). From the paste we can see this `android.content.res.Resources$NotFoundException: Unable to find resource ID #0x0`.
Reported bug is [here](https://fb.workplace.com/groups/flippersupport/permalink/830359447444715/)
I was able to repro this luckily
{F231474948}
Reviewed By: xiphirx
Differential Revision: D20441839
fbshipit-source-id: 9e9bfd15422c0f6c6f7a71aa22e9b1c8d640ec4a
Summary: Adds the theme information relating to a Litho component in the layout inspector
Reviewed By: sjkirby
Differential Revision: D20133889
fbshipit-source-id: 93acb745f47c1ff9ce37be35a05b4a6269193a47
Summary: Remove asan checker, we can use `BuildConfig.IS_ASAN_BUILD` to check whether it's a asan build to instead of invoking a JNI api.
Differential Revision: D20088093
fbshipit-source-id: f26d367430a983fbe7b630919a4131fdf2e2d510
Summary: This will query for and display all of the associated theme information for each of the descriptors.
Reviewed By: passy
Differential Revision: D20008056
fbshipit-source-id: 720d224144b0822528ca8e23cdbec9fe9dd25e6b
Summary:
Nested subobjects work but aren't very well typed in the layout plugin.
So changing it to help flipper work with it.
From:
```
positionOnScreen: {x: 234, y: 456},
```
to
```
positionOnScreenX: 234,
positionOnScreenY: 456,
```
Reviewed By: passy
Differential Revision: D19998161
fbshipit-source-id: 4e4d7ced3cb37c527bbdf65549ec436311a8c2b8
Summary: This will query for and display all of the associated theme information for each of the descriptors.
Reviewed By: passy
Differential Revision: D19987003
fbshipit-source-id: c9b51311d28712a1af76c45a434bfb25d28d5c54
Summary:
# Summary
Folly became once again incompatible with the Android NDK, which caused our CI to fail to produce sample APK builds on release. I managed to repro this on my machine and it's working again now.
Sadly, I had to patch another file manually because something about the template parameter inference wasn't working ...
# Notes
This was done by first bumping the version, then going through the compiler errors and simply removing the lines that the C++ compiler in the NDK had trouble inferring the types for. We were lucky in that the exported symbols this affected weren't actually used, so I copied over the file to `overrides/Folly/` and set up another copy rule in Gradle.
# Meta
Pull Request resolved: https://github.com/facebook/flipper/pull/809
Test Plan:
```
./gradlew :sample:assembleDebug
```
Internal, external CI.
Reviewed By: mweststrate
Differential Revision: D19948797
Pulled By: passy
fbshipit-source-id: b2e98d3a5c89b0fc77c157683cde90997232fee0
Summary:
This diff turns the DevTools plugin from a normal plugin in a device plugin. The reason for that can be seen at the end of the test plan in the first stack of this diff: Regardless on which client you open the devtools, you are always looking at the react tree of the app that happens to listen at the appropriate port, unrelated to the actively selected app. This diff moves the plugin from being a client plugin to a device plugin, a Metro device plugin to be precisely, as of the latter there is only one and they should typically correspond (which is why we can trigger reload as done in the previous diff)
Currently we have a Flipper plugin inside the iOS / Android apps with one purpose: to select different ports to listen to on different devices. But this functionality was never implemented, nor seems there to be much demand for. So these plugin don't offer any actual value. The widely used standalone version of the react devtools (https://www.npmjs.com/package/react-devtools) doesn't offer port customization either, so this limitation seems to be acceptable.
To make sure that this change is backward compatible, we make sure to show the metro device if we find metro, regardless whether it is new enough to support log forwarding and reload commands (previously we only showed the device if it has the /events endpoint).
The only case I can think of we are killing with this approach is where people are debugging a RN app, but with having metro running. I doubt that is an actual case, but probably rickhanlonii knows more about that.
Furthermore this diff makes sure that the devTools can connect to physical android devices. Also, making it to the end of this explanation means that you have done most of the reviewing for this diff. The actual code diff is shorter.
Reviewed By: passy
Differential Revision: D19878605
fbshipit-source-id: 3f33e59d4f6e4cce39102420f38afee10018999f
Summary:
Context: https://fb.workplace.com/groups/flippersupport/permalink/804152663398727/
This gives flipper the location of every node, in relation to the entire screen. This allows it to visualize the position of each node on it's own diagram, overlayed over a screenshot for example. The use case in mind is after importing flipper data, you'll still be able to see layout nodes overlayed over a screenshot taken during export.
Currently this is only added to Android Views, meaning we don't get it for Litho views or anything on iOS.
This is basically to get something working end-to-end, and if it's all good, then I'll add the other types of views.
Reviewed By: passy
Differential Revision: D19747691
fbshipit-source-id: 8ba3aae6b7685de6faaf55b9628c200802801db4
Summary:
mityal implemented a new check for nullsafe to warn about potentially
incorrect overrides of `equals` method (not yet released).
While testing some other things I stumbled upon incorrect `equal`
overrides in Flipper, particularly not properly handling `null` param.
Reviewed By: passy
Differential Revision: D19639882
fbshipit-source-id: 7f9aec7270e89a906810807f6849628967047b2a
Summary:
## Summary
Resolves https://github.com/facebook/flipper/issues/607
This removes stetho dependencies directly in favor of just copying in the used classes. This removes the last non-androidx dependency from the project, and is useful as stetho appears to be unmaintained. The fresco stetho dependency appeared to be completely unused.
## Changelog
Remove stetho dependencies. It was unused other than a few utility methods, but came at the cost of preventing Flipper consumers from completely removing dependencies that hadn't updated to Androidx yet.
Pull Request resolved: https://github.com/facebook/flipper/pull/762
Test Plan: Existing tests still pass with no regressions. Functionally this should be no difference.
Reviewed By: jknoxville
Differential Revision: D19577969
Pulled By: passy
fbshipit-source-id: b277ddf97a9d2c846dd0b9227c02bb46c1ecd930
Summary: Currently we dont describe a `Window` object at all. Now we how the relevant theme data associated with the window.
Reviewed By: passy
Differential Revision: D19550049
fbshipit-source-id: 29903fb487b0be91d305f3b8d8fa7e4c3b3213e9
Summary:
The FB4A SQLite database plugin has to be opened 4-5 times before it shows a list of databases. This is because some databases are encrypted and can't be opened. In this case the code throws and exception and we do not catch that, causing the whole load process to crash.
Now catching the exception and returning an empty list.
Reviewed By: jknoxville
Differential Revision: D19463876
fbshipit-source-id: af8c9a70dc2761e62088d90ce89f8d16057e8745
Summary:
When debugging closeable reference leaks, I found that the Flipper plugin doesn't properly close one:
```
2020-01-17 10:45:29.346 27038-27053/com.facebook.wakizashi D/YOLO: LEAK!!:
java.lang.Throwable
at com.facebook.common.references.CloseableReference.<init>(CloseableReference.java:158)
at com.facebook.common.references.DefaultCloseableReference.<init>(DefaultCloseableReference.java:29)
at com.facebook.common.references.CloseableReference.of(CloseableReference.java:237)
at com.facebook.common.references.CloseableReference.of(CloseableReference.java:203)
at com.facebook.common.references.CloseableReference.of(CloseableReference.java:176)
at com.facebook.imagepipeline.cache.CountingMemoryCache.newClientReference(CountingMemoryCache.java:221)
at com.facebook.imagepipeline.cache.CountingMemoryCache.get(CountingMemoryCache.java:209)
at com.facebook.flipper.plugins.fresco.FrescoFlipperPlugin$4.onReceive(FrescoFlipperPlugin.java:204)
at com.facebook.flipper.android.EventBase.loopForever(Native Method)
at com.facebook.flipper.android.FlipperThread.run(FlipperThread.java:31)
```
Second leak:
```
2020-01-17 11:04:16.503 28855-28869/com.facebook.wakizashi D/YOLO: LEAK!!:
java.lang.Throwable
at com.facebook.common.references.CloseableReference.<init>(CloseableReference.java:147)
at com.facebook.common.references.DefaultCloseableReference.<init>(DefaultCloseableReference.java:21)
at com.facebook.common.references.DefaultCloseableReference.clone(DefaultCloseableReference.java:35)
at com.facebook.common.references.CloseableReference.cloneOrNull(CloseableReference.java:258)
at com.facebook.common.references.CloseableReference.cloneOrNull(CloseableReference.java:326)
at com.facebook.imagepipeline.cache.CountingMemoryCacheInspector$DumpInfoEntry.<init>(CountingMemoryCacheInspector.java:32)
at com.facebook.imagepipeline.cache.CountingMemoryCacheInspector.dumpCacheContent(CountingMemoryCacheInspector.java:101)
at com.facebook.flipper.plugins.fresco.FrescoFlipperPlugin$3.onReceive(FrescoFlipperPlugin.java:171)
at com.facebook.flipper.android.EventBase.loopForever(Native Method)
at com.facebook.flipper.android.FlipperThread.run(FlipperThread.java:31)
```
Reviewed By: passy
Differential Revision: D19445902
fbshipit-source-id: 12a513d9e34fcac0d546a4eac55932956e4e4d5b
Summary:
As previously reported in https://github.com/facebook/flipper/issues/457, I immediately started to see crashes with Flipper integrated due to large responses (e.g., >= 100MB). This will only write the first 100KB of the response or request body into `RequestInfo` objects.
## Changelog
- Limits request/response body in network request info to 100KB max.
Pull Request resolved: https://github.com/facebook/flipper/pull/617
Test Plan:
- Make a network request which has a response size of < 100kb, verify that it is visible in its entirety
- Make a network request w/ response size > 100kb, verify that it is truncated
- Ideally, use your application with the Network plugin running, and do not see OOMs
Reviewed By: mweststrate
Differential Revision: D19412075
Pulled By: passy
fbshipit-source-id: c93662dba7a5f24820287e56e889576b5bcb5a72
Summary: Lets you test the crash reporter more easily
Reviewed By: passy
Differential Revision: D18830402
fbshipit-source-id: fca57a05f121ca4219aaaf4e2b8bfeca9b46a4a9
Summary: This was a failed attempt to fix invalid initialization, but just means it fails elsewhere, so undoing this change.
Reviewed By: passy
Differential Revision: D18685054
fbshipit-source-id: fc460ee7cacc8cb89ee2a22243f9738383cbba43
Summary:
If something calls FlipperClient.getInstance(), it will start a new thread and try to start the client. If this is in a context that will fail, like a process that hasn't loaded the .so, then it will fail, but we don't know who started the thread. This adds logging before spawning a new thread so we can see the stack trace of the culprit.
It might want to throw an error instead, that will help track down the culprit of such initializations, but this is a less intrusive change to just stop the failures from happening, to start with.
Reviewed By: cekkaewnumchai
Differential Revision: D18658972
fbshipit-source-id: 2433d4d6ef411d4fb28f31e27bcef702c5a8f4db
Summary: We're seeing some cases of initHybrid failing when the C++ class hasn't been registered. I don't think we should be attempting to init in these cases, so gating it by the same logic as when we load the static library.
Reviewed By: priteshrnandgaonkar
Differential Revision: D18658101
fbshipit-source-id: b29592135dcf637a8c0d40aee30e383f4f35e527
Summary:
Well, now I feel dumb. That should have definitely been caught earlier.
I'll set up a CI job to verify this.
Fixes https://github.com/facebook/flipper/issues/648
Reviewed By: jknoxville
Differential Revision: D18657185
fbshipit-source-id: 5fea08103f5a4292159b519d62d84800c0444e41
Summary: Failing OSS check because of this right now.
Reviewed By: cekkaewnumchai
Differential Revision: D18638744
fbshipit-source-id: 1e5076f69a40f7dea87078c346e85f1797de42aa
Summary: On Android, the stack trace looks different so we don't need to use the Regex we use on iOS. We can simply display all the lines in the trace.
Reviewed By: pasqualeanatriello
Differential Revision: D17181400
fbshipit-source-id: e471da17b89806a161edc7edcf05ac6faed44bf0
Summary: This will correctly show all view children instead of reverting to the non-ax default behavior. Fixes bug where recycler views showed no children.
Reviewed By: jknoxville
Differential Revision: D18574220
fbshipit-source-id: f22606fb582e0bfd1a171dc4497e1d1613e800d1
Summary: Show the simple name instead of the node info class since this is taken into account for the attributes.
Reviewed By: jknoxville
Differential Revision: D18574219
fbshipit-source-id: 4b134e8be18c313e08df423dcdbe286d96c80b56
Summary: I don't know why we left this for so long, it doesn't make a good first impression.
Reviewed By: mweststrate
Differential Revision: D18348908
fbshipit-source-id: b8b0e5fe8f6ab81281d6ea1a1299ebdaaf0b9c43
Summary:
There is no spacing between the texts on the demo app and I found them difficult to click. So I decided to add some margins to make them more thumb-friendly :)
## Changelog
Make demo app more thumb-friendly
Pull Request resolved: https://github.com/facebook/flipper/pull/621
Test Plan: N/A
Reviewed By: jknoxville
Differential Revision: D18245979
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 9c99a477c4100323144518f56369a42085589f77
Summary:
This was removed because it's implicitly required by the library now.
However, Buck doesn't pick this up by default and requires further
configuration. It's easiest just to declare this twice now.
Reviewed By: jknoxville
Differential Revision: D18202459
fbshipit-source-id: 48c6a91c2fca0d932950a81c092b78b90a24c27b
Summary:
If we move the permissions into the library itself, the manifest
merger will take care of adding them to consuming applications,
making setup instructions easier.
## Changelog
Move required permission declarations into flipper-core
Pull Request resolved: https://github.com/facebook/flipper/pull/593
Test Plan:
Using aapt we can dump the permissions of a sample app.
`$ANDROID_HOME/build-tools/29.0.2/aapt d permissions sample-debug.apk `
```
package: com.facebook.flipper.sample
uses-permission: name='android.permission.WRITE_EXTERNAL_STORAGE'
uses-permission: name='android.permission.INTERNET'
uses-permission: name='android.permission.ACCESS_WIFI_STATE'
uses-permission: name='android.permission.READ_EXTERNAL_STORAGE'
uses-permission: name='android.permission.FOREGROUND_SERVICE
```
Reviewed By: priteshrnandgaonkar
Differential Revision: D18006323
Pulled By: passy
fbshipit-source-id: c4cf28ee698faa3e2b631462f2953976135b299c
Summary:
Base64 encoding can easily cause OOMs for large payloads.
In the long-term, it would be great to have a way of streaming these
responses so we don't allocate 50MB chunks of memory at once.
Reviewed By: jknoxville
Differential Revision: D17951353
fbshipit-source-id: a5d7b8242892518590ac95c1d9751f24d20dc40e
Summary:
see https://github.com/facebook/flipper/issues/450
If we want to control a custom SharedPreferences, we can create a Class as SharedPreferencesDescriptor's Subclass, override the getSharedPreferences() function to return a custom SharedPreferences instance.
## Changelog
add getSharedPreferences() function in SharedPreferencesDescriptor Class
Pull Request resolved: https://github.com/facebook/flipper/pull/571
Test Plan: No
Reviewed By: jknoxville
Differential Revision: D17738675
Pulled By: passy
fbshipit-source-id: d227e7d6461194f7a01ae7b2ba53434dd71fc0d2
