我在一个android项目（java）上运行fortfy scan，发现了一些问题。报告没有建议如何解决这个问题。
它将具有清单声明接收器的启动程序类标记为“动态代码评估：不安全的反序列化”。但我没有反序列化任何对象。

<activity
        android:name=".LaunchScreen"
        android:screenOrientation="portrait">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />
            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>

我在google上搜索过，大部分都是java对象反序列化，没有一个和android相关。
扫描结果：
动态代码求值：不安全的反序列化
摘要在运行时反序列化用户控制的对象流可使攻击者在服务器上执行任意代码、滥用应用程序逻辑或导致拒绝服务。
说明java序列化将对象图转换为字节流，其中包含对象本身以及从字节流重建对象所需的元数据。开发人员可以创建自定义代码来帮助反序列化java对象，甚至可以用不同的对象或代理替换反序列化的对象。在对象被返回到应用程序并转换为预期类型之前，自定义反序列化过程在对象重构期间进行。当开发人员尝试强制执行预期类型时，代码可能已经执行。自定义反序列化例程在可序列化类中定义，这些类需要存在于运行时类路径中，并且不能被攻击者注入，因此这些攻击的可利用性取决于应用程序环境中可用的类。不幸的是，常见的第三方类甚至jdk类都可能被滥用以耗尽jvm资源、部署恶意文件或运行任意代码。某些协议在传输层后台使用java序列化。rmi和jmx就是这些协议的例子。
建议如果可能，在未验证对象流内容的情况下，不要反序列化不受信任的数据。为了验证被反序列化的类，应该使用先行反序列化模式。对象流将首先包含类描述元数据，然后包含其成员字段的序列化字节。java序列化过程允许开发人员读取类描述并决定是继续进行对象的反序列化还是中止它。为此，必须将java.io.objectinputstream子类化，并提供resolveclass（objectstreamclass desc）方法的自定义实现，其中类验证和验证应于2016年9月29日下午5:09进行。版权所有2015 hewlett-packard enterprise development lp 13。现有的look-ahead模式的实现很容易使用，比如apachecommons io（org.apache.commons.io.serialization.validatingobjectinputstream）。始终使用严格的白名单方法仅反序列化预期类型。不建议使用黑名单方法，因为攻击者可以使用许多可用小工具绕过黑名单。另外，请记住，尽管实现代码执行的某些类是公开的，但可能还有其他类是未知的或未公开的，因此白名单方法总是首选的。应该审核白名单中允许的任何类，以确保反序列化是安全的。为了避免拒绝服务攻击，建议您重写resolveobject（object obj）方法，以便统计有多少对象正在反序列化，并在超过阈值时中止反序列化。当反序列化在库或框架中发生时（例如，当使用jmx、rmi、jms、http调用程序时），上面的建议没有用，因为它超出了开发人员的控制范围。在这些情况下，您可能需要确保这些协议满足以下要求：-不公开。-使用身份验证。-使用完整性检查。-使用加密。此外，hpe security fortify runtime提供了每次应用程序从objectinputstream执行反序列化时都要执行的安全控制，从而保护应用程序代码以及库和框架代码免受此类攻击。