stoptalking

"так как если бы были ошибки, не открывало бы и на других телефонах" - ага, ага :D фабрик вам в помощь

вам нужно сохранить что? Если абсолютные отступы кнопок от границ контейнера - используйте абсолютное позиционирование (естественно, на разных экранах кнопки будут визуально позиционированы по-разному). Если относительные - используйте в метриках отступов дп или констрейнт в кач-ве контейнера.

если у вас есть прожекты/гитхаб сложнее, чем стандартные ресайклеры/фонарики/прочая хрень, то дополнительных вопросов может и не быть. В остальном зависит от собесера (как тут уже было сказано) - один спросит про связь между фрагментом и активей, второй про rxjava, третий про string1 == string2, четвертый про ad hoc полиморфизм, пятый про ковариантный сабтайпинг, шестой попросит стек написать на бумажке по-быстрому. Ведро это вся жава, фреймворк + дополнительный инструментарий. Про графы вас вряд ли спрашивать будут

imageView.setImageResource(Integer.parseInt(adapter.IMAGES[position]));

вы пытаетесь стринг вида "blablablaover9000symbols" спарсить в инт, поэтому у вас все крашится.

public static int parseInt(String s) throws NumberFormatException {
    return parseInt(s,10);
}

Вместо setImageRecource используйте пикассо и в активе, как вы это делаете в адаптере

Layout Transitions

Очевидно, мапить ответы с вопросами локально/удаленно. На очередном вопросе чекать ответы мапнутые с интересующими предыдущими вопросами

самый простой способ

<Framelayout ...>
    
    <ImageView src="somewhat" layout_width="match_parent" layout_height="somewhat"/>

    <...Toolbar fitsSystemWindows="true"/>

</Framelayout>

для темы соотв. активи указать атрибут:

<item name="android:windowTranslucentStatus">true</item>

для иконки - Toolbar::setNavigationIcon()
для меню - Toolbar::inflateMenu()

Если у вас все уезжает на одном экране, а на другом не уезжает, значит вы сверстали криво. Например, задавали ширину в дп без привязки к родительским контейнерам. Констрейнт позволяет флэттернить иерархию и не писать овер9000 вложенных контейнеров, но вам все равно придется пересматривать то что сверстано.

Во-первых String[] icons = {123,123} - это ошибка компиляции. Вы объявляете массив стрингов, и пытаетесь заполнить его интами.

Во-вторых вот в этом коде

for(int i = 0; i < arr4.length(); i++) {
    String icons = arr4.getJSONObject(i).getString("icons");
    list4.add(icons);
}

поменяйте getString на getInt (или как там у вас называется метод, который превращает JsonPrimitive в инт). Ну и меняйте везде String на инт. Зачем вы создаете список, заполняете его, а потом героически преобразуете в массив?

int[] arr = new int[arr4.length];
for (...) {
    arr[i] = arr4[i]....
}

adapter = new BlaBlaAdapter(... arr);

В третьих вам уже сказали - вы пишете чушь, инты в R классах меняются. Если у вас динамические иконки - лейте их по сети. В крайнем случае храните стринговые имена, но уж никак не ресурсные инты. Но даже имена - это тоже бред, просто пукан у вас будет полыхать не после каждого ребилда, а после изменения сетов иконок.

во-первых при вашем подходе все въюхи держатся в памяти, во-вторых если посмотрите исходник addView, то вы увидите, что при добавлении въюх в контейнер в общем случае начинается лейаут-траверс для всего дерева. Сложно сказать что вы там наверстали, но стоит иметь ввиду, что для окончательного позиционирования вьюх, лейаут-траверс может происходить несколько раз в зависимости от используемых контейнеров. Десериализация - тоже не дешевый код (но у вас я так понял он вынесен в асинк). В результате получается то, что получается. С учетом наличия лейаут-траверсов никакими асинками вы это не вылечите. Вам правильно сказали - добавление итемов на скролле это классический юзкейс ресайклеров - осильте ресайклеры и используйте их