I still think it is not really nice if we use HasReceiverRegistration, because this code has nothing to do with receivers. I suggest to reintroduce the interface that i mentioned, and use it there instead of HasReceiverRegistration.

HasLifecycleMethods?

Are you sure that the interface should have onDestroyBeforeSuperBlock method?
If not, how can I insert OpenHelperManager.release in the onDestroy method?

Do you think that HasLifecycleMethods should not have onDestroyBeforeSuperBlock? Why?

Because the OrmliteDaoHandler can handle two scenarios: with an onDestory method or not.
We cannot create getOnDestroy into HasLifecycleMethods, thus will be ignore annother scenario.

@EBean and @EActivity can use it well. But @EBean does not have a onDestroy method

You mean we should only add onDestroyXXX in the HasLifecycleMethods?
So that it conforms to the ISP? :)

Don't get me wrong, I just confirm that I understand

OK, it would be seen as redundant to you, because basically everyting which is a HasLifecycleMethods is HasReceiverRegistration, too. But i still think this is better design. This is what i propose:

create a new HasLifecycleMethods interface:

public interface HasLifecycleMethods extends GeneratedClassHolder {
    JBlock getOnCreateAfterSuperBlock();
    JBlock getOnDestroyBeforeSuperBlock();

    JBlock getOnStartAfterSuperBlock();
    JBlock getOnStopBeforeSuperBlock();

    JBlock getOnResumeAfterSuperBlock();
    JBlock getOnPauseBeforeSuperBlock();

    JBlock getOnAttachAfterSuperBlock();
    JBlock getOnDetachBeforeSuperBlock();
}

Let HasReceiverRegistration extend HasLifecycleMethods, and remove redundant method declarations:

public interface HasReceiverRegistration extends HasLifecycleMethods {
    JExpression getContextRef();

    JFieldVar getIntentFilterField(String[] actions, String[] dataSchemas);
}

Use HasLifecycleMethods in OrmLiteHelper:

public static void injectReleaseInDestroy(JFieldVar databaseHelperRef, HasLifecycleMethods lifecycleMethodsHolder, ProcessHolder.Classes classes) { ... }

Yep. You're right!

In fact, the most perfect solution i think is split into four interface: HasLifecycleMethods / HasStartAndStopMethods / HasAttachableMethods / HasReceiverRegistration.
There is no connection between them.

EActivityHolder and EFragmentHolder need implement: HasLifecycleMethods,HasStartAndStopMethods, HasAttachableMethods and HasReceiverRegistration
EServiceHolder need implement: HasLifecycleMethods and HasReceiverRegistration

In ReceiverHandler.registerAndUnregisterReceiver method, we can add two method with the same name.
These methods are respectively corresponding to these Interface.

However, this is a huge change. I think to do as you say.

Yes, we could split it even further, but i think my proposal will suffice
for now.