d7b17c469b
(This is a merge of http://go/wvgerrit/86383) When Key Sessions were added to CryptoSession, the initialization of the initial Key Session was placed at the end of the initialization of the owning CryptoSession. That's all well and good except the block right before that assumed that it was safe to abort initialization early in order to swallow errors when setting up usage tables. As a result, if anything caused usage table initialization to fail, it would leave the CryptoSession without a Key Session, resulting in an inevitable segfault further down the line. There's no reason the Key Session can't be initialized first. This change moves initialziation order around to avoid the bug. Bug: 141021960 Test: CE CDM Unit Tests Test: Android Unit Tests Change-Id: Ic78005c831d2a24d7d6de22df54462b2bd7085f0