Activity1 to Activity2. Finally, in Activity2, the device id is retrieved and is eventually sent out of the device through *sendTextMessage* (lines 15-17).

    //TelephonyManager telMnger; (default)
    //SmsManager sms; (default)
    class Activity1 extends Activity {
     void onCreate(Bundle state) {
      Button to2 = (Button) findViewById(to2a);
      to2.setOnClickListener(new OnClickListener(){
       void onClick(View v) {
        String id = telMnger.getDeviceId();
        Intent i = new Intent(Activity1.this,Activity2.class);
        i.putExtra("sensitive", id);
        Activity1.this.startActivity(i);
    }});}}
    class Activity2 extends Activity {
     void onStart() {
      Intent i = getIntent();
      String s = i.getStringExtra("sensitive");
      sms.sendTextMessage(number,null,s,null,null);
    }}

This privacy leak cannot be detected by intra-component analyzers such as FlowDroid [@arzt2014flowdroid], because the switching between Activity1 and Activity2 is unfortunately decided only by the system and it is non-trivial to obtain it directly at the code level [@octeau2015composite; @octeau2016combining]. Therefore, in this work, we present IccTA, a code instrumentation based approach, which modifies the code to be analyzed in a way that inter-component feature is mitigated. As an example, Listing \[code:resolve\_icc\] demonstrates the modifications made by IccTA for the ICC leak example shown in Listing \[code:example\_icc\]. The ICC method *startActivity* is replaced by a helper method that simulates the ICC through Java code, resulting in a simplified code snippet where ICC is no longer appearing. As a consequence, 