IssueTracker

Great! Thanks a lot, I'll look for the live updates soon!

I also needed this feature and 1.1.0-alpha1 seems to be working well. All I did was create a new provider class (FooProcessInitializationProvider) extending InitializationProvider (otherwise empty) and adding this to the manifest:

<provider
    android:name=".FooProcessInitializationProvider"
    android:authorities="${applicationId}:fooprocess.androidx-startup"
    android:exported="false"
    android:process=":fooprocess">
    <meta-data
        android:name="myapp.FooProcessInitializer"
        android:value="androidx.startup" />
</provider>

I think these are the minimal steps required, right (i.e. that name and authorities need to be unique)?

As a side note, it would be nice if android:name (in meta-data) would support local class names (e.g. android:name=".FooProcessInitializer")

That is correct.

As a side note, it would be nice if android:name (in meta-data) would support local class names (e.g. android:name=".FooProcessInitializer")

We tried making that part work originally. However determining the package name is expensive during startup.

It could be done at compile time, with a trick similar to the ${applicationId} manifest placeholder, or right into the manifest merger, or via a generated manifest (e.g. generated via Kotlin code, possibly using DSL(s)).

I don't think AppInitializer.discoverAndInitialize() is reading the metadata of a custom InitializationProvider, so the initializer needs to be declared separately.

Yes, the InitializationProvider needs to be declared per-process.

Are you sure the metadata tag declared on the custom InitializationProvider is being parsed? Looking at AppInitializer.discoverAndInitialize() it looks like it's only looking at non-custom InitializationProvider

Every provider declaration will also have to declare the <meta-data> entries it cares about. Unfortunately, we cannot make the assumption that Initializers that are important for one process are important for every process.

I'm seeing the opposite behaviour. Using the code shown in comment #4, it appears that the metadata tag is being ignored. Furthermore, Initializers declared in AndroidManifest, are being called in both default and "foo" process.

Are you sub-classing InitializationProvider and defining a new entry in your AndroidManifest.xml ?

Can you also please send a sample app and logs so I can better understand what is going on.

Maybe you should be passing the Initialization Class to AppInitializer.discoverAndInitialize() as an argument, so that it can query the PackageManager using that instead of InitializationProvider.class

The code is literally comment #4 plus:

class FooProcessInitializationProvider : InitializationProvider()

Please send us a full sample app. That and logs will tell me whats going on.

I don't have the time right now, unfortunately. I'd urge you to look carefully at comment #13 because that's a pretty clear bug for subclasses of InitializationProvider.

I'm also getting Lint errors on release builds:

Error: Every Initializer needs to be accompanied by a corresponding <meta-data> entry in the AndroidManifest.xml file. [EnsureInitializerMetadata from startup-runtime-1.1.0]

and

Error: Missing Initializer no-arg constructor [EnsureInitializerNoArgConstr from startup-runtime-1.1.0]

However, it is giving these messages for abstract initializers, which is surely incorrect.

Seeing the same behavior as the other commenter, with the same setup: meta-data tags being ignored for second process provider declaration, meta-data from default process provider declaration is being used instead for second process provider. Makes the multiprocess support fairly useless. Is there a desire to actually make it work?

https://android-review.googlesource.com/c/platform/frameworks/support/+/2012215 should address the issue.

Why not use the android:multiprocess tag?

This attribute is not implement?

Https://www.apache.Android10/Alcatel5002A.TCLcommonicationLTD.moden defaul.password

https://drive.google.com/file/d/1SCO1-8wLDe35GFyrp9xLBvkbDmA6vqzk/view?usp=drive_web (trace-msm8937-QKQ1.200623.002-2021-09-12-10-07-31.perfetto-trace)

Mac duflicate un prods verfier aosp iD in prod

The release is scheduled for Jan 11, 2023. Apologies for the delay !