To też nie jest specjalnie dobrym podejściem. Na przykład jeśli system ubije apkę, singleton zniknie, ale po powrocie apka zostanie zrestartowana od tej drugiej aktywności (jeżeli to na niej użytkownik był ostatnio), a nie tej pierwszej, która ustawiała stan singletona. A więc teraz już ta druga aktywność nijak "nie dowie się", jakie miała wcześniej parametry. Może to nawet doprowadzić do crasha, jeśli nie przewidziałeś takiej sytuacji i spróbujesz w ciemno odczytać jakieś dane z singletona, nie biorąc pod uwagę, że jego stan został w międzyczasie zresetowany i np. masz nulle.
Singletony są też niezalecane z powodów ogólnych, vide link podany przez @MarekR22. Między innymi zaciemniają one obraz powiązań między różnymi komponentami aplikacji (znany problem event busów). Widziałeś kiedyś na filmach wojennych czy szpiegowskich, jak uczestnicy konspiracji przekazują sobie grypsy czy mikrofilmy, wtykając je w umówione miejsce, a potem przychodzi ten drugi i wyciąga karteluszek spod ławki w kościele? Odpowiednikiem tego jest singleton. Jedna aktywność dyskretnie zostawia coś drugiej "w umówionym miejscu". W projekcie o rozmiarach przekraczających trywialne może to doprowadzić do tego, że zrozumienie, jak w aplikacji wygląda zarządzanie stanem, przepływ kontroli itd. stanie się bardzo trudne. Sami sobie stworzyliśmy siatkę konspiratorów do rozgryzienia :)