The test failed with the rewrite of the code because it violates
one of our assumptions that only one Activity will be started. However,
since it doesn't rely on observed behavior and we made up the events,
it's value is questionable so it seems okay to remove, especially for
the gain of conciseness in the code.
While we could easily move this into the metrics ping, it's better to
leave it in the other ping because it's less work and because (I think)
we'll be better able to match `framework_secondary` values to the clock
ticks if we combine them in the same ping.
We do this in order to make it easier to analyze in GLAM: see the metric
descriptions for more details.
Additionally, we change the time unit to milliseconds to make it easier
to analyze in GLAM.
Add privacy notice related strings
Pop out privacy notice with onboarding
Using embeded geckoview to display details about privacy
Present or hide privacy pop window according to isMozillaOnline
Add activity_privacy_content_display.xml into layoutNotToTest due to EngineView
* For #16373: Added performance Inflater to counter # of inflations
This class is quite straight forward. The only thing that I have to point out is the onCreateView method. It usually
calls its super if you don't override it. The problem with that is that the super.onCreateView actually uses
android.view. as a prefix for the XML element it tries to inflate. So if we have an element that isn't part
of that package, it'll crash. As I said in the code, a good example is ImageButton. Calling android.view.ImageButton
will make the app crash. The method is implemented the same way that PhoneLayoutInflater does (Another example
is the AsyncLayoutInflater)
* For #16373: Added test for PerformanceInflater
This test got quite awkward / complicated fast. I wanted to test the to make sure we don't break *any* of our layouts
and to do so, I decided to just retrieve all our XML in our /res/layout folder. However, this gets quite a bit outside of a unit test scope.
The point was to get every layouts and get their LayoutID through the resources using the testContext we have. It gets even weirder, since some
of the XML tags have special implementation in android. One of them is the <fragment> tag. That tag actually is inflated by the OS using the Factory2
that the Activity.java implements. In order to get around the fragment issue, we just return a basic FrameLayout since the system LayoutInflater doesn't deal
won't ever get a <fragment> tag to inflate. Another issue was the <merge> tag. In order to inflate those, you need 1) a root view and 2) attach your view to it.
In order to be able to test those layouts file, I had to create an empty FrameLayout and use it as the root view for testing. Again, I know this is beyond the spirit of a unit test but if we use this inflater, I think it should make sure that no layouts are broken by it.
* For #16373: Overrode getSystemService to return PerformanceInflater
This allows PerformanceInflater to be called in every inflation to keep track of the number of inflations we do.
* For #16373: Added UI test for # of inflations
* For #16373: Lint fix
* For #167373: Changed the LayoutInflater cloneInContext to take this instead of inflater
The inflater parameter is set on the first call from the OS from the Window object. However, the activity itself sets multiple factories on the inflater
during its creation (usually through AppCompatDelegateImpl.java). This means that, once we initially set the inflater with a null check, we pass an inflater
that has no factory initially. However, since we keep a reference to it, when cloneInContext was called, it cloned the inflater with the original inflater
which didn't have any factories set up. This meant that the app would crash on either browserFragment creation or any thing that required appCompat (such as
ImageView and ImageButton). Now, passing itself with a cloneInContext means we keep all the factories initially set by the activity or the fragment.
* For #16373: Fixed code issues for PR. No behavior change
* For #16373: fixed some code nits
While StrictMode is not exclusively used for performance purposes, it's
primarily used for perf purposes so let's move it to the perf package
and code owner it.
* For #15278: added CoroutineManager to count runBlocking calls
* For #15278: Added actual detekt rule for runblocking and its config to the yaml
* For #15278: Added unit test for RunblockingCounter
* For #15278: renamed StrictModeStartupSuppressionCountTest.kt to PerformanceStartupTest.kt and added runBlockingCount test
* Lint fix
* For #15278: made runblocking a Long to prevent overflow
* For #15278: fixed MozRunblocking name, description and moved RunBlockingCounter to perf package
* For #15278:Renamed MozillaRunblockingCheck to MozillaRunBlockingCheck
* For #15278: Added setup for unit test, since it failed without restting counter
* For #15278: Fixed naming for RunBlocking lint check
* For #15278: removed changes made to test to use runBlockingIncrement
* For #15728: added test exclusion for runBlocking check
* For #15278: changed null check and added Synchronized to count setter
* For #15278: fix for nits
* For #15278: added StartupExcessiveResourceUseTest to CODEOWNERS
* For #15278: fixed for nits
* For #15278: Moved increment function to extension function and fixed indentation
* For #15278: Added tests for Atomic Integer extension and nit fix
We need to access the data in stat to get the process start time, so we
can calculate the time from process start until application.init for the
frameworkStart probe.
This monitor for hot start was intended to be used by FNPRMS to measure
hot start. However, hot start was deprioritized so it's now essentially
unused.
Michael Comella
rxu
MarcLeclair
Tiger Oakes